Alerts and SLOs
Alerts tell you when something needs attention, so nobody has to watch a dashboard. Each rule watches your event stream and notifies a channel you choose.
Add rules in the Alerts tab with New alert.
Rule types
| Rule | Fires when | Checked |
|---|---|---|
| Threshold | Events matching your query reach a count within a window | Every minute |
| New issue | A problem is seen for the first time | As it happens |
| Regression | An issue you resolved comes back | As it happens |
The last two need no query, and catch what a threshold misses: something new appearing, and something you thought was fixed returning.
Setting up a threshold
NametextrequiredWhat the notification calls it, such as "5xx error spike".
Match querysearch queryOnly events matching this expression count, such as statusCode >= 500. Threshold rules only.
ThresholdnumberHow many matching events within the window fire it, from 1.
WindowminutesThe rolling look-back, from 1 minute.
ChannelSlack or webhookrequiredWhere it goes, with the address to post to. See where alerts go.
CooldownminutesHow long to stay quiet after it fires. 0 notifies every time.
The query is the same one you'd type in search, so get it returning the right events there before saving it as a rule.
level = 'error' AND path LIKE '/v1/checkout%' AND statusCode >= 500Where alerts go
Slack
Paste an incoming webhook URL. The message names the rule and kind, and for thresholds, the value against its limit.
Webhook
Octri sends this JSON to any endpoint you own:
{
"type": "alert",
"rule": "5xx error spike",
"kind": "threshold",
"message": "...",
"value": 34,
"threshold": 20,
"issue": null,
"firedAt": "2026-11-04T09:30:00.000Z"
}For a new issue or a regression, issue names the issue, and value and threshold are null.
Each delivery is a single attempt with a 5-second timeout. If your endpoint is down at that moment, that alert isn't retried, so point it at something reliable.
Testing a rule
Evaluate now checks your threshold rules straight away, instead of waiting for the next minute. From the CLI, see alert commands.
Pause a rule to stop it without deleting it.
Rules that get ignored
An alert nobody acts on trains people to ignore all of them.
Alert on what someone would act on. If nobody would get up for it, make it a report.
Set the cooldown longer than a rollback takes. Most alert storms are one bad release, and a long cooldown turns forty messages into two.
Scope queries to what matters. path LIKE '/v1/checkout%' beats every error everywhere.
Exclude known noise with your query, such as health checks.
Service level objectives
An SLO is a target for one transaction, and you set it in the Performance tab. There you can see a transaction breach its target and how fast it's using up its error budget. From the CLI, octri monitoring slos sets targets, and --fail exits with an error on a breach, so a deploy job can check them.
SLOs show up in the Performance tab, and there's no burn-rate alert rule. To be told when one is at risk, add a threshold rule on the same transaction, with a query such as path = '/v1/checkout' AND statusCode >= 500.
Choosing a target
A target should be the number you'd really roll back a release over. 99.9% isn't automatically right, and a target nobody defends is decoration. Start from what the endpoint does today, then tighten it.
Alerts and releases
Set your release on every event, so an alert leads straight to the deploy that caused it. Regression alerts are most useful right after a deploy.