Alerts: latency, errors, function failures and connections
Get an email or a signed webhook when your API gets slow, server errors climb, functions fail or your database runs out of connections — checked every minute, with a plan-based number of rules.
An alert rule watches one number over a window — say, the p95 latency of GET /rest/v1/orders over 15 minutes — and fires when it goes over your threshold. The project team gets an email (and an entry in the console's notification feed); a webhook gets a signed POST. When the number is back under the threshold for two checks in a row, the alert resolves and you hear about that too. Manage rules in Observability → Alerts.
#What you can alert on
| Metric | Unit | Scope | Measured from |
|---|---|---|---|
latency_p95_ms, latency_p99_ms | ms | The whole project or one route | Gateway request latency (the same data as Routes) |
error_rate | % of requests answered 5xx | The whole project or one route | Gateway responses |
function_failures | Failed runs in the window | Every function or one | Function runs that end failed, timed out or dead-lettered |
db_connections | Connections | The project's database | The most connections the database held in the window (sampled every minute) |
- Windows: 5, 10, 15, 30 or 60 minutes. Route alerts — and every request alert on plans with 15-minute metrics (Free) — need 15 minutes or more.
- Request alerts ignore windows with fewer than
min_requestsrequests (default 20), so one slow request at 3 a.m. doesn't page anyone. - With no traffic at all, a firing alert stays firing (an outage that stops all requests must not look resolved) and an OK one shows No data.
- Route alerts cover every environment, or the ones you name (
env, comma-separated ids;main= requests that named none).
#Create an alert
sov alerts create --metric latency_p95_ms --threshold 800 --target "GET /rest/v1/orders" --window 15
sov alerts create --metric error_rate --threshold 2 --window 10 --webhook https://hooks.example.com/sovaria
sov alerts list
sov alerts test <rule-id>Creating, changing and deleting rules needs a project owner or admin (or the service key); anyone on the team can read them. Test measures the rule now, says whether it would fire, and sends an alert.test to its webhook (no email).
#Webhooks
Webhook URLs must be public HTTPS hosts. Each delivery is a POST of JSON with X-Sovaria-Event (alert.firing, alert.resolved or alert.test) and X-Sovaria-Signature: sha256=<hex>, an HMAC-SHA256 of the raw body with the rule's signing secret (shown once, when you add the webhook). Answer with any 2xx.
{
"type": "alert.firing",
"project_id": "f0c3e9a2-1b4d-4e7f-8a6c-2d9b5e3f1a07",
"alert": { "id": "alr_3f9a1c0b7e2d4a6f", "name": "Slow orders", "metric": "latency_p95_ms", "threshold": 800,
"unit": "ms", "window_minutes": 15, "target": "GET /rest/v1/orders", "env": null },
"value": 2500,
"since": 1792396800.0,
"sent_at": 1792396801.4,
"console_path": "/project/f0c3e9a2-…/observability/alerts"
}#Plans
| Free | Pro | Ultra | Team | Enterprise | |
|---|---|---|---|---|---|
| Alert rules per project (latency, errors, function failures, connections) | — | 10 | 25 | 50 | 200 |
When a project has more rules than its plan allows (after a downgrade), the oldest ones keep running and the rest wait, marked Over plan limit; nothing is deleted. Sovaria support can pause a rule that misbehaves (for example a webhook that keeps failing); only support can resume it.