URL inspector
One host and path: what it serves, how fast, with what status mix, over time.
Monitor → Cloudflare → URL Inspector narrows the edge data to a single host and path.
Why host and path
/api/orders on the marketing site and on the API are different endpoints with
the same path. Every inspector view is keyed on both — a path-only view mixes
them, and the mix is invisible.
What it shows
| Requests over time | With selectable granularity |
| Status mix | 2xx / 3xx / 4xx / 5xx, stacked |
| Origin latency | p50 / p95 |
| Cache | Hit ratio |
| Countries and ASNs | Where it is served to |
Path normalisation
Paths with identifiers in them are normalised — /orders/1234 and
/orders/5678 become /orders/:id — so an endpoint is one row rather than ten
thousand.
Brushing the chart
Drag on the chart to narrow the range. The panels below follow. It is the fastest way to go from "something happened around 14:00" to the exact window.
Compare
Compare two endpoints, or the same endpoint across two periods. The second is the one you want after a deploy: same path, yesterday against today.
Saved views
Save an inspector configuration. Saved views are shared within the organisation — an endpoint somebody investigated last month is one click away rather than being reconstructed from memory.
Alert from the inspector
The Create alert button carries the current host, path and filters into a new rule. You are alerting on exactly what you are looking at, rather than retyping the filters into a rule form and getting one of them slightly wrong.
Inline alert detail
Existing alerts for the endpoint are shown in a panel beside the data, so "is this already alerting" does not require a second tab.
Where this behaviour lives: backend/internal/integration/cloudflare_url_inspector.go, frontend/src/app/cloudflare/url-inspector/. If the code and this page disagree, the code is right — please fix the page.
Part of Monitor — Everything that watches something and reports what it saw.