Alerts
Rules watch a number and notify when it crosses a line you set. Incidents are the record of a rule having fired.
The three rule typeslink
A rule compares one value against a threshold using one of four operators: greater than, greater or equal, less than, or less or equal. There are three things it can measure.
- Issue count - how many issues currently hold a given status (unresolved by default). Fires while the count sits past your threshold.
- Metric threshold - the latest reported value of a named metric you send over OTLP.
- Device error rate (mobile) - errors per session for a device model, as a percentage, over a rolling window of 1 to 90 days. Pin it to one model (
TECNO KC8) or leave the model empty to watch every device and fire on the worst one. A minimum sessions floor (default 5) stops a single crashed session on a single phone from paging you. The incident names the device: TECNO KC8 on android, error rate 12% over 1d, 6 errors in 50 sessions.
Issue count measures a standing total, not arrivals. A rule set to "greater than 10 unresolved" keeps firing while 11 remain open. It is a backlog alarm, not a new-issue notification.
Scoping a rulelink
- Environment - leave it unset to watch every environment, or pin it to production so staging cannot page anyone.
- Severity - carried onto the incident, for triage.
- Webhook URL - where the notification is delivered. The payload and signature scheme are documented in BugWatch alert webhooks.
- Enabled - disabled rules are skipped entirely by the evaluator.
Evaluationlink
Enabled rules are evaluated on a repeating pass in the background, not on every incoming event. Each rule records when it was last evaluated and last fired, so a rule that has never fired is visibly distinguishable from one that is not running.
A metric rule whose metric has reported no value at all does not fire, including for a "less than" threshold. Absent data is treated as unknown, not as zero.
Incidentslink
A fired rule opens an incident holding the rule name, the value that tripped it and the comparison that failed. Incidents move through open, acknowledged and resolved. Acknowledge to show someone is on it, resolve when the underlying condition is genuinely back to normal.
Keeping alerts trustedlink
- Alert on conditions someone would act on immediately. Everything else belongs in Issues.
- Ignore known-noisy issues rather than raising the threshold until the rule is meaningless.
- A rule that fires constantly gets filtered out by its recipients and stops working.