🧱 Slack Block Kit Message Design for Ops: Make Alerts Scannable

I’ve watched brilliant ChatOps tooling get ignored because the messages were ugly. A deploy bot can do everything right and still fail if its output is a wall of unformatted text that scrolls past at 2am. Block Kit — Slack’s layout system — is the difference between a message that gets read and one that gets skimmed and forgotten. After 25 years of ops, I treat message design as a first-class part of any bot, not an afterthought.

Here’s how I design ops messages people actually read.

The blocks you’ll use 90% of the time

Block Kit has many block types, but ops messages need only a handful:

• header — one bold line stating what this is. “Deploy succeeded.” “Critical alert.”
• section with fields — the key/value facts in a two-column grid.
• section with mrkdwn — a paragraph of context.
• context — small, muted footer text: who triggered it, when.
• actions — buttons for the next step.
• divider — visual separation when a message carries two distinct ideas.

That’s the whole toolkit for ops. Resist using more; the goal is scannability, not a UI showcase.

Anatomy of a good deploy message

Here’s a deploy-result message that answers what, where, who, and outcome at a glance:

{
  "blocks": [
    { "type": "header", "text": { "type": "plain_text", "text": ":rocket: Deploy succeeded" } },
    { "type": "section", "fields": [
      { "type": "mrkdwn", "text": "*Service:*\ncheckout-api" },
      { "type": "mrkdwn", "text": "*Environment:*\nproduction" },
      { "type": "mrkdwn", "text": "*Version:*\nv2.14.3" },
      { "type": "mrkdwn", "text": "*Duration:*\n1m 42s" }
    ]},
    { "type": "context", "elements": [
      { "type": "mrkdwn", "text": "Triggered by <@U123> · 14:32 UTC" }
    ]}
  ]
}

The fields array renders as a tidy two-column grid. The reader’s eye lands on the header, scans four facts, and moves on. No clicking, no parsing.

Use color to signal severity — sparingly

The attachments wrapper still gives you the colored left bar, which is the fastest severity signal Slack offers. I use exactly three colors and nothing else: green for success/resolved, amber for warning, red for critical/failed. Consistency is what makes color useful. The moment you have seven shades of meaning, the bar means nothing and you’ve added noise.

Add actions, but keep them honest

Buttons turn a message into a control surface. A failed-deploy message can carry “Rollback,” “View logs,” and “Open runbook” buttons. Two design rules I never break:

• Label the consequence, not the verb. “Rollback to v2.14.2” beats a bare “Rollback.” People click fast; the button should say exactly what it does.
• Gate destructive buttons. A rollback button checks authorization on click and, for prod, pops a confirmation. The button being visible is not permission to use it.

{ "type": "actions", "elements": [
  { "type": "button", "style": "danger",
    "text": { "type": "plain_text", "text": "Rollback to v2.14.2" },
    "confirm": { "title": { "type": "plain_text", "text": "Roll back production?" },
      "text": { "type": "mrkdwn", "text": "This reverts checkout-api in prod." },
      "confirm": { "type": "plain_text", "text": "Do it" },
      "deny": { "type": "plain_text", "text": "Cancel" } } }
]}

The built-in confirm object gives you a native confirmation dialog for free. Use it on anything dangerous.

The Block Kit Builder is your friend

Slack’s Block Kit Builder (app.slack.com/block-kit-builder) renders your JSON live. I prototype every non-trivial message there before wiring it into code. It catches the field-count mistakes (a fields array maxes out at 10) and the markdown quirks before they hit a real channel.

Design for the mobile glance

Half your on-call engineers will see these on a phone at night. That changes the rules:

• Front-load the verdict. The header and first field must carry the message even if nothing below loads.
• Keep fields short. Long values wrap badly on mobile.
• Don’t bury the action. If a rollback button is below five paragraphs, a half-asleep thumb won’t find it.

A message that works on a phone at 3am works everywhere.

Where AI helps

The hardest part of a good ops message isn’t the layout — it’s the prose. Raw command output is verbose and noisy. I use AI to compress it into the one-line section text:

“Summarize this deploy log into a single sentence stating outcome and any warnings worth noting. No log lines, no speculation.”

The bot drops that sentence into the mrkdwn section above the raw details. The structure (header, fields, buttons) stays deterministic and templated; AI only fills the human-readable summary slot, and never decides which buttons appear or what they do. Layout and actions are too important to hand to a model.

A quick rule of thumb

If your reader has to read the message rather than scan it, redesign it. Header states the verdict. Fields carry the facts. Context names who and when. Actions offer the next step, gated if dangerous. That template covers nearly every ops message you’ll ever send.

For prompts that compress raw output into clean summaries, see our Slack message prompts and the prompt library.

Keep layout and buttons deterministic and templated. Let AI write the summary line, not decide the actions.