2,785,861 screenshots in 31 days

The number

This March, a single Add Screenshots customer captured 2,785,861 screenshots. Averaged out, that is roughly 90,000 captures every day — about one per second, around the clock, for a month — except that real workloads are never averaged out. They arrive in bursts: thousands of captures fired in parallel when a job kicks off, then quiet, then another wave.

We are sharing the number because it answers the question every developer quietly asks when evaluating a smaller vendor against the big names: can this platform actually handle production volume? The honest answer is a specific number, not an adjective.

What breaks at that volume

At a few hundred screenshots a day, almost any headless-browser setup works. At ninety thousand a day, everything that can go wrong, does — daily:

• Pages that hang. Some fraction of the web simply never finishes loading. At volume, "some fraction" means hundreds of captures a day that would block a worker forever if you let them.
• Servers that degrade. A browser process leaks memory, a VM gets a noisy neighbor, a deploy goes sideways. With enough requests, a rare server problem becomes a daily event.
• Regions that blip. Cloud regions have bad moments. If your capture fleet lives in one region, its bad moment is your outage.

The design goal that fell out of this: no single capture request may ever depend on a single machine — or a single continent.

The architecture that absorbs it

Every request that hit the platform in March — all 2.78 million from this customer, plus everyone else's — ran through the same routing layer:

• Edge routing: requests enter a global edge network and route to the nearest of three capture regions — the US, Europe, or Australia / Asia Pacific — each running at least four dedicated capture servers.
• Hedged requests: if a capture hasn't returned within a threshold, a second server starts the same capture in parallel and the fastest result wins. A slow machine costs milliseconds of routing, not minutes of waiting.
• Fleet retries: if a server errors, the request retries across the other servers in the region — inside the same request, invisibly to the caller.
• Geo-failover: if an entire region is having a bad day, the request completes on another continent. No configuration, no client-side retry code.

The full breakdown lives on our reliability page. The short version: the customer doing 2.78 million captures never wrote a retry loop. They didn't need to.

The part nobody notices: where 2.78 million screenshots go

Here is the design decision that matters most at volume, and it's about what we don't do: we never store your screenshots. Every capture is delivered directly to storage the customer owns — AWS S3, Azure Blob, Google Cloud Storage, Cloudflare R2, or FTP/SFTP — or returned in the API response and forgotten.

At small volume that is a privacy feature: sensitive captures never sit on someone else's servers. At 2.78 million captures a month it is also an economic one. There is no growing archive on our side whose storage bill quietly becomes part of your subscription price, and no honeypot of customer screenshots accumulating anywhere. The customer's captures went straight into the customer's buckets, in their regions, under their retention rules.

What this means if you're evaluating us

Three takeaways from the biggest single-customer month in our six years of operation:

• The infrastructure is proven at roughly 3M captures/month for one tenant — and every plan, including the free tier, runs on exactly the same fleet, routing, and failover. There is no "premium infrastructure" upsell.
• Volume doesn't require negotiation. Self-serve plans run to 1.5 million screenshots per month; above that, email us for volume pricing.
• Concurrency is not rationed. Burst workloads are the normal case at scale, so no plan has concurrency caps or throttling.