Cache-busting magic variables for uptime checks

Published on May 18, 2026 by Mattias Geniar

Over the weekend, my own site went down and Oh Dear didn't catch it. The origin server had fallen over, but Cloudflare happily kept serving the cached HTML. Everything looked fine from the outside. Embarrassing. 😬

Scratching our own itch here, we just shipped magic variables: short placeholders you can drop into your monitor URL, request headers, or POST payload. Right before each check, we replace them with fresh values, so every request is unique enough to slip past any cache and actually hit your origin.

This is fully opt-in. Nothing changes for any of your existing monitors until you explicitly add a variable somewhere. That's intentional: some sites want a random query argument, others would rather pass a fresh value in a header so the URL stays clean, and a few only want it on a single endpoint. You decide where it goes.

We're starting with four variables. We deliberately want to see how you use them before adding more, so if one of these almost fits but not quite, let us know.

Variable Expands to Good for
$OH_DEAR_TIMESTAMP 20260518091245123 Cache-buster query strings
$OH_DEAR_ISO8601 2026-05-18T09:12:45Z Signed URLs, Date headers
$OH_DEAR_UUID fd5735c5-134a-4e3c-a425-1b0794103df0 Idempotency keys, request IDs
$OH_DEAR_RANDOM aB3xY7kQ Path-segment cache-busters

The most common use case is a query-string cache-buster. A monitor URL like this:

https://your-site.com/?cb=$OH_DEAR_TIMESTAMP

Gets rewritten right before we check it:

https://your-site.com/?cb=20260518091245123

Cloudflare sees a fresh URL every minute, has no cached copy for it, and forwards the request to your origin. If your origin is down, we see it.

Within a single check, the same variable always expands to the same value. So if you put $OH_DEAR_UUID in both the URL and an X-Request-ID header, they'll match, and you can correlate the request on your side. Handy when you're digging through logs trying to find the exact probe that failed.

The expanded URL is stored with the run, so when you open the report page for a historical check, you see exactly which URL we requested. No guessing, even if you edit the monitor URL later.

Other ways to bypass the cache #

Magic variables are the easiest path, but they're not the only one. Depending on how your stack is wired up, one of these might fit better, or you can combine them.

Monitor the origin directly with a custom Host header

Instead of resolving the hostname through DNS (which sends you to the CDN), put the origin server's IP address straight in the monitor URL and override the Host header in your monitor's request settings. The request reaches the origin without ever touching the cache, but your application still sees the right virtual host and serves the correct site.

In Oh Dear, that's:

  • Monitor URL: https://203.0.113.10/health
  • Request header: Host: www.your-site.com

A successful check now tells you with certainty that your origin is up. The trade-off is that you're no longer measuring what visitors actually experience through the CDN, so it's worth pairing this with a regular check on the public hostname.

The FAQ on monitoring the origin server walks through this in more detail.

Add a bypass rule at the edge

If you'd rather keep monitoring the public hostname, tell your edge layer to skip the cache for Oh Dear's requests. Our checker identifies itself with a User-Agent that starts with OhDear.app, which makes it easy to match.

In Varnish, a few lines of VCL in vcl_recv do the trick:

sub vcl_recv {
    if (req.http.User-Agent ~ "OhDear.app") {
        return (pass);
    }
}

return (pass) tells Varnish to forward the request to the backend without consulting or populating the cache, so every Oh Dear probe hits your origin directly.

Cloudflare has the same idea with a Cache Rule: match (http.user_agent contains "OhDear.app") and set the cache eligibility to Bypass cache. Same effect, different dashboard.

If you're on Varnish and want more background on how we use it ourselves, we've written about keeping your Varnish cache warm with Oh Dear and a behind-the-scenes look at tuning our own status pages during a DDoS.

Combine a magic variable with an edge bypass

For the strongest signal, use both: a magic variable makes every request unique enough that no cache could serve a stale copy by accident, and the edge rule guarantees the request hits your origin even if the cache layer changes behavior later.

Try it out #

Drop a magic variable into your monitor's HTTP settings to give it a spin. Full details on each variable are in the docs.

Start using Oh Dear today!

  • Access to all features
  • Cancel anytime
  • No credit card required
  • First 10 days free

More updates

Want to get started? We offer a no-strings-attached 10 day trial. No credit card required.

Start monitoring

You're all set in
less than a minute!