Every engineering team starts incident management the same way. Someone posts in #engineering: "prod is down." Three people reply, two investigate the same thing, and the one person who actually knows the affected service is asleep. The runbook exists somewhere. No one is reading it while production is burning.
This is a field playbook for that first 15 minutes: five specific decisions, in order, with the exact channel moves that keep the room functional instead of frantic. It assumes Slack, but the logic holds in Teams.
What to do in the first five minutes
Declare and name the channel before you understand the problem. That sounds backwards, but it matters. The biggest problem isn't the process - it's that everything depends on one person remembering eight steps in the right order while production is on fire. Getting everyone into one named room removes that dependency.
When a Datadog alert fires for API latency spiking to 5000ms, a well-set-up platform automatically creates a dedicated Slack channel named #inc-2847-api-latency-spike, pages the on-call engineer, and pre-populates the channel with the triggering alert, full context from your service catalog (owners, recent deployments), and an auto-assigned incident lead.
If you're not yet on a platform that does this, do it by hand - but do it first.
Channel naming matters for operational sanity. FireHydrant customers use formats like {{ incident.severity }}-incident-{{ name }}-{{ date }} so the channel name carries enough signal that responders know what they're walking into before they read a single message. The Slack official sample app uses #incd-YYYY-MM-DD-1234 as a baseline. Pick one convention and hold it - the exact format is less important than applying it every time.
The first pinned message in the channel should be three lines: what is broken, who is the incident commander, and where the current status doc lives. Nothing else. Responders joining mid-incident will scroll to the top; give them what they need in ten seconds.
The five moves, in order
Minute 0-2: Create the channel and page the right people. Do not post in a general engineering channel. Dedicated channels create focus. A single channel per incident means everyone involved sees the same information. No cross-talk from other conversations. No "did you see my message in #engineering?" The channel is the incident.
It's best practice to limit channel participation to the people who are actively involved in resolving the incident. Anyone else may be tempted to ask questions about why the incident happened, which creates distractions and wastes valuable time.
Stakeholders get a separate #inc-comms-* channel, or a pinned read-only update thread. Keep the working room clean.
Minute 2-5: Post the opening declaration. Use a fixed template. Every team copies the one that fits, but the fields that must be present are: severity (P1/P2/P3), what is impacted, detection source, incident commander, and a status page link if customer-facing. The first update should come within 5 minutes of detection. It doesn't need root cause - just acknowledge the problem: what's affected, what you know so far, and that you're investigating. Silence during an outage is worse than incomplete information.
Minute 5-8: Name the roles out loud. Incident commander, comms lead, and technical lead. If you have two of those covered by one person, say so explicitly. Without clear ownership, responsibility stays informal - "I'll check this" - leading to duplicated effort or dropped issues. Without ticketing, it's hard to see who's handling what.
Minute 8-15: Log actions as they happen, not after.
Message history becomes the timeline. Every message in the incident channel is a timestamped record of what happened: who said what, when, what was tried, what failed. This is the raw material for your post-incident review, and Slack captures it automatically. That only works if people actually post their moves in the channel rather than DMs. Make it a norm, not a rule - the norm is: if you tried something, post one line saying so.
Minute 15+: Update the status on a cadence.
Update every 15-30 minutes for active incidents. Even if nothing changed, post "Still investigating, no new information" - it shows you're working on it. For P1 incidents with high visibility, update every 10-15 minutes.
A teammate like Beagle can watch the channel and draft those cadence updates - pulling the most recent technical messages into a two-line stakeholder summary, so the incident commander stays focused on the problem rather than the comms.
Why most runbooks don't survive contact
Manual context switching between Jira and Slack costs engineering teams 15-20 minutes per incident in coordination overhead. Add 23 minutes to rebuild focus after each tool switch and a $150/hour engineer cost, and your "free" workflow likely costs $20,000+ annually.
The runbook breaks down when it lives in Confluence and the incident lives in Slack. Incidents pull teams into Slack, then scatter the work across dashboards, tickets, and docs, which adds coordination drag and dilutes attention. Slack-native incident management makes chat the primary interface so responders can declare incidents, coordinate, execute runbooks, and capture timelines inside the channel.
The fix is not to write a better Confluence page. It's to put the runbook steps inside the channel itself - as a pinned canvas, a bot prompt at declaration, or a simple workflow that fires when the channel is created.
Runbooks rot when they're verbose and detached from the tools you actually touch during an outage. Keep the in-channel version to five steps. Longer reasoning lives in a linked doc. Nobody opens the doc during a P1, and that's fine - the five steps are what matters.
One thing the Opsgenie sunset is forcing
If you're still on Opsgenie, you have a hard migration deadline to deal with. Atlassian announced in March 2025 that Opsgenie will no longer accept new customers starting June 4, 2025, and the service reaches end-of-life on April 5, 2027. These are hard dates that force every Opsgenie customer to migrate.
JSM is a service desk platform first, incident management second. Complex implementations can take 2-3 months depending on your workflow requirements. That migration window is the right moment to also audit whether your incident channel runbook is actually being followed - and to move whatever is useful out of the docs tool and into the channel itself, where it will actually get used.
The incident channel is a coordination tool, not a log. Most teams treat it like a log and then wonder why MTTR stays flat. Get the first five minutes right - channel created, roles named, template posted, stakeholders separated - and the rest of the incident has a much better chance of staying coherent.