Keep routing close to ownership
Select the escalation policy for each service. Give systems with different owners or response paths their own service, rather than creating a new service for every host or alarm rule.
An alert needs an owner. Give it a response plan.
Connect each service to the people responsible for it. WarnFire combines on-call schedules, escalation policies, multi-channel paging, and a shared incident record so your team knows who is responding and what happens next.
Start with the service that needs attention.
A service represents a system or area of responsibility: your payments API, customer portal, or data platform. It gives incoming alerts an operational owner and an escalation policy.
Read the product guideConnect each monitoring source separately
Issue service-scoped integration keys bound to their alert source. Alertmanager, Grafana, Datadog, cloud monitoring, and custom events can feed the same service through separate credentials.
Manage credentials through their lifecycle
Name keys, set expiry and lower event ceilings, inspect last use, and revoke access. Use a separate replacement key when you need an overlap while changing a sender.
Connect the internal and customer view
Choose which status-page components a service affects. Internal incident details remain separate from the customer-facing updates your team writes and publishes.
Build coverage around how your team actually works.
Schedules answer who is on call now. Rotations define the repeating coverage; temporary overrides handle the exceptions. Review every schedule together before relying on it to page someone.
Read the product guideRotations with explicit handoffs
Set responder order, shift length, start time, timezone, weekdays, and time windows. Combine rotations for business hours, nights, or follow-the-sun coverage.
See gaps and overlapping coverage
The timeline shows one lane per schedule, current coverage, and uncovered windows. Overlapping active rotations within a targeted schedule can page more than one responder.
Make time zones and daylight saving explicit
Day- and week-based shifts preserve local handoff times through daylight saving changes. Hour-based shifts use elapsed time. Choose the behavior that matches the rotation you intend.
Cover a shift without rebuilding the rotation
Apply a bounded override to one rotation or the whole schedule. Responders can request cover or a swap from the mobile app; accepted requests become schedule overrides.
Account for time away
Mark people out, review the resulting coverage, and arrange cover before a gap becomes an unanswered incident. Mobile shows current on-call status, upcoming shifts, and the schedule calendar.
Decide who to try, how to reach them, and when to escalate.
An escalation policy is an ordered response plan. Each step selects its targets, matching severities, channels, response window, and the condition that stops further escalation.
Read the product guideTarget a person, schedule, or team
Page a named responder, the people currently on a schedule, a team's on-call coverage, or every enabled member of a tiger team. Put several targets in one step when they should respond together.
Give each severity the response it needs
Match steps to severity. Unmatched steps are skipped immediately, so a critical incident can follow a different response path from a warning.
Choose channels and their timing
Select push, email, SMS, and voice per step. Configure the delay between channels within the step's total response window, and inspect the delivery preview before saving.
Choose what stops the policy
Stop on acknowledgement or resolution for normal ownership handoff. For incidents that require continued escalation, choose resolution as the stop condition.
Keep an open incident's plan understandable
WarnFire captures the resolved response plan when the incident opens. Later configuration changes apply to new incidents, while the existing incident retains the plan it started with.
Make unanswered escalation visible
If the policy runs out without an acknowledgement, the incident remains open with escalation exhausted. Delivery failures and unavailable targets remain visible in the incident record.
One policy. A clear next step.
For api.prod.example.com, a response policy could try the on-call schedule first, then a team lead, then the wider response team. This example uses a five-minute first window; the targets, channels, severity and stop condition are your configuration.
| Step | Target | Response window |
|---|---|---|
| First | Current on-call schedule | 5 minutes |
| Next | Team lead | 10 minutes |
| Then | Every enabled member of the response team | Final configured step |
Keep the response together as the incident changes.
Repeated signals should add context to the incident they describe. Responders need its current state, the changes that led there, and a way to bring in the right help.
Read the product guideOne incident, updated context
Correlate related events by their deduplication identity. Keep summaries, severity changes, source links, structured details, notes, and resolution in a timestamped activity trail.
Clear ownership from the console or app
Acknowledge an incident to record that someone has taken it, add a note, and resolve it with the response history intact. Open the incident's selected Slack or Zoom war room from the same context.
Ask for help without guessing who is available
Request a responder or team for a specific role. Invitees can join now, commit to a later time, or decline with context. Assistance uses active push-enabled mobile destinations.
Inspect the delivery evidence
Review notification attempts and their strongest available evidence. Provider acceptance, provider delivery, and a device open are different events; the record keeps those distinctions visible.
Plan maintenance deliberately
Use maintenance controls for planned work and review the affected services. Keep a scheduled deployment from becoming a surprise page while retaining an accountable configuration history.
Build a response people can follow.
Start a workspace, connect a service, and make the next signal reach its owner.