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.

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.

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:

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.
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 instead.

The five-minute diagnosis

Run these in order and stop at the first failure.

Bot is online — green dot in the member list.
Bot can see the channel — it appears in that channel’s member list.
Commands appear — type / and find the bot by name.
Command runs for you — as an administrator, in the channel in question.
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 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.

Why your Discord bot is not responding