Slack

Most incidents already get coordinated in Slack — the question is whether the paging tool knows that. The OpsPing Slack app brings alerts and acks into the channels where your team already works: Block Kit alert cards with Ack, Snooze, and Resolve buttons, slash commands, per-incident channels, and delivery rules that route alerts to the right place. This guide covers install, account linking, and daily use. For the feature overview, see the Slack ChatOps page.

Before you start
  • An OpsPing workspace with alerts flowing in, per Getting started.
  • Permission to install apps in your Slack workspace (or a friendly workspace admin who has it).
  • Each user who wants to act on alert cards must link their Slack account, below.
  1. Install the app

    There are two ways in. The easy one: open the admin console's Slack settings page and click Add to Slack — that runs the OAuth flow and installs the app with the scopes it needs. If your workspace restricts OAuth installs, the same settings page shows the app manifest so you can create the app manually: paste the manifest into Slack's app builder, then paste the resulting bot and signing tokens back into the OpsPing Slack settings page.

    Note

    Either path ends in the same place: a bot token, a signing secret, and a working app. OAuth is just less typing.

  2. Link your account

    Slack actions run as a user, not as a mystery bot. Each person goes to their Slack settings page in the admin console, generates a 6-character link code, and runs /opsping link in Slack with it:

    /opsping link A1B2C3

    Once linked, Ack, Snooze, and Resolve from Slack are attributed to you — in the alert timeline, in reports, everywhere. Until you link, you can still see cards and command output; you just can't take actions on alerts.

    Tip

    Link codes are short-lived. If /opsping link says the code is stale, generate a fresh one and try again.

  3. Work alerts from cards and commands

    Alerts delivered to Slack arrive as Block Kit cards: priority, service, the message, and three buttons — Ack, Snooze, and Resolve. Tapping one does exactly what the console buttons do, as your linked user. The card updates in place so the whole channel sees the new state instead of a pile of "did someone take this?" replies.

    For everything else there are slash commands:

    /opsping status   — open incidents and anything currently firing
    /opsping oncall   — who's on call right now, per schedule
    /opsping ack <alert> — acknowledge an alert by ID
    /opsping link     — link your Slack account (step 2)
    Tip

    /opsping status is the fastest standup in existence: paste the output, and the room knows what's open without anyone opening a browser.

  4. Run incidents in per-incident channels

    When an incident is bigger than one alert, the app can create a dedicated Slack channel for it. The incident channel is created automatically per incident, responders get invited, and the channel becomes the war room: status updates land there, and when the incident resolves, OpsPing posts a resolve summary so latecomers and the postmortem have the story in one place. Once things cool off, an archive policy cleans up channels from resolved incidents so the workspace doesn't accrete 200 #incident- channels.

    Note

    Postmortems are generated from the audit trail, not from Slack chatter — but a well-used incident channel is where you'll reconstruct what actually happened. Write it down as you go.

  5. Route alerts with delivery rules

    Not every alert belongs in every channel. Delivery rules route alert notifications to Slack channels by team, priority, and source — payments P1s to #payments-eng, everything P4 to the quieter #alerts-low, heartbeat noise to nowhere. Rules are managed in the admin console's Slack settings; the app just delivers. Combine them with alert policies for the full funnel: policies decide what an alert is (suppressed, delayed, retagged), delivery rules decide where it lands.

  6. Paste service links for instant context

    Paste a link to a OpsPing service into any channel and the app unfurls it: name, tier, on-call schedule, owners, runbook URL — the service card from the CMDB, right in the conversation. It's the difference between "can someone look at the payments API?" and the person you pinged already knowing who owns it and where the runbook lives.