# Why your Discord bot is not responding

> Why a Discord bot is not responding — nine causes, ordered by how often they are the answer, starting with a channel overwrite silently swallowing it.

- Canonical: https://discordguides.blog/blog/discord-bot-not-responding
- Published: 2026-08-30
- Author: The Manual desk
- Facts checked: 2026-08-30
- Sources:
  - Discord developer docs — Receiving and responding to interactions (https://docs.discord.com/developers/interactions/receiving-and-responding) — checked 2026-08-30
  - Discord developer docs — Application commands (https://docs.discord.com/developers/interactions/application-commands) — checked 2026-08-30
  - Discord developer docs — Gateway intents (https://docs.discord.com/developers/events/gateway) — checked 2026-08-30
  - Discord developer docs — Rate limits (https://docs.discord.com/developers/topics/rate-limits) — checked 2026-08-30
- Publication: The Manual, an independent site not affiliated with Discord Inc.

---
A bot that ignores you is usually running fine. The commonest cause is a **channel permission
overwrite** denying View Channel, Send Messages or Use Application Commands in the one channel you
are testing in. Check that channel's permissions before you check anything else. The causes below
are ordered by how often each turns out to be the answer.

**Before you start:** you need Manage Server to see the bot's settings and Manage Roles to change
them. Keep a second account without staff roles to hand — half of these faults are invisible to an
administrator.

## Is the bot online at all?

Open the member list and find the bot. A grey dot means it is not connected to Discord, and nothing
below will help until that changes. That is a different problem with a different fix — see
[what to do when your bot goes offline](/blog/discord-bot-offline).

A green dot means the bot is connected and the fault is in your server, not in the bot.

## Can the bot see and speak in this channel?

This is the answer more often than every other cause combined, and it produces no error message of
any kind. The command appears to run and nothing happens.

Open the channel, then **Edit Channel** and **Permissions**. Look for the bot's role in the list,
and for the bot's own user entry. Three permissions matter:

| Permission               | Symptom when denied                                    |
| ------------------------ | ------------------------------------------------------ |
| View Channel             | The bot cannot read or reply. Total silence.           |
| Send Messages            | The command runs, the reply never arrives.             |
| Use Application Commands | The bot's commands do not appear in the picker at all. |

A red cross at channel level beats a green tick at server level. That is the whole rule, and it is
why the bot's role page can show every permission granted while the bot sits mute in one channel.
The same logic drives most [Missing Permissions errors](/blog/fix-missing-permissions-error).

If you are testing inside a thread, check the parent channel as well. A thread inherits from its
parent, and a private thread additionally requires the bot to be added to it.

## Do the bot's commands appear in the slash picker?

Type `/` in the channel and look for the bot's name in the list.

If it is missing entirely, the bot was invited without the `applications.commands` scope. Discord's
documentation is explicit: "To create commands in a guild, your app must be authorized with the
`applications.commands` scope." A bot invited with only the `bot` scope joins the server, appears
in the member list, holds its permissions — and registers no commands.

**The fix is a re-invite, not a permission change.** Generate a fresh invite link from the bot's own
site or dashboard and authorise it for the same server. The bot does not leave and rejoin, and you
lose no configuration; the authorisation is widened in place.

## Is the command hidden from one member and not from you?

If the commands appear for you but not for a member, the difference is Use Application Commands at
the role level, or the bot's own per-command restrictions.

Check both, in this order:

1. **Server Settings, then Roles, then the member's role, then Use Application Commands.** Denied
   here, the command vanishes from that member's picker while staying visible in yours.
2. **The bot's own command settings.** Most configurable bots let you restrict a command to
   specific roles or channels, and a restriction set months ago is easy to forget.

## Why does it say "The application did not respond"?

That message means Discord delivered the interaction and the bot did not answer in time. Discord
allows three seconds: "you **must send an initial response within 3 seconds of receiving the
event**. If the 3 second deadline is exceeded, the token will be invalidated."

Nothing in your server causes this. It is the bot being slow, and there are three readings:

- **It happens on one command only.** That command does heavy work — rendering an image, reading a
  large leaderboard — and is not deferring its response. Report it to the bot's developers with the
  command name.
- **It happens on every command, intermittently.** The bot is under load or one of its dependencies
  is degraded. Check the bot's status page.
- **It happens on every command, always.** The bot is misconfigured on its own side, or it has been
  removed from the server and Discord is still offering stale commands. Re-invite it.

"Interaction failed" is the same condition surfaced differently, and the same three readings apply.

## Did a prefix command stop working when slash commands still work?

Prefix commands — `!ban`, `?help` — depend on the bot reading message content, and Message Content
is a **privileged intent**. Discord's gateway documentation lists three privileged intents,
`GUILD_PRESENCES`, `GUILD_MEMBERS` and `MESSAGE_CONTENT`, and states that "For verified apps
(required for apps in 100+ guilds), the intent must also be approved after the verification process
to use the intent."

A bot that never obtained that approval, or lost it, can no longer read `!command`. Its slash
commands are unaffected. If prefix commands died and slash commands did not, this is why, and only
the bot's developers can resolve it.

## Is the feature switched off in the bot's own configuration?

Bots that ship dozens of systems generally ship them switched off, so that adding one does not
flood a server with behaviour nobody asked for. The command then exists, runs, and reports nothing
useful.

Vetox is built that way deliberately. Its Server Setup switchboard carries **30 module toggles — 20
systems, 2 AI and 8 notification platforms — and every one of the 30 defaults to off**, so a
feature does nothing until it is enabled on the dashboard. Under that sits a second layer: each
individual command has its own enable switch, role allow and deny lists, channel allow and deny
lists, and optional prefix-free aliases. When a Vetox command reports that it is disabled, one of
those two layers is the reason, and both live on the dashboard rather than in Discord.

Whatever bot you run, the check is the same. Open its dashboard, confirm the feature is enabled,
and confirm the command is not restricted to a role or a channel you are not testing in.

## Could the bot be rate limited?

Discord allows "up to 50 requests per second to our API" per bot globally, and separately restricts
IP addresses that make too many invalid requests — the current threshold is "10,000 per 10 minutes."

A bot at either ceiling replies late or not at all. You cannot fix this from your server, and it is
rare enough to sit near the bottom of this list, but it explains a bot that answers some commands
and drops others during a busy hour.

## Did you just change a permission?

Discord applies permission changes quickly, but a bot that caches your server's configuration may
not see a dashboard change immediately. Give it a minute before deciding the change did not work,
and prefer re-running the command over re-inviting the bot.

Role position is the exception: moving a role in the hierarchy takes effect at once. If the change
was meant to let the bot hand out a role, read
[why your bot cannot assign a role](/blog/discord-bot-cant-assign-role) instead.

## The five-minute diagnosis

Run these in order and stop at the first failure.

1. **Bot is online** — green dot in the member list.
2. **Bot can see the channel** — it appears in that channel's member list.
3. **Commands appear** — type `/` and find the bot by name.
4. **Command runs for you** — as an administrator, in the channel in question.
5. **Command runs for a normal member** — from a second account with no staff roles.

Step 4 passing while step 5 fails is a permissions problem in your server, and
[which permissions a bot actually needs](/blog/discord-bot-permissions-explained) covers what to
grant. Steps 1 to 3 failing are each covered above. If all five pass and the bot still misbehaves,
the fault is in the bot, and the useful next step is its support server — with the command name,
the channel type and the exact error text.