Slack Bot Not Responding to @Mentions? 9 Causes We Reproduced

A Slack bot that does not answer an @mention is, most often, missing one of three things: it is not a member of the channel, the app is not subscribed to the app_mention event, or the app was not reinstalled after app_mentions:read was added. We reproduced each of those and six more causes on 1 October 2026 with two throwaway apps, one in Socket Mode with Bolt for Python and one on an HTTP request URL behind a cloudflared tunnel. For each one we recorded what the person typing saw in Slack and what reached the app.

Causes, symptoms and fixes from our runs

The first three: channel, event, scope

Not in the channel. When we typed @sglabw2 in a channel the bot had not joined, the mention menu already marked it "Not in channel". After sending, Slackbot posted this, visible only to us:

No event reached the app. When we clicked Add Them, Slack added the bot and then delivered the original mention, 18 seconds after it was sent, and the bot replied in the thread. The same membership rule makes chat.postMessage fail with not_in_channel.

Not subscribed to app_mention. Our first app subscribed only to message.channels. A mention arrived as a plain message event with <@U0C5QDUGPV1> in the text and no app_mention event, so an @app.event("app_mention") handler never ran.

Scope missing. We tried to add the event without the scope through apps.manifest.update. Slack refused the change:

{"ok": false, "error": "invalid_manifest", "errors": [{"code": "app_mention_event_missing_scope", "message": "app_mention event is missing scope(s): app_mentions:read", "pointer": "/settings/event_subscriptions", "related_component": "oauth"}]}

So a saved app cannot subscribe to app_mention without app_mentions:read. The same error blocks the manifest editor in the UI. Writing manifests by hand is covered in Slack app manifest, tested.

Added the scope but did not reinstall

With both the scope and the event in the manifest, the update returned "permissions_updated": true and the app's settings pages showed this banner:

We mentioned the bot before reinstalling. The app received only the message event, and auth.test on the bot token returned an x-oauth-scopes header without app_mentions:read. After we reinstalled, the next mention delivered app_mention and the bot replied. The bot token string did not change. Scope errors on API calls look different; they are covered in Slack missing_scope.

Crashes and a stopped Socket Mode process

This is the handler we ran in Bolt for Python, with a switch to make it raise:

@app.event("app_mention")
def on_mention(event, say):
    if flags().get("crash"):
        raise RuntimeError("handler crashed on purpose")
    say(text=f"Got your mention: {event.get('text', '')[:60]}", thread_ts=event["ts"])

With the switch on, the event arrived once and the log showed:

ERROR:slack_bolt.App:Failed to run listener function (error: handler crashed on purpose)

Slack did not send it again. Bolt acknowledges an event before your function runs, so from Slack's side the delivery succeeded. Nobody in the channel sees an error.

We then stopped the Socket Mode process, mentioned the bot, and started the process again 150 seconds later. The event did not arrive on reconnect. It arrived 360 seconds after the message, 210 seconds after the restart, and the bot replied then, so the person got an answer 6 minutes late. Slack Socket Mode in Python has more on connections.

HTTP request URLs: slow answers and dead URLs

An HTTP app must answer each event within 3 seconds. Our endpoint waited 5 seconds before answering. Slack sent the same app_mention four times:

A bot that posts a reply each time it handles the event posts four replies. Answer with HTTP 200 first and do the slow work after, or skip requests that carry X-Slack-Retry-Num once you have handled the first one. The retry schedule and headers are measured in more detail in Slack Events API retries. When we made the endpoint return 500 instead, the retries came with X-Slack-Retry-Reason: http_error, starting after 0.3 seconds.

apps.manifest.update accepted a request URL on a host that does not exist and returned ok: true, without sending a challenge. Mentions made while that URL was set reached nothing. The Event Subscriptions page showed the problem, plus a Delayed Events switch that retries missed events over 24 hours:

After we put the working URL back, the mention made in between arrived within a minute, as retry 2. Checking the signature on these HTTP requests is covered in verify Slack request signatures.

FAQ

Why does my bot answer its own messages?

In our Bolt app, the bot's own chat.postMessage posts never reached a handler: Bolt drops them by default. Posts from the same app's incoming webhook did come back, as 292 message events with bot_id B0C5UMRDJJJ, which is not the bot's own B0C5WFWMXT4. If your handler answers message events, skip any event that carries bot_id, as shown in Slack thread_ts, tested.