Metrics & SLOs — Dashboard Docs

Metrics dashboard

The Metrics page (/account/observability/metrics) is the traffic analytics dashboard for your account. It aggregates every request the edge served and renders time series, percentiles, top-endpoint rankings, status-code and method breakdowns, geography, and SLO health — all over a window you choose.

Time range & scope

Pick a preset window (1h, 24h, 7d, 30d, …) or a custom from/to range. Filter to a single endpoint with the per-endpoint dropdown, which is pre-populated server-side from your endpoint list so it renders without a round-trip. The default window is the last 24 hours.

What the page shows

Summary KPIs — total requests, average / median / p95 / p99 response time, error rate, total bandwidth (in and out), unique visitors, and peak requests-per-hour. Each KPI carries a period-over-period change figure so you can spot a regression at a glance.
Time series — requests, response times, bandwidth (bytes in vs out), and errors (4xx vs 5xx) bucketed across the window.
Status codes — 2xx / 3xx / 4xx / 5xx split with an overall success rate.
Top endpoints — ranked separately by requests, response time, errors, and bandwidth.
Methods & geography — HTTP method distribution and a top-countries map.

Error attribution: 5xx responses are attributed to either the origin or the edge, so a spike in errors tells you whether your backend failed or whether the edge generated the error (offline origin, timeouts, etc.).

Real-time view

The metrics page includes a live mode that streams fresh data every few seconds over Server-Sent Events, showing the most recent traffic (last ~5 minutes) without a manual refresh. Use it to watch a deploy land, confirm traffic is flowing through a new endpoint, or keep an eye on an incident in progress.

You can also compare endpoints side by side — select multiple endpoints and the page overlays their series so you can see which one is driving load or errors.

Threshold alerts

Threshold alerts (/account/observability/alerts) watch a metric over a rolling window and notify you when it crosses a threshold you set. The feature is plan-gated behind the metric_alerts entitlement; without it the create/edit flows redirect to an upgrade prompt.

Creating a rule

Click New Alert to open the full-page authoring form. A rule is defined by:

Field	What it does
Metric	Request rate (req/s), error-rate %, p95 latency (ms), p99 latency (ms), bandwidth in (bytes/s), or bandwidth out (bytes/s).
Operator & threshold	Compare the observed value against your threshold with `>`, `>=`, `<`, or `<=`.
Window	The rolling window the metric is computed over, in seconds. Must be between 60 (1 minute) and 86 400 (24 hours).
Cooldown	How long to wait after firing before the rule can fire again, in seconds (0 to 86 400). Stops a flapping metric from spamming you.
Endpoint	Scope the rule to one endpoint, or leave it unset to span all of your endpoints.
Enabled	Arm or disarm the rule without deleting it.

Notification channels

Every rule needs at least one notification channel. Add as many as you like:

Email — target is the recipient address.
Webhook — target is a destination URL; the optional secret is the HMAC-SHA256 key used to sign the request body with an X-Ngris-Signature header.
Slack — target is a Slack Incoming Webhook URL.
Discord — target is a Discord Webhook URL.

Slack and Discord carry no secret — the webhook URL itself is the credential, so treat it as sensitive.

Preview & test before you arm

Two helpers let you author with confidence instead of blind:

Preview — computes the metric's current value over the rule's window without creating the rule, using the exact same formula the evaluator runs. Set thresholds against real data, not guesses.
Send test — delivers one sample notification to a single channel synchronously and reports pass/fail inline, so you can confirm a webhook/Slack/Discord URL or email address actually receives the alert before arming the rule. Webhook targets are delivered through an SSRF-safe client and cannot reach internal addresses.

Managing rules & the events log

From the list page you can toggle, edit, and delete rules. Each rule has an events log recording when it fired and the deliveries it triggered, so you can audit alert history and confirm notifications went out.

AI Generate: The Generate with AI button drafts a batch of alert rules from a plain-language description (“page me if error rate goes above 2% or p95 latency exceeds 800ms”). Generated rules are created as drafts you review before arming — the magic-wand button creates; editing happens through the chat widget.

SLO targets & burn rate

The metrics page includes an SLI/SLO tab that tracks how well your service is meeting reliability targets and how fast it is consuming its error budget. Targets are per-account configurable; with no custom values the platform defaults apply.

Configuring targets

Edit your account's SLO targets from the SLI/SLO tab:

Availability target — the success-rate objective as a percentage (e.g. 99.90).
Latency threshold — the “fast” boundary in milliseconds; requests faster than this count toward the latency SLI.
Latency target percent — the percentage of requests that must come in under the latency threshold.

What the SLO panel shows

Availability — the measured success rate vs your target.
Error budget — total, consumed, and remaining (as a percentage), so you know how much room you have left before missing the SLO.
Burn rate — how fast you are spending the error budget (e.g. 1.5×). A burn-down chart plots remaining budget across the window, and a latency-SLI chart tracks the fast-request percentage.
SLI definitions — each SLI lists its definition, objective, current compliance, and status (Met, At Risk, or Violated).

Tip: Pair SLO targets with threshold alerts — a burn-rate or error-rate alert turns the SLO from a dashboard you have to remember to check into something that pages you when the budget is at risk.