Most teams think about Slack notifications as one-directional: something happens, a message fires, people read it. The message is a snapshot in time: it describes a moment and then sits there, frozen, while the world moves on.
This is a significant missed opportunity. A Slack message can be a living record. It can reflect what happened after the alert fired: who took action, when, and what the outcome was. And doing this right solves three real problems that most teams don’t even realize they have.
Problem 1: Did anyone handle this?
When an alert fires in a shared channel, a silent question hangs over it: is someone dealing with this? Without an answer, two things happen. Either someone eventually picks it up without knowing if it’s already being handled: wasting time or creating duplicate work. Or everyone assumes someone else has it, and nobody acts.
This is the bystander problem applied to Slack. In a channel with 15 people, no individual feels responsible unless the message explicitly tells them it hasn’t been handled.
A message update solves this directly. When someone clicks “Acknowledge” or “Take ownership,” the message updates immediately, visibly in the channel, to show who has it. Everyone else sees the updated state. No confusion. No duplicate effort. No dropped alerts.
Problem 2: What actually happened?
A frozen alert message tells you something went wrong. It doesn’t tell you what was done about it, by whom, or when. That context lives in someone’s head, in a separate thread, or nowhere at all.
When your message updates in real time (“Acknowledged by Priya at 2:14pm · Resolved at 2:31pm · Root cause: misconfigured rate limit”) the message itself becomes the record. The channel history is now an accurate account of what happened and what was done. No separate incident log required. No manual write-up. The message is the audit trail.
For teams in regulated environments or with compliance requirements, this is more than a convenience: it’s documentation that would otherwise require manual effort to produce.
Problem 3: The “open loop” alert
An alert that fires and never resolves creates cognitive debt. Every time someone sees it in the channel history, they have to ask: is this still relevant? Was it handled? Should I care?
An unresolved message in a channel is ambient stress. Multiply it by dozens of automated alerts that never update, and the channel becomes something people learn to ignore: because it’s full of old messages they can’t quickly evaluate.
When messages update to reflect resolution (a green check, a “Resolved” status, the duration it took) they become inert. The record is closed. The channel stays useful.
What this looks like in practice
A good message update flow for an alert:
State 1: Alert fires:
🔴 Failed payment · Stripe webhook
14 events unprocessed · payment.succeeded · us-east-1
[Acknowledge] [View events →]State 2: Someone clicks Acknowledge:
🟡 Failed payment · Stripe webhook
14 events unprocessed · payment.succeeded · us-east-1
Acknowledged by Marcus · 2:14pm
[Mark resolved] [View events →]State 3: Resolved:
✅ Failed payment · Stripe webhook: Resolved
14 events processed · Root cause: endpoint timeout
Acknowledged by Marcus · 2:14pm · Resolved · 2:31pm (17 min)The same message. Three states. The channel tells the complete story without a word typed by anyone.
Why this is hard to build with standard automation tools
Message updates in Slack require two separate pieces of information: the channel the message was sent to, and the timestamp (ts) of the original message: which is Slack’s unique identifier for that specific message.
When you update a message, you call chat.update with the channel, the ts, and your new blocks. Simple enough. The problem is the gap between sending the original message and needing to update it later.
In Make or Zapier, a scenario that sends a message runs once and finishes. If you want to update that message later (when a button is clicked, when a downstream system resolves the issue, when a timer fires) you need to:
- Capture and store the
tsfrom the response when the original message is sent - Persist it somewhere: a Make data store, an external database, a record in your CRM
- Retrieve it later in a different scenario or execution when the update needs to happen
- Re-construct the updated blocks, often without seeing the current state of the message
- Call
chat.updatewith the correct channel andts
Each step is manageable in isolation. Together, they require coordinating state across multiple automation scenarios, a persistent data layer, and careful handling of the mapping between your internal record IDs and Slack’s ts values. If any link in that chain breaks (the ts isn’t stored, the lookup fails, the update scenario uses the wrong channel) the message never updates and you’re back to frozen alerts.
For teams building more than one or two interactive flows, maintaining this infrastructure becomes significant overhead.
How LithoBlocks handles it
LithoBlocks builds message update logic directly into the actions configuration for every template. When you create a template with interactive buttons, you configure what each button does: including what the message should look like after the action is taken.
The ts tracking, state management, and update routing are handled automatically. You define the states (pending, acknowledged, resolved) and the transitions between them. LithoBlocks handles the Slack API calls.
The result is that message update flows that would take an afternoon to wire up manually (all the data store configuration, multi-scenario coordination, and debugging) can be configured in minutes without touching any of the underlying plumbing.
Message updates aren’t a polish feature. They’re the difference between a notification system and a workflow system: between messages that fire and messages that close. Once you build a few flows with proper update states, sending static one-way alerts starts to feel like sending letters when you could be having a conversation.
Message update flows are a first-class feature in LithoBlocks: configure states, transitions, and dynamic content without managing Slack ts values or data stores. Try it free →