Tutorials

Slack alerts and ChatOps in 5 minutes

Connect the HowlOps Slack OAuth app, route an alert, and acknowledge, silence, or resolve the incident from Slack.

What you will build

In about five minutes, you will connect a Slack channel that can:

  • receive alerts and recovery messages;
  • acknowledge, silence, and resolve an incident from message buttons;
  • run /howlops incident commands.

You need a HowlOps account and permission to install apps in the Slack workspace.

Step 1: Connect the OAuth app

  1. In HowlOps, open Integrations.
  2. Open the Slack card and select Add to Slack.
  3. Choose the workspace and the channel that should receive incident alerts.
  4. Review the requested permissions and select Allow.
  5. Return to HowlOps and confirm that the Slack channel is enabled.

OAuth matters here: Slack signs every button click and slash command so HowlOps can authenticate the request. A plain Incoming Webhook can deliver messages, but it cannot provide this interactive identity.

The OAuth installation also binds the stable Slack workspace, channel, and installer user IDs to the HowlOps user who connected it. HowlOps checks that identity, incident permissions, and private-team visibility again for every command. If the channel was connected before this identity model was introduced, reconnect it once before testing ChatOps.

To create incident channels automatically, open Incident settings, keep Slack as the chat provider, and enable Auto-create chat channel. Opening a war room with a blank channel field then creates the Slack channel from your naming pattern. Team incidents use a private channel and invite the installing Slack user; add other responders in Slack until their accounts have an explicit identity link.

Step 2: Verify delivery

  1. In the notification-channel list, find the connected Slack channel.
  2. Select Send Test Alert.
  3. Confirm that the opening alert arrives in Slack.
  4. Wait for the automatic test resolution and confirm that the recovery follows the same route.

The test uses the real routing, delivery, escalation, timeline, and recovery paths. A received opening and resolution confirms more than a standalone webhook ping.

If delivery fails, check that the app is still installed, the selected channel still exists, and the app can post there. Then use Missing notifications to inspect routing and channel filters.

Step 3: Choose how Slack is reached

  • For broadcast routing, leave the alert without a governing escalation policy. Every eligible enabled channel receives it.
  • For controlled on-call routing, add the Slack channel as a target in an escalation-policy step, then select that policy with a routing rule, the monitor, or the workspace default.

The complete precedence is documented once in Alert & incident flow.

Step 4: Respond from the alert

A production incident message includes:

  • monitor or source identity and failure detail;
  • a link to the incident;
  • Acknowledge, Resolve, and Silence 1h buttons.

Use Acknowledge when you take ownership; it stops escalation but leaves the incident open. Use Silence for a temporary pause. Use Resolve only when the incident is over.

Step 5: Use slash commands

/howlops status
/howlops ack <incident_id>
/howlops silence <incident_id> [minutes]
/howlops resolve <incident_id>
/howlops help

Start with /howlops status: it lists recent open incidents and their full IDs, so the next command does not require a trip to the dashboard. Silence defaults to 60 minutes; the valid range is 1–1440 minutes.

Incoming Webhook fallback

Use a manual Slack Incoming Webhook only when Add to Slack is unavailable on the deployment. Create the webhook in Slack, paste its URL into the Slack integration card, and test delivery. This fallback receives alert and recovery messages, but its actions and /howlops commands are not interactive.

Next steps

Was this page helpful?