Built to survive failure

Screenshot infrastructure only matters when something goes wrong: a page that hangs, a server that dies, a region that goes dark. Add Screenshots is designed so that none of those events becomes your problem. This page explains exactly what happens to every request you send — no marketing abstractions, just the actual behavior of the platform.

A fleet of 12+ dedicated capture servers, three continents

Every screenshot request enters through our global edge network and is routed to the nearest of three capture regions — the United States, Europe, and Australia / Asia Pacific — or to the specific region you choose. Each region runs at minimum four dedicated, high-capacity capture servers, for a fleet of at least twelve servers worldwide.

These are dedicated machines, not shared serverless functions. That is why Add Screenshots has no concurrency caps and no request throttling on any plan: your burst of a thousand parallel captures runs on reserved capacity instead of competing in a shared queue.

What happens when something fails

• A server is slow: if your capture has not returned within a threshold, a second server automatically starts the same capture in parallel and the fastest result wins. You never wait on a struggling machine.
• A server errors: the request automatically retries across the other servers in the region — transparently, within the same request.
• An entire region is unavailable: the request fails over to another continent. A capture routed to the US can complete in Europe without you changing anything.

All of this happens on every single request, at the routing layer, with no configuration, no retry code on your side, and no extra charge. Failed captures are surfaced with clear response codes and debug details when a target website itself is the problem.

Your data never sits on our servers

Add Screenshots does not store your screenshots. Captures are delivered directly to storage you own — AWS S3, Azure Blob, Google Cloud Storage, Cloudflare R2, FTP/SFTP — or returned in the API response. There is no screenshot archive to breach, and nothing to retain. Read more about our approach on the security page.

A track record, not just a promise

• In production since 20 July 2020 — six years of continuous operation.
• Our largest customer peaked at 2,785,861 screenshots in a single month — roughly 90,000 captures a day — on this infrastructure, alongside thousands of scheduled and real-time jobs for teams worldwide. Read the full story.
• Scale without renegotiation: plans run to 1.5 million screenshots per month self-serve, with custom volume above that.

Frequently asked questions

How reliable is the Add Screenshots API?

Every request runs against a fleet of at least 12 dedicated capture servers across the US, Europe, and Australia / Asia Pacific. Slow servers are raced against a second server, errors retry across the regional fleet, and a regional outage automatically fails over to another continent - all transparently on every request.

Does Add Screenshots throttle concurrent requests?

No. Capture servers are dedicated machines rather than shared serverless functions, so there are no concurrency caps or request throttling on any plan.

How long has Add Screenshots been operating?

Add Screenshots has been in production since 20 July 2020. Its largest customer captures over 1,000,000 screenshots per month on the platform, peaking at 2,785,861 screenshots in a single month.

Where are my screenshots stored?

Add Screenshots does not store screenshots. Captures are delivered directly to storage the customer owns - AWS S3, Azure Blob, Google Cloud Storage, Cloudflare R2, or FTP - or returned in the API response.

See what the platform can do — start with 100 free captures or explore the API docs.