One canvas, one source of truth
Engineering, comms, exec sponsor, customer support — same URL. The status banner is visible to everyone, current to the second.
Use case · Incident response
When SEV-1 hits, the last thing anyone needs is to hunt for the dashboard or paste the same Slack message twice. b/oncall opens a live incident board with status, timeline, dashboards, decision log, and the post-mortem template — same URL the whole company watches.
The shape of the work
Incident response is choreography under stress. The board is the choreography sheet — visible to everyone, edited in real time, archived for the post-mortem.
On-call engineer types b/oncall. Lands on the active incident board. Status, severity, current commander — visible in five seconds.
Status updates pinned to the timeline node. Stakeholders watch the same canvas instead of pinging the on-call channel.
When the all-clear is called, the timeline becomes the post-mortem skeleton. No retracing, no re-pasting Slack into a doc.
Incident board template
Designed for on-call engineers, comms leads, and execs to read at the same glance. Status block at the top so anyone landing on the board knows the score in two seconds.
Severity, start time, current commander, comms lead. Big text, visible at the top of the board.
Embedded service dashboards. Errors, latency, saturation. Refresh the board, see fresh numbers.
Time-stamped event log. Every status change, every mitigation step, every comms update. The post-mortem skeleton.
Notes node: what we tried, what we decided, what we ruled out. With author tags, visible to the whole team.
Tasks node: who has been notified, when, with last contact time. CSMs, exec sponsor, support leads.
Live chart of affected accounts or transactions. Updates as the incident unfolds.
A countdown to the next status update. Removes "should I send another update?" The timer answers.
Pinned at the bottom. Pre-filled with timeline events. Triggers from the all-clear button — no retyping.
Why this works
Engineering, comms, exec sponsor, customer support — same URL. The status banner is visible to everyone, current to the second.
The board IS the dashboard. Stakeholders refreshing the page see fresh numbers, not yesterday’s screenshot.
Comms lead hits "next update in 30 min" and the whole company watches the same timer. Removes the "are we overdue?" anxiety.
What we tried. What we ruled out. Who decided. Searchable forever — institutional learning, not Slack archaeology.
Timeline events flow into the post-mortem template automatically. The hardest part of writing it (reconstructing what happened) is done.
On-call engineer in the kitchen with their phone? b/oncall lands them on the board. PagerDuty integrates the slug into the alert payload.
We ditched two wikis and a "links" channel. The on-call rotation went from "where's the dashboard?" to "type b/oncall."
Renata Coleman
Eng Lead · Halberd Mobility
Frequently asked
It does not — the Slack channel is still where engineers type. The board is where the canonical state lives: status, timeline, decisions. After the incident, the board becomes the post-mortem; the Slack channel becomes archive.
Yes. b/oncall is the dispatcher; it links to the active incident board (b/sev-2025-04-12). When a new incident opens, a fresh board is duplicated from the template, given an ID, and linked from b/oncall.
The slug pattern goes in the alert payload as a custom field. PagerDuty templates can include "Open b/oncall" so the on-call engineer goes from page to board with one keystroke.
They watch the board. Read-only viewers see the status banner and timeline updates without typing in the engineering Slack channel. Comments on the board are how stakeholders ask questions without crowding the on-call.
Start with one team. Roll out when it sticks.
2,400+ teams reach every important destination in their stack with a single keystroke. Save the first slug in 30 seconds.
Free for personal use · No credit card · 14-day team trial