SMS performance testing is harder than typical API load testing. Delivery can be delayed, carriers can reorder messages, and simple polling logic often turns test runs into noisy false failures.

This guide shows a practical pattern for QA, SRE, and performance teams:

  1. Create a MailSlurp deliverability test.
  2. Start it.
  3. Send traffic (MailSlurp simulator or your own sender).
  4. Poll one status endpoint until completion.

The result is a stable, long-running test flow with clear progress and pass/fail outcomes.

Why SMS tests fail in the real world

  • Carrier and routing delays are normal.
  • Delivery timing varies by destination and region.
  • Direct inbox polling loops are hard to tune and easy to flake.
  • Teams often lack one reliable success metric for multi-recipient runs.

MailSlurp deliverability tests solve this by tracking the run centrally and returning test-level progress, counts, and status over time.

What this example project gives you

This repository includes two equivalent JMeter implementations:

  1. HTTP sampler approach (classic JMeter style).
  2. Java Request sampler approach using .

Both support:

  • and .
  • and .
  • 15-second status polling.
  • 20-minute timeout by default (suitable for typical 15-20 minute telecom windows).

The workflow at a glance

Create a free MailSlurp account and API key

  1. Sign up at MailSlurp.
  2. Create at least one phone number (two numbers for ).
  3. Create an API key in the MailSlurp app.
  4. Export the key in your shell:

Core API sequence

The JMeter plans use these endpoints:

  • (simulator mode)

Step 1: choose simulator and target phones

  • First phone in the page is used as the simulation sender.
  • In mode, second phone is used as the explicit target.

Step 2: create the deliverability test

mode selector:

mode selector:

Why we exclude the simulator sender

Some telecom routes can allow sender loopback behavior (a number effectively messaging itself). To avoid skewed results, the example excludes the simulation sender from the selected targets.

Step 3: start the test

Start the run with:

Step 4: send traffic

:

  • The plan creates a simulation job that sends SMS to selected targets.

:

  • The simulation call is skipped.
  • Your application, queue worker, campaign platform, or notification service sends SMS instead.
  • MailSlurp still tracks outcomes through the same deliverability test.

Step 5: poll status until complete

Every 15 seconds:

The run exits on success, failure, or timeout.

Running the example

From the repo root:

HTTP sampler approach

Java sampler approach

Use your own sender platform

What you will see during runs

Console progress markers are printed as the test executes:

  • HTTP plan: , ,
  • Java plan: , ,

Helpful commands:

HTTP vs Java approach: when to use each

Use HTTP sampler if you want:

  • A transparent, endpoint-by-endpoint JMeter plan.
  • Easy editing by non-Java JMeter users.
  • Quick experimentation with raw payloads.

Use Java sampler if you want:

  • Reusable typed client logic.
  • Easier extension with shared utility code.
  • A pattern that mirrors how many mature JMeter teams integrate JVM services.

Replacing the simulator with your real sender

The simulator is useful for proving the test harness. In production-like tests, most teams switch to and invoke their actual sender stack:

  • Application API endpoints.
  • Message bus producers.
  • Campaign orchestration jobs.
  • Cron or workflow pipelines.

That keeps the verification model the same while making the traffic source realistic.

Why this is reliable for long telecom windows

Older telecom infrastructure can introduce long, uneven delivery windows. These tests avoid fragile -style receive loops by using deliverability primitives designed for asynchronous completion and progress polling. You get durable run-state tracking without constant custom retry logic.

You can also run this without code

MailSlurp deliverability tests can also be configured in the MailSlurp web app, then connected to notification channels such as:

  • Slack
  • Email
  • Microsoft Teams
  • Webhooks

That gives operations teams a no-code path for monitoring and alerting while engineering teams keep JMeter in CI/CD.

Final recommendation

Start with simulator mode to validate your flow quickly. Once stable, move to and drive SMS from your real system. Keep the same polling and pass/fail logic so results stay consistent across environments.