Alert rules watch one metric type for a client app and POST a webhook when it crosses a threshold within a rolling window.
Creating a rule#
From the Alerts tab, click New alert rule and set:
- Metric type — exceptions, jank events, or tap-cluster (rage/dead/error tap) events.
- Threshold — how many occurrences trigger the alert.
- Rolling window (seconds) — the time span the threshold is measured over.
- Webhook URL — where the alert gets POSTed.
A rule fires at most once per window (a cooldown, not a per-occurrence spam) — once it fires, it won't fire again until the window has passed without a re-breach.
Using Slack#
Paste a Slack Incoming Webhook URL directly into the Webhook URL field — nothing else to configure. The payload always includes a top-level text field with a human-readable summary, which is the one field Slack's incoming-webhook format requires; any other fields in the payload are additional structured data for non-Slack receivers and don't interfere with how Slack renders the message.
Using a generic webhook#
Any endpoint that accepts a JSON POST works. The body shape is:
{
"text": "Alert fired: 5 exceptions in the last 60s",
"metricType": "exceptions",
"count": 5,
"threshold": 4
}
text is a ready-to-display summary; the remaining fields give a programmatic receiver the structured data to act on instead of parsing
text back apart.
Email (recipient field exists, not live yet)#
Every rule has an optional Recipient email field — but setting it has no effect right now. Sending it requires real SMTP credentials configured on the backend, which don't exist yet in this deployment. The webhook channel is unaffected either way and keeps working normally, with or without a recipient email set.
When SMTP credentials are configured, a rule with a recipient email fires both channels independently — a webhook failure doesn't block the email attempt, or vice versa.