Measured, not promised.
We ran SimpleQ under sustained load in an isolated environment and checked every published job against every delivery. Here are the numbers, and exactly how they were produced.
At a sustained 100 attempts/sec — the pace that carries 259 million attempts a month — SimpleQ delivered 1,046,431 attempts with zero delivery discrepancies, zero publish errors, and a 22.6 ms p95 on ack callbacks.
the pace held for two hours, extrapolated — no service approached saturation
1,046,431 attempts matched per job ID — none missing, none unrecognized (100.00% deliverability)
zero non-2xx across 1,046,431 POST /jobs
SimpleQ's ack endpoint answering 326,430 acknowledgments, zero failures
What the run actually produced.
| Metric | Result | Detail |
|---|---|---|
| Attempts delivered | 1,046,431 | 720,001 in standard mode, 326,430 in ack mode |
| Publish error rate | 0.00% | zero non-2xx responses across every POST /jobs in both runs |
| Deliverability | 100.00% | published jobs matched to a delivery, per job ID |
| Delivery discrepancies | 0 | none published-but-never-received, none received-but-never-published |
| Sustained rate | 100/sec | held at exactly 100.0 attempts/sec for the full two-hour standard-mode run |
| Ack callback API round-trip p95 | 22.6 ms | same-region client, across 326,430 acknowledgments with 0 failures |
| Queueing and delivery lag | none | no lag developed at any point in either run |
The tested environment was deliberately capped well below production limits — these were test constraints, not production ceilings. For workloads that need dedicated infrastructure, see Enterprise.
How the numbers were produced.
A benchmark is only worth what its method is worth. Here's how this one was set up, and why each choice matters.
The environment was isolated
Every measurement ran in a dedicated environment separate from development and production, so no other workload contributed to the readings. Deploys were frozen for the duration of each window — a build consumes compute on the same infrastructure and would corrupt the numbers.
The load generator was external to the system under test
The generator and the receiving webhook endpoint both ran on a separate host in the same region, so neither appears in the measured resource figures. File-descriptor limits and the ephemeral port range were raised first, which matters: a saturated generator produces a plateau that looks exactly like a server-side ceiling.
Rate control was open-loop
The generator dispatches on a clock rather than waiting for responses. A closed-loop generator — send N, await all, repeat — silently converts the intended rate into whatever the server allows, which makes a throughput measurement meaningless. Open-loop control is why the effective rate held at exactly 100.0/sec across both runs.
Delivery was verified independently, per job
The generator counts successful publishes, the receiver independently counts deliveries, and in ack mode the receiver separately counts acknowledgments sent. Analysis then joins the two records on job ID rather than comparing totals — so a lost job and a duplicated job cannot cancel out. Agreement across those independently maintained records is what establishes that nothing went missing.
The run would have stopped itself if it went wrong
The generator aborts if non-2xx responses exceed 1% in any rolling five-second window, and exits with a diagnostic status histogram. A run whose error rate got interesting would not have quietly finished — which is what makes a 0.00% error rate over a million attempts meaningful rather than survivorship.
This run covered standard and ack mode on the clean-delivery path with ~2.4 KB JSON payloads.
Run it against your own endpoint.
The free tier covers 30,000 attempts a month, every feature included, no credit card.