Observability overview

Every environment on managed.dev is wired for observability the moment it is provisioned — production, staging, and every preview. There is nothing to install, no agent to configure, and no separate dashboard to log into. You push a branch, the environment comes up, and its telemetry starts flowing into the dashboard alongside everything else.

This matters because environments are first-class here. A preview environment for feature/checkout is not a second-class copy — it emits the same metrics, logs, and traces as production, so you can spot a regression on a branch before it ever reaches your users.

What gets measured

Every site and every environment reports five streams of telemetry:

• Web vitals & real-user monitoring — Core Web Vitals and p95 latency from actual visitors, broken down per page. See Web Vitals & RUM.
• Logs — application and access logs, tailing live, filterable by severity and time. See Logs.
• Traces — distributed request traces and the slowlog, spanning FrankenPHP, cache, and database. See Traces.
• Requests — the per-request view and a live request stream: status codes, latency, and paths. See Requests.
• Security blocks — requests stopped by the WAF, rate limiter, Patchstack, login lockout, or the CrowdSec edge. These live under Security → Blocks, deliberately separate from Requests.

Everything is scoped to a team and an environment, so an observer on one project never sees another team’s traffic.

The meter and the ledger

managed.dev keeps two kinds of data, and the distinction explains why observability behaves the way it does.

The ledger is Postgres: authoritative, mutable state — which sites exist, who owns them, what plan a team is on, the current status of a deployment. When you ask “is this true right now?”, you are reading the ledger.

The meter is ClickHouse: append-only facts you scan rather than mutate — every request, every trace span, every web-vitals beacon, every block. Telemetry is written once and never updated. That is what makes it cheap to fan out across billions of rows and answer “what was the p95 latency on /checkout last Tuesday?” in milliseconds.

Why it's structured this way

Mixing high-volume, write-once telemetry into your authoritative state store makes both slow and expensive. Keeping the meter (ClickHouse) separate from the ledger (Postgres) is what lets observability stay fast and stay enabled on every plan, not just the expensive ones.

Privacy and the PII hard-cut

Telemetry is built to answer performance and reliability questions, not to profile your visitors. Identifying data is cut at a hard floor before anything is stored: request bodies are not retained, and sensitive headers and query parameters are dropped at ingest rather than redacted after the fact. There is no “raw” copy sitting behind the cut that an operator could reach for later — the data simply is not collected.

This floor is the same in every environment, so a preview environment is no more revealing than production.

Reading it through the API

Everything you see in the dashboard is also queryable through the public API under the observability:read scope — useful for piping metrics into your own dashboards or alerting. See the observability API resource.

Next steps

Web Vitals & RUMCore Web Vitals and p95 latency from real visitors, per page.

LogsLive-tail application and access logs, filtered by severity and time.

TracesPer-request timings across FrankenPHP, cache, and database — find the slow query.

RequestsThe per-request view and live request stream: status, latency, paths.