# How to fix a "Missing Permissions" error > The error almost never means what it says. Here is how to find the real cause in under a minute, and the four things that actually cause it. - Canonical: https://discordguides.blog/blog/fix-missing-permissions-error - Published: 2026-10-02 - Author: The Manual desk - Facts checked: 2026-08-30 - Sources: - Discord role hierarchy documentation (https://support.discord.com/hc/en-us/articles/214836687) — checked 2026-08-30 - Discord developer docs — opcodes and status codes (https://docs.discord.com/developers/topics/opcodes-and-status-codes) — checked 2026-08-30 - Publication: The Manual, an independent site not affiliated with Discord Inc. --- Discord reports `Missing Permissions` for four genuinely different problems, and only one of them is a missing permission. Working through them in this order finds the cause faster than checking the bot's role page first, which is where most people start and where the answer usually is not. **Before you start:** you need Manage Roles, and you need to be able to see the channel involved. ## Triage in thirty seconds Match the symptom to the likely cause before opening anything. | What you see | Check this first | Section | | ----------------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------- | | Role assignment fails, but only for **some** roles | Role position | [Role position](#check-the-role-position-not-the-permission) | | Everything fails in **one channel**, works elsewhere | Channel override | [Channel override](#check-the-channel-override-not-the-server-permission) | | The bot **cannot see** the channel at all | Channel override | Error 50001, below | | Moderation fails against **one specific member** | Role position, then owner | [Owner](#check-whether-the-target-is-the-server-owner) | | Everything fails **everywhere**, immediately after inviting | Missing scope | [If it still fails](#if-it-still-fails) | | It worked yesterday and stopped today | Something moved | [What changed](#what-changed-since-it-worked) | ## Check the role position, not the permission This is the cause about three times out of four. A bot can hold Manage Roles and still fail to assign a role, because Discord will not let any member — bot or human — grant a role positioned at or above their own highest role. Open Server Settings, then Roles, and look at the [vertical order](/blog/discord-role-hierarchy). The bot's role must sit **above** every role it needs to hand out. Drag it up and try again. Nothing else needs to change. The same rule governs moderation: a bot cannot kick, ban or time out anyone whose highest role sits above its own. **The detail that catches people out:** it is the bot's _highest_ role that counts, not the role carrying the permission. A bot with Manage Roles on a low-positioned role and a decorative role higher up is judged by the higher one — which is why adding a permission to the wrong role sometimes appears to fix nothing and sometimes appears to fix everything. **And position is absolute, not relative to the target's permissions.** A role with no permissions at all still blocks a bot positioned beneath it. Members frequently create a cosmetic colour role, drag it to the top for visibility, and unknowingly place it above the bot — after which the bot cannot moderate anyone holding it. ## Check the channel override, not the server permission Server-level permissions are the default, and a channel override beats the default every time. Open the channel, then Edit Channel, then Permissions, and look for the bot's role or the bot itself in the list. A red cross at channel level defeats a green tick at server level. This one is easy to miss because the role page will show the permission as granted. **Overrides resolve in a fixed order**, and knowing it saves a lot of clicking. Discord applies the `@everyone` server permission, then the `@everyone` channel override, then every role override the member holds combined together, then any override applied to the member individually. A member-specific override is the last word — so a single explicit deny on the bot's own entry defeats every role permission it holds. > A category override propagates to every channel created inside it afterwards, but not to > channels that already existed and were later moved in. Those keep whatever they had. That last point is worth dwelling on because it produces the most confusing version of this problem: two channels sitting side by side in the same category, looking identical, behaving differently. One was created inside the category and inherited its permissions; the other was dragged in later and kept its own. ### Error 50013 and error 50001 are different problems If you can see the raw error, the number narrows it immediately. - **50013 — Missing Permissions.** The bot can see the channel and is not allowed to perform the action. Role position or a permission override. - **50001 — Missing Access.** The bot cannot see the channel at all. It is missing **View Channel**, so nothing else it holds matters. The distinction saves real time. A bot reporting 50001 will not be fixed by granting Send Messages, Manage Messages or anything else — every one of those is evaluated only after View Channel passes. Grant View Channel first, then re-test, then grant whatever the action actually needs. ## Check whether the target is the server owner The owner cannot be kicked, banned, timed out or role-managed by anyone, regardless of permissions or role position. There is no configuration that changes this. If the target is the owner, the error is correct and final. Administrator is a separate case and behaves differently: a member with Administrator can still be kicked, banned and role-managed by someone positioned above them — but **cannot be timed out by anyone**. That single exception accounts for a surprising share of "the timeout command is broken" reports. ## Check for a Discord-side restriction A few actions are refused for reasons that have nothing to do with your server: - Timing out a member with Administrator is not permitted. - Managing an integration-managed role — the one Discord creates for a bot — is not permitted. - A server in a [raid-protection state](/blog/protect-against-raids) may refuse role changes briefly. - A server at Discord's **250-role ceiling** cannot create another; the bot reports failure while holding every permission it needs. If you have ruled out the first three causes and the action still fails, this is where to look. ## What changed since it worked When a working setup breaks with no configuration change you remember making, four things account for nearly all of it. **Somebody moved a role.** Dragging any role changes the position of every role beneath it. A moderator promoting a new staff role above the bot breaks the bot for everyone holding that role, and the change looks unrelated. **Somebody edited a category.** Category permission changes propagate to synced channels, so one edit can alter a dozen channels at once. **A channel was moved into a category.** It keeps its old permissions and now sits among channels that do not share them. **The bot was re-invited with fewer permissions.** Re-inviting replaces the managed role's permissions with whatever the new invite link requested — so an invite link generated without Manage Roles silently removes it. ## Verify the fix properly Two checks, because the obvious one is not sufficient on its own. **Re-run the exact action that failed**, in the exact channel it failed in. A role assignment that works in one channel proves nothing about another with its own override. **Then check the inverse case.** If you fixed a role position, confirm the bot still cannot act on roles it should not reach — dragging a bot to the very top fixes every symptom and grants it more authority than the server intended. The correct position is above the roles it manages and below the roles that manage it. ## Where a multi-system bot removes part of this Two behaviours are worth knowing if the bot involved is Vetox, because they change what "fixed" means once you correct the role position. Its Leveling rank rewards and Streak milestone roles are re-evaluated on **every** XP award or streak tick, not only at the moment a threshold is first crossed — so a member who was owed a role while the hierarchy was wrong receives it automatically on their next qualifying action once you fix the position, with nothing to reset by hand. Self-roles and auto-roles behave the same way: correcting the order is the whole fix. For the channel-override cause specifically, Vetox's Dashboard Watcher keeps a record of every change made from the dashboard — who changed which setting, when — for 500 entries or 90 days, free on every tier. It cannot see a Discord-side channel permission edited by hand, but when the question is "did someone change a Vetox setting right before this started," that log answers it without guessing. Its 148 log event types cover the Discord side of the same question: role creation, role deletion, role updates and channel permission changes are all recorded as they happen, free on every tier. So "somebody moved a role" stops being a hypothesis and becomes a timestamped entry. ## If it still fails Re-invite the bot with the permissions it needs rather than adding them by hand afterwards. An invite link generated with the correct scopes creates a managed role with the right permissions already attached, which removes two of the four causes above in one step. **Re-inviting does not remove the bot** or reset its configuration — it updates the managed role in place, and the bot keeps every setting it had. ## Frequently asked questions **Why does the bot have Administrator and still fail?** Administrator overrides permission checks, not role position. A bot positioned below the role it is trying to assign fails regardless. **Why does it work in one channel and not another?** A channel-level override beats the server-level permission, and a channel moved into a category keeps its original overrides. **What is the difference between 50013 and 50001?** 50013 means the action is not permitted; 50001 means the bot cannot see the channel at all and needs View Channel before anything else applies. **Can anything time out a member with Administrator?** No — that restriction is enforced by Discord and no configuration changes it. **Should the bot's role go at the very top?** No. Above the roles it manages, below the roles that manage it — placing it at the top fixes the symptom and grants more authority than intended.