---
type: Article
title: "Uncacheable Path Monitoring"
description: "A cached check can report green while your origin is down. A rotating token forces every probe to a real round-trip, so an outage surfaces immediately."
resource: "https://snmp-monitoring.com/http-monitoring/uncacheable-path/"
tags: [http-monitoring, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Uncacheable Path Monitoring

Here's a trap that catches a lot of people: your monitor reports a green, sub-50ms response, but real users are staring at an error. The check never reached your server at all — a CDN edge node answered it from cache. Bypass cache monitoring is the fix. Instead of hitting a URL a cache can recognise and short-circuit, you make every request unique so it has to travel all the way to the origin and prove the application is genuinely alive. This page explains why cached checks lie, how a rotating token forces a real round-trip, and how to set uncacheable url monitoring up in a couple of minutes.

## What is Uncacheable Path Monitoring

Uncacheable path monitoring is the practice of pointing your availability check at a URL that no cache will ever serve a stored copy of, so each probe exercises the full path down to your origin server and back. The point isn't to be difficult. It's to make sure a "200 OK" actually means the origin returned 200, not that a reverse proxy, a CDN, or the browser cache had something lying around from an hour ago.

You want this any time there's a caching layer between the outside world and your app — which, these days, is almost always. A CDN in front of a marketing site, Varnish ahead of an API, even aggressive `Cache-Control` headers can all make a dead origin look healthy. The moment your monitoring can be satisfied by cached bytes, it stops measuring what you care about. Bypass cache monitoring closes that gap by guaranteeing the request is a cache miss every single time, so an origin outage surfaces immediately instead of hiding behind a stale hit.

## How it works

Caches key their stored responses on the request — mostly the URL, sometimes headers. Ask for the exact same URL twice and a well-behaved cache is entitled to answer the second one itself. So the whole game is making the URL different on every request. The cleanest way is a rotating token: a placeholder in the URL that resolves to a fresh, random value each time the check runs.

ostr.io implements this with a `{{rand}}` placeholder. Drop it anywhere in the monitored URL and it expands to a unique string per request, forcing a cache miss and a genuine origin round-trip. It can appear more than once in a single URL if you want extra entropy across path and query.

| Technique | Cache miss? | Trade-off |
|---|---|---|
| Static URL | No — cache may serve it | Fast, but can report a false healthy |
| `Cache-Control: no-cache` header | Sometimes ignored | Not all intermediaries honour it |
| Random query string (`?_={{rand}}`) | Usually | Some CDNs strip or ignore query keys |
| Random path segment (`/health/{{rand}}`) | Yes | Needs a route that accepts the token |
| `{{rand}}` used multiple times | Yes | Maximum entropy, always a miss |

The random query string approach is the everyday choice — `?nocache={{rand}}` on the end of any URL is enough for most CDNs. When a cache is configured to ignore query parameters, move the token into the path instead, so the whole URI changes and there's nothing left for the edge to match against.

It helps to picture the request's journey. A normal check travels browser-like toward your origin, but the first cache with a matching key intercepts it and answers on the origin's behalf — fast, and completely blind to whether the origin is even running. A unique URL has no match anywhere along that chain, so every proxy, edge node, and shared cache is obliged to pass it through. The response you measure is unambiguously your application's. That's the difference between timing a cache lookup and timing your actual stack, and it's why a rotating token beats every header-based trick that asks a cache politely to opt out.

## Setup

Setting up uncacheable url monitoring is mostly about choosing where the token goes. The steps below assume an ostr.io HTTP/HTTPS check.

1. **Pick the endpoint you actually want to test.** A lightweight health route that touches your real stack — database, cache, dependencies — is far more useful than a static file that proves nothing.
2. **Insert the `{{rand}}` placeholder.** Append it as a query parameter for the simplest case: `https://example.com/health?nocache={{rand}}`. Every check now sends a different value.
3. **Escalate to a path token if a query isn't enough.** Some CDNs cache by path only. Route a wildcard like `https://example.com/health/{{rand}}` to your health handler so the entire path is unique.
4. **Use the placeholder more than once for stubborn caches:** `https://example.com/{{rand}}/health?v={{rand}}`. Two independent random values leave nothing consistent to key on.
5. **Confirm the origin sees the request.** Watch your origin access log while the check runs — you should see a fresh entry with a changing token on each poll, not a gap where the CDN answered.
6. **Set your alert thresholds** on response time and status code, and add the same endpoint at two frequencies for a fuller picture of behaviour under load.

One caution: keep the random token in a part of the URL your application safely ignores, or route it to a handler that expects it. You're forcing a cache miss, not trying to generate 404s.

## Screenshot walkthrough

![ostr.io custom path monitoring configuration showing a URL with the {{rand}} placeholder inserted to bypass cache on an HTTP endpoint](https://snmp-monitoring.com/img/ostrio/custom-path.webp)

The screenshot shows the ostr.io endpoint configuration where the `{{rand}}` placeholder lives inside the monitored URL. In the path or query field you type your target address and drop `{{rand}}` wherever you need a cache-busting value — the interface treats it as a template that's expanded fresh on every scheduled check. What the UI makes obvious is that this is a per-request substitution, not a one-time random value baked in at save time: each poll gets its own token. That's the whole difference between a check that measures your origin and one that measures your CDN's memory. The panel sits alongside the standard availability fields — response time, status code, uptime — so a single configured endpoint gives you cache-bypassing checks and normal [availability monitoring](/http-monitoring/availability-monitoring.md) at once, with the confidence that green means the origin really answered.

## Use cases

Bypass cache monitoring earns its place in plenty of real setups:

- **CDN-fronted sites.** When Cloudflare, Fastly, or CloudFront sits in front of your origin, a static check can be answered at the edge. A rotating token forces the request past it to confirm the origin lives.
- **Reverse-proxy caches.** Varnish or an Nginx `proxy_cache` layer will happily serve a cached health page while the app behind it is on fire. Uncacheable url monitoring sees through that.
- **Stale-while-revalidate configs.** Aggressive caching that serves old content during revalidation can mask a backend that's failing to revalidate at all.
- **API health checks.** For an API where a cached `{"status":"ok"}` would be dangerously misleading, a unique URI guarantees the handler actually executed.
- **Post-deploy verification.** Right after a release, you want proof the new origin is answering — not a cached response from the version you just replaced.
- **Multi-region edges.** With many edge locations, each could hold its own cached copy; a per-request token sidesteps all of them uniformly.

![Diagram: the rand placeholder generating a unique URI per request to bypass caches](https://snmp-monitoring.com/img/http/uncacheable-path-diagram.webp)

## FAQ

**What does the `{{rand}}` placeholder actually do?**
It's a template token that expands to a unique random string on every single check. Because the resulting URL is different each time, no cache can match it against a stored response, so the request is forced through to your origin. It can appear multiple times in one URL for extra entropy.

**Won't a `no-cache` header do the same job?**
Not reliably. `Cache-Control: no-cache` and `no-store` are requests, and not every proxy or CDN honours them — some are configured to ignore client cache directives entirely. Changing the URL itself is far harder for an intermediary to override, which is why a random token is the dependable approach.

**Query string or path — which should I use?**
Start with a query parameter like `?nocache={{rand}}`; it's the least intrusive. If your CDN is set to cache by path and strip query keys, move the token into the path so the whole URI changes. When in doubt, use it in both places.

**Does this add load to my origin?**
A little, by design — every check becomes a real request instead of a cache hit. It's negligible at normal polling intervals, and it's the entire point: you're trading a trivial amount of origin traffic for honest health data.

## Conclusion

Bypass cache monitoring exists because a cached "OK" is worse than no check at all — it's a lie that lets you sleep through an outage. Making the URL unique on every request, with a `{{rand}}` placeholder in the query or the path, forces each probe to reach your origin and report the truth. Run those checks from outside your network for real [double durability](/monitoring/double-durability.md), and a stale edge can't fool you. [ostr.io Monitoring](https://ostr.io/service/monitoring) supports the `{{rand}}` token natively and fires real-time email and SMS alerts the moment the origin genuinely fails. Wire it up from the [HTTP monitoring hub](/http-monitoring/index.md) or the [site home](/index.md).