Worked examples for IncidentRelay v2.3.1, checked on . Names, identifiers and timings below are illustrative; validate them in a test deployment before using production credentials.
Business example · Setup · Worked example · Acceptance checks · Limits and failure modes
Business example: SaaS customers work across time zones
Illustrative scenario, not a customer case study. Metrics below are suggestions for your pilot, not measured savings or a claim that IR includes every reporting dashboard.
Situation and risk. A B2B SaaS team serves customers in Europe and North America. A customer's working afternoon overlaps another engineer's evening, and the usual responder is on holiday. Without an agreed schedule, the team relies on whoever notices the chat first. The risk is an unowned outage and repeated interruptions for off-duty staff.
Workflow with IR. Agree on staffed coverage, then represent it with a base rotation and a working-day layer. Record holiday substitutions as overrides and configure a separate backup escalation target. Check handovers and future gaps. For a planned billing deployment, use a service-scoped maintenance window while unrelated services continue notifying.
Operational benefit to validate. Make responsibility predictable for support and engineering, including leave and handovers. Planned work should not require muting the entire company's alert stream.
What to measure. Review uncovered minutes in a defined future period, such as the next 14 days, last-minute manual handovers and acknowledgements within the team's response target. Compare night-time notifications per engineer alongside the actual staffing schedule; a balanced calendar alone does not show the workload.
Boundary. A filled calendar does not create extra staff or prove that somebody can respond. IR does not guarantee a contractual response time or calculate customer availability from ACKs. Keep staffing decisions, SLO monitoring and customer communication in the broader operating process.
Cover the night before optimizing the working day
Suppose an SRE team owns billing reliability across a working-day shift and an overnight rota. In one rotation, create a base layer with priority 10 and unrestricted 24/7 coverage. Add a layer with priority 20, restricted to Monday-Friday, 09:00-18:00 in Europe/Berlin. Use real active members and verify the generated calendar.
The highest-priority active layer supplies the assignee; an override takes precedence over layers. These are not two simultaneous responders. Configure a separate escalation target or rotation for backup coverage. If no layer is active and no override applies, there is no assignee. See rotation and layer rules.
Pause billing notifications during a planned deployment
Create a service-scoped window through the interface, or submit this configuration to POST /api/maintenance-windows using an authenticated management-API session with permission to modify the scope. An intake route token is not a management credential. Replace 42 with your actual billing service ID and choose a future test window.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}These timestamps are wall-clock times in the selected timezone, not UTC values with an omitted Z. During this window, incoming billing alerts remain visible, but notifications, reminders and escalation are paused. Other services should remain unaffected. This behavior is not suppress_incident, which prevents new AlertGroups, or pause_escalation_only, which keeps notifications enabled.
Test the boundaries, not just the middle of a shift
- Inspect assignment just before and after 09:00 and 18:00, across a weekend and a daylight-saving transition. Add a temporary override and confirm that it wins, then remove it.
- Open the full On-call Health check. Review its checked future window, gaps, inactive members and usable delivery methods. A green summary is not proof of coverage forever or delivery to a phone.
- Send billing and unrelated-service test events during maintenance. Confirm billing is visible but quiet and the unrelated service still notifies. To include already unresolved alerts, explicitly enable the option to apply the window to existing alerts; it is off by default.
- Leave billing firing when the window ends. With reactivation enabled, verify normal notification resumes without replaying every missed reminder. Confirm the actual responder receives it and can acknowledge it.
A quiet service is not a recovered service
Maintenance does not repair the service, retract delivered messages or imply resolution. Reactivation at the end is enabled by default; disabling it retains the maintenance effect after the window ends. Overlapping windows can keep an alert quiet until the last applicable active or retained effect is released. Review these controls in the maintenance guide.
Keep SLO calculations and burn-rate detection in your monitoring stack. IR routes and coordinates the resulting signals. An AlertGroup owns technical acknowledgement, resolution, notifications and escalation; an Incident is a separate operational workflow. Linking several AlertGroups to one Incident does not merge their technical histories. In v2.3.1, responders and stakeholders still belong to AlertGroups. Test both lifecycles instead of treating an Incident status change as an AlertGroup ACK.