KEY TAKEAWAYS
- Throughput scales with concurrency only up to the provider ceiling.
- Size time budgets with p95 latency, not the median.
- Deduplicate lists and stream results to work faster.
- Observed average: 139 checks per active day.
Before running a large list, it helps to know what the numbers look like. These figures come from real platform activity over the last 90 days.
Observed volume
- Checks in the window: 278 across 2 active day(s).
- Average per active day: 139; busiest day: 262.
- Median per-check latency: 10,971 ms.
Throughput by concurrency
Rough expected capacity at the current median latency (cards checked in parallel × 3600 / latency). Real throughput also depends on provider limits and p95 tail behaviour:
| Concurrency | Approx. rate | 8-hour run | 10,000 cards |
|---|---|---|---|
| 10 in flight | 3,281 / hour | 26,248 / 8h | 3 h for 10k |
| 25 in flight | 8,203 / hour | 65,624 / 8h | 1.2 h for 10k |
| 50 in flight | 16,407 / hour | 131,256 / 8h | 0.6 h for 10k |
| 100 in flight | 32,814 / hour | 262,512 / 8h | 0.3 h for 10k |
Planning rules of thumb
- Throughput scales with in-flight concurrency until the provider ceiling — past it, added parallelism turns into timeouts.
- Plan with p95, not median, when sizing time budgets for large lists.
- Streaming means you can start acting on results long before the run finishes: see how it works.
- Split very large lists and deduplicate first — see the bulk workflow.
Methodology
Volumes and latency come from aggregate platform metrics over the last 90 days. Capacity figures are estimates at the current median latency and exclude provider-specific limits. No customer data is used or published.