Know why an alert fired, or why it didn't

Test a rule against your own history before you save it. Once it is live, every evaluation is logged with the value it saw.

The surface

Preview before you save

The preview uses the same logic as the real alert, so it shows exactly when it would have fired.

/alerts rule high-error-rate · critical

In motion

Rules run every minute. Two bad checks in a row open an incident and notify you. Two good ones close it.

alerts · rule high-error-rate LIVE

rule critical

signalerror_rate

conditionerror_rate > 5%

window5 min · 2 consecutive

group byservice.name

OK FIRING breaches 0/2 1/2 2/2 · eval every 60s

#alerts via slack

Maple APP 14:32

High error rate — checkout

error_rate at 8.4% · threshold 5% · window 5 min

service checkout · env production · severity critical

View in Maple Chat

delivered · 200 · attempt 1/5

slackdiscordtelegrampagerdutyemailwebhookhazel

evaluated every 60s · auto-resolve after 2 healthy renotify 30m while open

More screens

What it does

Alert on anything: Error rate, latency, Apdex and throughput built in. Or alert on any query over traces, logs and metrics, or raw SQL.
Same logic as the live rule: If the preview says it would have fired twice last Tuesday, it would have.
One rule, many incidents: Group by service or any attribute, and each group alerts on its own. One bad service can't hide in an average.
Every check logged: Each check records its value and result, including failures. If a rule stays quiet, you can see why.
Delivery with retries: Automatic retries, custom templates and reminders while an incident is open. Slack, Discord, Telegram, PagerDuty, email, Hazel or any webhook.

One endpoint, one key. Traces, logs, metrics and sessions, linked from the first request.