Discord Bot "Missing Permissions" (50013) — Why It Isn't Your Hosting

Missing Permissions with error code 50013 is one of the few bot failures that looks like a deployment problem and never is — your code ran, reached Discord, and Discord declined. There are three usual causes, and they're worth separating because the fixes are unrelated. A channel overwrite is denying something the bot has at server level. The bot is trying to act on a role or member positioned above its own highest role, which no permission flag can fix. Or a permission it needs was never granted at invite time. Only the last one is about ticking a box.

Server permissions aren't the final answer#

The mistake almost everyone makes is checking the bot's role in Server Settings, seeing the permission enabled, and concluding the permission exists. Channel-level overwrites are applied on top, and they're applied in a specific order — first the @everyone overwrite, then role overwrites (combining all allows and denies), and finally any member-specific overwrite (Discord docs).

So a bot with Send Messages at server level can be denied it in exactly one channel — usually the one you're testing in — by an overwrite nobody remembers adding.

Check the channel, not the server. Open the channel's permission settings and look at what applies to your bot's role specifically.

While you're there, note the implicit dependencies. Per the docs, "denying a user or a role VIEW_CHANNEL on a channel implicitly denies other permissions on the channel" — the bot can't act on what it can't see. Denying SEND_MESSAGES similarly blocks things that depend on it, like MENTION_EVERYONE and ATTACH_FILES. If a bot appears to be missing several unrelated permissions in one channel, look for a single denial underneath them.

Role hierarchy, which permissions can't override#

This is the one that produces genuine confusion, because the bot has Administrator and still fails.

The rule: "A bot can only kick, ban, and edit nicknames for users whose highest role is lower than the bot's highest role." Position in the role list, not permissions, decides this. A bot cannot act on a member or role at or above its own highest position — Administrator does not help, because hierarchy isn't a permission.

Symptoms that point here:

• Kick and ban work on most members and fail on moderators.
• Adding a role works for some roles and not others.
• The bot can't change a specific member's nickname but can change others'.

The fix is dragging the bot's role higher in the list, above whatever it needs to manage. Nothing in your code or your hosting changes this.

One related trap: a bot can never edit the server owner, regardless of position.

The permission was never granted#

The third cause, and the simplest. The invite URL carries a permissions integer, and the bot has what was granted when it was added — not what you enabled in the Developer Portal afterwards.

If you added a permission to your bot's default invite settings after inviting it, the existing installation doesn't have it. Re-invite the bot with an updated URL; re-authorising updates the granted permissions without removing it from the server.

Worth checking at the same time whether the invite included the applications.commands scope, since missing that produces a different confusing failure where registration succeeds and nothing appears.

Administrator is not the diagnosis you want#

Granting Administrator makes most 50013s disappear — it "allows all permissions and bypasses channel permission overwrites" — and it's a bad habit for two reasons.

It doesn't fix hierarchy problems, so the confusing subset survives and you've lost the signal that would have explained it. And it means a compromised bot token is a compromised server. Since a leaked token is a routine incident with a routine fix, it's worth not making the blast radius total.

Grant what the bot uses. If you're unsure what that is, the failures tell you one at a time, which is tedious once and correct afterwards.

Handle it in code, too#

A permission error shouldn't look like a crash. Catch it, write a line to your logs naming the permission and the channel, and tell the user something actionable:

except discord.Forbidden:
    log.warning("missing permission in channel %s", channel.id)
    # reply somewhere you *can* write, if anywhere

Two hosting-adjacent notes. An unhandled Forbidden that propagates out of your event loop can take the process down — which restarts you, and for a bot that connects first, every restart has a cost. And a permission error in a startup routine is worse than one in a command handler, because it turns a partial failure into a crash loop.

Log the channel ID, not just the error. "Missing Permissions" without a location is a message you'll read three times before it helps.

A two-minute diagnosis#

1. Does it fail everywhere, or in one channel? One channel → overwrite. Everywhere → granted permissions.
2. Does it fail only for certain members or roles? → hierarchy. Move the bot's role up.
3. Did it work before and stop? → someone changed a channel overwrite or moved a role.
4. Is the permission enabled at server level? If yes and it still fails, you're in case 1 or 2, not case 3.

Nothing in this list involves your logs, your build, or your host — a useful thing to establish early, because 50013 arrives looking like everything else that goes wrong after a deploy.

FAQ#

What does Discord error 50013 mean?#

The bot lacks permission for the action it attempted. It's an authorisation response from Discord, not a failure in your code or hosting.

My bot has the permission but still gets 50013.#

Check the channel's overwrites, which apply on top of server permissions. If it's failing only for certain members, it's role hierarchy instead.

Why can't my bot kick a moderator?#

A bot can only act on members whose highest role is below its own. Move the bot's role higher; Administrator doesn't override hierarchy.

Do I need to re-invite my bot after adding a permission?#

Yes. The installation keeps what was granted at invite time. Re-authorising with an updated URL applies the change.

Should I just give the bot Administrator?#

It hides the diagnosis and makes a leaked token catastrophic. Grant what it uses instead.

Could my hosting cause permission errors?#

No. The request reached Discord and was refused. Hosting affects whether your process is running, not what it's allowed to do.

Wrapping up#

Permissions are the second-most common "it's not the host" bot problem after intents, and they're confusing for a specific reason: two independent systems decide the answer, and only one of them is a checkbox. Look at the channel before the server, remember that hierarchy is position rather than permission, and re-invite after changing what you grant. Then handle Forbidden deliberately in code, so the next one arrives as a log line naming a channel instead of a restart.