Watching the origin, not the cached copy

Your CDN can be serving a healthy page long after the server stopped producing one

The problem

Caching layers exist to put distance between visitors and the origin server, and they do it well. That same distance hides the origin from anyone trying to monitor it. A check that goes through the CDN sees what the CDN has stored, which may be a page captured before anything went wrong. Content can be defaced at the origin and the cached copy will keep serving normally until it expires. The reverse happens too: the application starts returning errors and the edge keeps things looking fine for long enough that nobody escalates.

The usual answer

By whitelisting SentryPage's request header or IP address, the check bypasses infrastructure caching and reaches the origin. What comes back is what the server is actually producing right now, which makes the monitoring useful beyond defacement. Downtime and application errors show up in the same stream, on the same interval, before the cache expires and the public sees them.

How we approach it

Captures are retained for up to three months, and every alert stays in the history table. That covers the question that always follows an incident and is usually impossible to answer: what did this page look like at this time, and when did it change. Access to all of it is controlled with user roles and multi-factor authentication, and the domains treated as legitimate are set per organisation.

What changes

There is a window between something going wrong and anyone outside noticing it, and this is the work of using that window. The team gets to restore the page, flush the cache and confirm what happened from the retained captures, rather than reconstructing the timeline afterwards from memory.