Live platform health checks, uptime monitoring, and how to get a failed capture diagnosed.

Status page

ssnap.cc/status reports live health, checked on request rather than served from a cached dashboard. That distinction matters: the page tells you what is true now, not what a background job last recorded.

Check	What it proves
Database	Connection and a live query succeed.
Cache	A value can be written and read back.
Browser engine	A real test page renders, not merely that a binary is installed.
Queue	The async capture backlog is within normal depth.
Capture	Recent success rate across real captures.

Each check reports operational, degraded or down, rolling up to an overall state. The browser render check is cached for a minute, since the probe itself costs about a second.

Reading a degraded state

The checks map onto failure modes you can see from the outside:

Browser engine degraded → expect capture_failed on synchronous captures. Retrying with backoff is reasonable.
Queue degraded → synchronous captures are fine; callback_url deliveries arrive late. Do not re-queue, or you will pay for the capture twice.
Capture success rate degraded → renders are completing but failing more often than usual. Check your own target url first; a single broken page skews nothing, but a site that started blocking datacentre traffic looks identical from your side.

Uptime monitoring

There is a lightweight GET /up endpoint for external monitors. It is cheap, so a one-minute interval is fine.

Do not point a monitor at the capture endpoint itself. Every probe would be a real capture: it consumes a monthly slot, counts against your per-minute rate limit, and costs a browser launch. If you want to monitor captures specifically, do it once every few minutes against a static page, with a long cache_ttl so most probes are free cache hits — see Screenshot caching.

Getting help

Channel	Where
Email	[email protected]
Contact form	ssnap.cc/contact
In-app	The feedback control in your dashboard

Reporting a failed capture

Include these five things and the problem is usually reproducible without a back-and-forth:

The target url, exactly as sent.
The full parameter set, including the ones you think are irrelevant — delay and network_idle frequently are not.
The HTTP status and the code from the body. See API error codes.
Roughly when it happened, with a timezone.
Whether it is consistent or intermittent, and whether the url renders in your own browser.

Worth checking before you write

A large share of reported failures resolve to one of these:

A selector that no longer matches, which fails the render rather than falling back.
A target that requires a login, or has started refusing datacentre IP ranges — the capture is what an anonymous visitor sees.
A private or internal url, refused by URL restrictions.
quota_exceeded mistaken for rate_limit_exceeded, since both answer 429.
A stale signed url: they expire 24 hours after the response, and the stored file is itself subject to Storage and retention.

Security reports

Security issues go to [email protected] directly rather than through the in-app form. Include reproduction steps and give us a chance to fix it before publishing.

Status and support