WarnFireDocs

Incident response

Slack

Post incidents to your channels and let responders acknowledge without leaving Slack.

Version 1.0 Status Needs verification For Tenant administratorsFor Responders incident-responseslackintegrations

Connect Slack and every new incident lands in the right channel, with Acknowledge and Resolve buttons right in the message.

Setup lives under Integrations → Slack and is a three-step checklist. The page tracks your progress — “1 of 3 complete” — so you can’t miss a step.

Before you begin

You need tenant-owner or tenant-administrator access in WarnFire and permission to install apps in the destination Slack workspace. Create at least one enabled responder and one enabled service before starting. Know which Slack channel should receive that service’s test incident.

Step 1 — Connect your workspace

  1. Open Integrations → Slack.
  2. Select Connect workspace.
  3. Review and approve the permissions Slack displays.
  4. Confirm that WarnFire returns to the integration page showing Workspace connected and the intended Slack workspace name.

Slack asks for these exact bot scopes:

ScopeWhat WarnFire does with it
chat:writePost incident cards, status changes, and closing summaries.
channels:manageCreate, name, and archive public incident channels.
channels:joinJoin a public channel when Slack requires membership, including archive recovery.
groups:writeCreate, invite responders to, and archive private incident channels.
users:read and users:read.emailMatch a paged WarnFire responder to the Slack member with the same verified email address.
channels:read and groups:readList public channels and private channels the app can access in the route picker.
commandsAnswer /warnfire and /wf.

WarnFire does not request message-history scopes and cannot read existing conversations. The channel picker can list public channel metadata and private channels to which the app has access. Posting to a private or routed channel still requires the WarnFire app to be a member.

Slack returns the browser to WarnFire’s OAuth callback. The authorization state is single-use and expires after ten minutes. On success, WarnFire saves the new installation and returns you to the console with slack=connected in the URL. If you deny access, omit the authorization code, or return an expired state, the callback shows an error and does not change the installation.

If you connected Slack some time ago, the page may ask you to reconnect. That happens when WarnFire has gained a feature your original approval didn’t cover — it tells you which one, and reconnecting grants only that.

After reconnecting, reload or restart Slack so its command autocomplete list reflects the current installation. If typing /warnfire changes to /wf instead of running, an administrator must reinstall the WarnFire Slack app; both commands are separate Slack registrations even though WarnFire handles them identically.

Step 2 — Authorize responders

This step decides exactly who may press Acknowledge and Resolve. Being in your Slack workspace grants nothing by itself.

Most of the time this happens by itself. The first time WarnFire pages someone into an incident channel, it matches them to their Slack account using their email address and links them then and there. You’ll see them appear here marked matched by email address.

To link someone in advance, or if their WarnFire email differs from their Slack one:

  1. Press Link responder.
  2. Choose the WarnFire responder.
  3. Enter their Slack member ID. To find it: open the person’s Slack profile → MoreCopy member ID. It looks like U012AB3CD.
  4. Press Save link.

You can remove any link at any time, however it was created.

Removing an automatically email-matched link is durable: WarnFire will not silently recreate it during a later incident. To authorize that responder again, create an explicit link with Link responder.

Step 3 — Route services to channels

Tell WarnFire where each service’s incidents should be posted.

  1. Press Add route.
  2. Pick the Service, then pick the Slack channel from the list.
  3. Press Save route.
  4. Invite the WarnFire app into that channel in Slack (type /invite @WarnFire) — Slack doesn’t let apps post to channels they haven’t joined.

Private channels only appear in the list once WarnFire has been invited to them.

Then send a test alert from Configuration → Services and watch it arrive. The setup checklist confirms only that a workspace, link, and route exist; it does not prove that the app is still present in the channel or that Slack accepted a message.

The test follows the service’s real escalation policy. Push and email are free; SMS and voice attempts use credits and can trigger automatic recharge when it is enabled. Notify the test responder before sending it.

Change or repair a workspace

Use Reconnect Slack when WarnFire reports missing scopes or a revoked connection. Reauthorizing the same Slack workspace preserves responder links and service routes.

Use Change workspace only when you intend to replace the workspace. The console asks for confirmation before sending you to Slack. If Slack authorizes a different workspace, WarnFire atomically removes the old workspace’s responder links, service routes, and unsent Slack messages. Then:

  1. Link responders in the new workspace.
  2. Recreate every service route.
  3. Invite WarnFire to each routed private channel.
  4. Send a real test alert and verify the incident card and response action.

Using the buttons

When an incident posts to Slack, any linked responder who is on that incident’s escalation plan can press Acknowledge (paging stops — you own it) or Resolve (the problem is fixed and the incident closes). Anyone else who presses a button gets a private note saying so, and nothing changes.

Good to know

  • Slack is a convenience layer, never a dependency: if Slack has an outage, paging by push, email, text message, and phone call continues through the channels in the incident’s response plan.
  • Acknowledging in Slack is exactly as real as acknowledging in the app — it’s recorded on the incident timeline with your name.
  • Temporary failures show as retrying with an attempt count. WarnFire uses bounded backoff. After the retry budget is exhausted, the Slack page shows a terminal failure. Correct the workspace, membership, or route first, then select Retry failed Slack deliveries.

Verify it worked

  1. Confirm that the setup checklist says 3 of 3 complete and Slack configuration is complete. This verifies configuration presence, not live Slack delivery.
  2. From Configuration → Services , send a test alert for the routed service.
  3. Confirm that the test incident appears in the selected Slack channel.
  4. As a linked responder on the incident, select Acknowledge and confirm that WarnFire records the responder and stops that incident’s escalation.
  5. Return to Integrations → Slack and confirm that no delivery is marked retrying or failed.

Next steps