Decide who receives notifications
Notifications should lead to action
An alert is useful only when the recipient knows what to do. Before enabling every option for every person, identify who owns each important service and who needs awareness rather than interruption.
One confirmed event, the right destinations
Delivery begins after your incident policy confirms the problem.
Confirmed event
Checkout unavailable
2 regions · 2 failed checks
Understand the event types
| Event | When it occurs | Typical audience |
|---|---|---|
| Confirmed outage | Failure thresholds and regional confirmation are reached | Service owners and responders |
| Incident resolved | Recovery requirements are satisfied | Responders and affected stakeholders |
| SSL expiring | A certificate is approaching expiration | Website or infrastructure owner |
| SSL expired or invalid | Secure browser trust is at risk | Immediate service owner |
Individual failed checks remain visible in the monitor history but do not automatically notify everybody.
Configure a member’s email preferences
Open Team
Choose Team, then open the member whose delivery preferences you want to review.
Select important events
Enable confirmed outages, recoveries, and SSL alerts according to that person’s responsibilities.
Save the preference
The member’s delivery summary shows how many notification types are enabled.
Test the wider path
For external destinations such as Slack, use the integration’s test action rather than creating a fake production incident.
A practical starting policy
- Service owners receive confirmed outage and recovery messages.
- The website or infrastructure owner receives SSL warnings.
- Managers who do not respond directly use a stakeholder channel or status page instead of every internal notification.
- At least two people can receive critical-service alerts when coverage requires it.
Understand delivery status
The Delivery area groups attempts by incident or SSL event so you can inspect many destinations without scrolling through every raw attempt.
Common states include:
- Queued — waiting to be sent;
- Sending — delivery is in progress;
- Delivered — the destination accepted it;
- Retrying — a temporary error will be tried again;
- Skipped — preferences or configuration excluded it;
- Failed — delivery could not complete.
A delivered state means the destination accepted the message. It does not guarantee that a person read it.
Muting versus changing preferences
Use a temporary mute for a short operational need. Change notification preferences when the recipient should no longer receive that class of event.
Do not mute a noisy monitor indefinitely. Troubleshoot the failed check or adjust its policy after reviewing evidence.
Review notification quality
After an incident, ask:
- Did the right people receive the confirmed event?
- Did anyone receive an alert they could not act on?
- Did the resolved message close the loop?
- Did any delivery retry or fail?
- Was the monitor policy accurate enough to trust?
For a team channel, continue with Connect a Slack webhook.