Requests

The Requests view is the raw traffic ledger for an environment: one row per HTTP request the site served, with its status code, latency, method, and path. It’s where you go to answer “is anything throwing errors right now?” or “which 404s are my visitors actually hitting?” — and it streams live, so you can watch traffic as it happens.

The per-request view

Open an environment and go to Insights → Requests. Each request shows:

• Status code — 2xx, 3xx, 4xx, 5xx, color-coded so failures stand out.
• Latency — how long the response took, with the slow tail visible rather than averaged away.
• Method and path — GET /checkout/, POST /wp-login.php, and so on.

The Insights → Requests view for a production environment, live-streaming rows with a colored status-code column (a run of green 200s, a red 500, several yellow 404s), a latency column, and method + path, newest at the top.

You can filter to a status class — pin to 5xx to watch only server errors, or 4xx to audit what’s missing — and to a time window to line traffic up with a deploy.

The live request stream

The view streams over server-sent events (SSE), so requests appear as the site serves them. Two things this is good for:

1. A live 404 / error tail. Leave Requests open filtered to 4xx/5xx right after a deploy. If a release broke a route, the errors scroll in immediately and you can roll back before it spreads. See promote and rollback.
2. Confirming a fix. Reproduce the request and watch it flip from 500 to 200 in real time, without digging through after-the-fact logs.

From a request to the why

Requests tells you what happened; the other views tell you why:

• A request is slow → open its trace to see which span (database, cache, outbound call) ate the time.
• A request errored → check the logs for the same path and window to read the stack trace.

Blocked traffic lives under Security

This is deliberate and worth knowing: blocked and malicious requests do not appear in Requests. A request stopped by the WAF, the rate limiter, Patchstack virtual patching, a login lockout, or the CrowdSec edge is surfaced under Security → Blocks, not mixed into your normal traffic.

Why they're separated

Folding blocked attack traffic into Requests would bury your real 404s and 500s under a flood of probes for /wp-config.php.bak and brute-force login attempts. Keeping the two apart means Requests reflects the traffic your application actually handled, and Security → Blocks reflects what the platform stopped before it got there — each view stays readable.

So if you’re hunting a genuine application error, Requests is the right place; if you’re investigating an attack or a rate-limit complaint, go to Security → Blocks.

Reading requests over the API

The request stream and the per-request history are available under the observability:read scope, paginated by cursor. See the observability API resource for parameters and the SSE streaming endpoint.

Next steps

Security → BlocksEvery request the platform blocked — WAF, rate limit, Patchstack, lockout, CrowdSec.

LogsThe error message behind a failing request.

TracesThe span-by-span breakdown behind a slow request.