Alerting and response
2 min read · Updated View as Markdown
Know when something breaks and who is fixing it. Monitors watch your telemetry and raise alerts, notification policies send them to the right people, related alerts fold into one problem, and a case tracks the work until it is resolved.
Monitors and templatesWatch metrics, logs, traces and devices, starting from a templateNotification channelsSend alerts to Slack, Microsoft Teams, PagerDuty, Opsgenie, a webhook or your email gatewayProblems and casesSee related alerts as one problem and work it as a caseSLOs and on-callTrack error budgets and page the person on call
How the pieces fit
| Step | What happens | Console page |
|---|---|---|
| Watch | A monitor evaluates a query for every entity it covers, such as each host or service. | Alerts › Monitors |
| Alert | When a threshold is crossed, the monitor opens an alert for that entity, and closes it when the value recovers. | Alerts › Alerts |
| Notify | The monitor's own channels and any matching notification policies deliver the alert. | Alerts › Channels, Alerts › Policies |
| Correlate | Alerts on the same or related resources fold into one problem, with the changes that came before it. | Alerts › Problems |
| Respond | A case tracks ownership and the timeline. An escalation policy pages each of its steps in turn until someone acknowledges. | Alerts › Cases, Alerts › On-Call |
Every page above lives under Alerts in the console sidebar, with SLOs, Downtimes, Anomaly detection, Correlation and Analytics beside them.
Before you begin
Monitors need data to watch. If your workspace is new, install a collector or instrument a service first: