Sending Slack Alerts from Make Without Breaking Your Threads

1. Picking the right Slack module chain in Make actually matters

There are at least four different Slack modules in Make that seem like they do the same thing—send a message. They don’t. And depending on the combination you stack in your scenario, you can either break threading, drop a payload silently, or end up triple-posting to a channel that was supposed to be muted.

Here’s how mine looked before I fixed it:

Trigger: Webhook (from my Notion integration)
→ Slack: Send Message (legacy HTTPS)
→ Slack: Upload File (new module)
→ Slack: Make API Call (to format a thread)

Every once in a while, the first Slack message wouldn’t post, but the file and thread would still execute. There’s no rollback or error trap between them. No blue bubble. Just silence—and a confused team tagging me why a thread starts with a PDF.

Eventually I realized the Send Message module (not the legacy one) worked better when followed immediately by the Add Reaction module or the Get Message module, because those confirm the message timestamp which you need for thread_ts—you can’t guess it. And yeah, the module library doesn’t exactly tell you which one’s deprecated unless you squint at the top-right label.

2. Slack bot tokens quietly lose thread_ts context on reconnect

This one wrecked a 32-thread reporting structure I had running for client check-ins.

When you reauthorize your Slack connection (or if a token refresh fails and Make auto-prompts for reauthentication), any downstream module chain that depended on thread_ts from the old bot context stops threading properly. It still says it’s sending a reply, but it starts posting as brand-new messages in the same channel. If you’re syncing DMs, it sometimes drops them entirely.

Slack won’t show any errors. Make won’t show errors. The thread just falls apart. It took me days to find a log from an old run where the message ID wasn’t being returned—just an empty string for ts, even though the main message sent fine.

What made it worse? The Scenario ran perfectly fine on manual tests. It only failed inside the full weekly run because the initial message came from a delay 3 modules earlier and the Slack auth had changed silently the day before.

3. Using a router to branch new threads versus reusing old ones

Here’s the situation: I wanted our #standups channel to get a grouped thread per assignee, even if multiple systems (Notion, Linear, GitHub) fed updates about that person.

Naively, I tried filtering messages by name and reusing thread_ts from the last known update. Problems:

• Slack doesn’t give you a reliable way to find a user’s last thread_ts without scanning 3 months of history with a pagination token
• If two updates happen within the same Make execution, there’s no cached thread_ts yet
• Messages posted to private channels don’t show up in that API call even with full scopes

The solution was to use a router that splits each update by user, then stores that user’s active thread_ts in an Airtable lookup. If the record doesn’t exist (i.e. first update that day), it posts a new parent message and writes the new ts. Otherwise, it appends to the existing thread.

I had to add a conditional that clears the stored thread_ts every 24 hours via separate scheduled deletion, otherwise the next day’s messages kept chaining into yesterday’s thread, which confused people.

4. Thread replies fail silently if posting to a Slackbot-initiated conversation

Undocumented edge case: you cannot reply in thread using Make if the parent message was sent by Slackbot, not a real user or app bot.

I ran into this with a calendar integration that triggered Slackbot to post automatic birthdays. I tried reacting with a thumbs up using Make, then reply-threading a custom message with links to a kudos board. Nothing. Zero error. Scenario runs green. Message never appears.

Eventually I isolated it to the thread_ts being technically valid, but permission-blocked. Slackbot messages are almost like read-only contexts; even if you’re an admin or using a full-scope bot token, you can’t post replies there via the API.

Once I swapped the parent message to be something I posted via Make’s Send Message module instead, everything worked—which means if you want to interact with those reminders or shoutouts programmatically, you have to intercept and repost them yourself.

5. One wrong Make webhook URL breaks queuing without any alert

I had a queue setup:
Webhook → Filter module → Array aggregator → Slack thread posting system. Pretty clean. Messages came from multiple tools, so I used Make’s built-in webhook generator per tool. But at some point I re-copied the wrong webhook URL for Notion into the Zap sending updates.

And because the module does not check for duplicate webhooks across scenarios, I had two almost identical triggers silently fighting. The worse part? Neither one threw errors. One would intercept 70% of the messages and route them wrong; the other would occasionally catch one but be out of sync with the iterator loop.

Trigger timestamps didn’t match, Slack posted duplicates occasionally, and some team members got pinged twice in DMs by mistake since the routing logic ran half-cooked. No visual indicator, no webhook misfires in History tab. I discovered it by checking the scenario ID in the webhook logs—literally had to dig up the original scenario that endpoint was tied to, because Make doesn’t warn about endpoint collisions.

6. Slack limits on attachments hit hard when looping updates

Turns out Slack has a size limit—not just per message but per parent thread post. If you try to send looped updates with attachment blocks via Make, and the combined payload exceeds some undocumented threshold (different from the per-message limit), the last few updates won’t render, and Make doesn’t report any error.

This caused our ticket recap from Jira to get clipped mid-paragraph, ironically cutting off right where an engineer had explained the root cause of a rollout bug. Everyone thought he hadn’t written it—turned out it just got dropped.

The fix was to change the message type from attachments to text blocks and literally break them into separate messages using a 5000-character limit. Also added counters with emoji sequencing (e.g. :one: :two:) to track what landed.

7. Slack DMs from Make only work if bot is already visible

This one makes sense if you think about it, but feels broken till you realize how Slack scopes work. If you try to send a DM to a user via Make and your Slack bot user hasn’t ever manually interacted with them (via invite, command, prior message), the DM will not send. No error. Nothing.

I was confused why a specific onboarding reminder worked for newer hires but failed for two senior devs. Turns out their Slack preferences hid new bot messages unless they opted in, and Slack’s API treats those users as invisible.

We solved it by including a one-time announcement in a shared channel that mentioned the Make bot openly. After that, DMs worked fine. This behavior isn’t noted anywhere in Make’s Slack module either.

8. Router logic order makes Slack reactions misfire in loops

I had a loop that added emojis like ✅ or 🔥 based on labels pulled from Notion properties. Each label added a separate reaction to the same message—looked great when demoed inside a single test cycle.

But the moment multiple items came in per user, the router fired the reactions in an unpredictable order. Sometimes the same emoji got added three times, sometimes the wrong one was skipped.

Eventually I toggled the router’s setting from “execute immediately” to “execute after all routes” and inserted a 1-second delay before each Slack reaction. That forced enough separation between rate-limited API endpoints that Slack stopped rejecting excess requests. Also prevented the weirdness where Make would say a reaction posted successfully, but it never showed up after refresh.

“Slack’s emoji reactions have a max-per-user-per-message cap, and rate limit under 1 second response time” — buried in a bug thread somewhere on Zapier

If you’re trying to make reaction-based metadata work in threads, you have to rate-limit yourself—even if you think Make handles that internally.