Alerts & notifications

Ultraviolet watches your telemetry and tells you when something crosses a line you care about — then delivers that alert wherever your team works. Both live under Monitoring.

Alerts

On the Alerts page you’ll see any firing alerts up top, your rules, and a history of everything that’s fired. Create a rule with New rule (requires the editor role) and choose what to watch:

Condition	Alerts on
Error rate	the fraction of failing requests
Latency p95	slow requests (95th-percentile latency)
Throughput	request volume rising or falling
Log error rate	error-and-above logs arriving too fast
Metric value	any metric you can chart, at any aggregation

For each rule you set a comparison and threshold (e.g. error rate > 0.05), a look-back window, and optional scope — protocol, service, route, and site — so an alert can be as broad or as targeted as you need. Alerts evaluate continuously; an empty window never counts as a breach.

The History tab records every firing and recovery with the observed value, the threshold, and whether notifications went out.

Notifications

The Notifications page manages where alerts go. Add a channel with New channel:

• Webhook — a JSON POST to any endpoint (optionally signed).
• Email — over your SMTP server.
• Slack, Microsoft Teams — branded messages to an incoming webhook.
• PagerDuty — triggers and auto-resolves incidents.
• incident.io — opens and resolves alerts.

Route per rule: each alert rule can send to specific channels, or leave it blank to notify every enabled channel. Recovery notices can be turned off per channel. You can send a test to confirm a channel works, and a delivery history shows every attempt, its outcome, and any error.

Customize the message: a rule can carry its own message template with fields like the rule name, state, observed value, and threshold — handy for tailoring what lands in Slack or an email.

Note

A channel never stores its secret (webhook URL, SMTP password, routing key). It holds only a key name that points at a secret you provision at the platform level. See notification secrets.

Silences and maintenance windows

A silence stops notifications you already expect: during a deploy, a database migration, or a known-bad stretch. Find it under Alerts → Silences (creating and ending one needs the editor role), or click the silence button next to a firing alert to quiet just that one.

• Silence: quiet for a fixed time, from 30 minutes up to 30 days. It ends on its own; there are no open-ended silences. Every silence needs a reason.
• Maintenance window: quiet on a schedule, such as Saturdays 02:00–04:00 in your time zone. It repeats until you remove it.

Either one can cover everything, or only what matches what you pick: kinds of alert (alert rules, SLO burns, synthetic monitors, cost alerts), specific alerts, services, sites, and SLO severity. Every field you fill in must match.

A silence only holds back notifications. Alerts keep evaluating and recording history, and a silenced alert shows as Silenced rather than disappearing, so nobody mistakes a silence for a fix.

• Firing and recovering within the silence: nobody is notified at all.
• Still firing when the silence ends: the notification goes out then, so a silence never hides a problem that outlasts it.
• Already notified before the silence began: its recovery notice is still sent, so incidents it opened in PagerDuty or incident.io close.

The History tab counts silenced notifications next to sent and failed ones, and the audit log records who created, changed or ended each silence, and why.