Alerts
Hear about a slow endpoint before a customer does.
An alert watches one route of one service, such as POST /checkout, and fires when its latency, error rate or traffic stays past a threshold. Unhandled checks it every minute, opens an incident, and tells the channels you picked when it fires and when it resolves.
- Seven metrics
- p50, p95, p99, average, errors and traffic
- Checked every minute
- Over a 5 to 30 minute window
- Preview first
- Replays the rule on the last 24 hours
- Snooze and acknowledge
- Holds messages, keeps the incident
See when it would have fired
While you edit the condition, the preview replays it against the endpoint's last 24 hours in 5 minute steps and marks every period the alert would have fired. Move the threshold until it catches the incidents you care about and stays quiet otherwise.
- For latency it suggests a threshold: the value over the whole range times 1.5
- Windows under the minimum request count are marked as ignored, so a quiet hour cannot fire
- Create alert on an endpoint in Requests opens the form with the route filled in
Firing, pending or quiet
The alerts list shows each alert's condition, state and last value in the current environment. Filter it to firing, OK or paused alerts, or search with service: and state:.
- Must breach for keeps a single slow window from firing, and Resolve after keeps a single good one from resolving
- Each minute judges a window that ended 2 minutes earlier, so spans that arrive late still count
- When your services stop sending spans, the minute is skipped, so a gap never fires or resolves an alert
Someone owns the incident
Each firing period opens an incident with its start, its peak value and the reason it resolved. Anyone who can see the project can acknowledge it, assign it and comment on it from the alert page.
- Acknowledging stops reminders. The resolved message goes out if the firing one did
- Snooze for 1 hour, 4 hours, until 9:00 tomorrow in your time zone, or until the incident resolves
- Remind while firing repeats the message every hour, every 4 hours or every day
A payload your pager can key on
Webhook channels get a signed JSON event when an alert fires, reminds, resolves or stops evaluating. The dedupKey stays the same from firing to resolved, so a receiver that bridges to a paging tool can use it as the incident key.
- Every request carries an HMAC-SHA256 signature in the webhook-signature header
- A failed delivery is retried 6 times over about 50 minutes
- A resolved event never arrives before the firing event of the same incident
{
"type": "alert.firing",
"timestamp": "2026-10-25T17:20:00.000Z",
"data": {
"incidentId": "337",
"dedupKey": "alert:8:337",
"ruleId": "8",
"ruleName": "5xx error rate · GET /cart > 1%",
"metric": "server_error_rate",
"comparator": "gt",
"threshold": 1,
"windowMinutes": 30,
"method": "GET",
"route": "/cart",
"serviceName": "storefront-api",
"applicationName": "Storefront",
"environmentName": "production",
"organizationSlug": "acme",
"alertUrl": "https://…/o/acme/projects/storefront/alerts/8?env=production",
"endpointUrl": "https://…/o/acme/projects/storefront/requests/detail?…",
"slowestTracesUrl": "https://…/o/acme/projects/storefront/traces?…",
"startedAt": "2026-10-25T17:20:00.000Z",
"value": 13.64,
"samples": 22
}
}Sends to
Where alerts go
- SlackAlerts that fire within 20 seconds of each other arrive as one message.
- DiscordA channel webhook, grouped the same way as Slack.
- WebhooksSigned JSON for firing, reminder, resolved and error events.
- InboxWith App members on, everyone on the project sees it in the app.
- Email[Alert] and [Resolved] emails for members with Endpoint alerts on.
- MCP serverAgents list, preview, create, pause and snooze alerts.
Questions
Try it on your own stack.
Every feature is on every plan, priced by the telemetry you send.