# What to do when your Discord bot goes offline

> What to do when a Discord bot goes offline — telling in ninety seconds whether it is Discord, the bot, one shard or your server, and how to stay safe.

- Canonical: https://discordguides.blog/blog/discord-bot-offline
- Published: 2026-08-30
- Author: The Manual desk
- Facts checked: 2026-08-30
- Sources:
  - Discord Status (https://discordstatus.com) — checked 2026-08-30
  - Discord developer docs — Gateway and sharding (https://docs.discord.com/developers/events/gateway) — checked 2026-08-30
  - Discord developer docs — Gateway intents (https://docs.discord.com/developers/events/gateway) — checked 2026-08-30
  - Discord developer docs — Audit log (https://docs.discord.com/developers/resources/audit-log) — checked 2026-08-30
- Publication: The Manual, an independent site not affiliated with Discord Inc.

---
Check [discordstatus.com](https://discordstatus.com) first. If Gateway or API is degraded, every
bot in every server is affected and there is nothing to fix on your side. If Discord is healthy,
the next likeliest cause is the bot's own hosting, and the third is a single shard — a large bot can
be down for your server and fine for everyone else's.

Work through the checks below in order. Then read the last section, because a dark bot is a
moderation problem before it is a technical one.

## Is Discord itself degraded?

Open [discordstatus.com](https://discordstatus.com). It reports Gateway, API, Media Proxy, Push
Notifications, Search and Voice separately, plus each voice region and each client platform.

**Gateway** is the one that matters here. Bots hold a persistent gateway connection to receive
events; when Gateway degrades, bots disconnect and reconnect in waves, and they show grey in the
member list while they do it. **API** degradation is different — the bot stays online and its
actions fail.

If either is degraded, stop. Nothing you change in your server will help, and changes made during
an incident are the ones you forget to undo.

## Is the bot down for everyone?

Every serious bot publishes a status page and runs a support server. Both are usually linked from
the bot's website footer, and both answer this question in seconds.

[Vetox's status page](https://status.vetox.io) is a useful example of what to look for: it breaks
the platform into nine separately tracked components — the bot's gateway connection, its command
handling, the dashboard, the API, the CDN, the Vito API, the database, cache and message broker —
each showing its own current state and incident history. That granularity is the point. A single
bot-wide "operational" badge cannot tell you whether the one component you actually depend on is the
one that is degraded, which is the whole reason to check a status page rather than just guess from a
grey dot in the member list.

Two other quick reads:

- **Its Discord support server.** If the bot is broadly down, an announcement is normally posted
  there within minutes.
- **A second server you own that has the same bot.** If it is green there and grey in yours, the
  problem is scoped to your server or to one shard, and the next two sections apply.

## Is it one shard rather than the whole bot?

This is the cause almost nobody checks, and it is why "the bot is up, it says so on their status
page" and "the bot is down, I can see it" are frequently both true.

Discord requires large bots to split their connection across shards. Its documentation states:
"Each shard can only support a maximum of 2500 guilds, and apps that are in 2500+ guilds _must_
enable sharding." Which shard serves your server is fixed by your server's ID, through the formula
Discord publishes: `shard_id = (guild_id >> 22) % num_shards`.

The consequence is direct. **Your server is served by exactly one shard.** If that shard has
dropped, your server sees an offline bot while thousands of other servers see it working normally.
Nothing about your configuration is involved and nothing you change will help.

When you report the outage, say which server it is. A shard fault is invisible to the bot's team
until someone tells them which servers are affected, and the server ID is the fastest thing they
can act on.

## Is the bot still in your server?

An offline bot and a removed bot look similar at a glance, and a removed bot cannot come back on
its own.

Open **Server Settings**, then **Integrations**. A bot that is still installed is listed there. If
it is not, it was kicked, banned or removed — and Discord's audit log will tell you by whom. Note
the limit before you go looking: "All audit log entries are stored for 45 days." Past that window
the entry is gone.

Re-invite from the bot's own site. Do not accept an invite link from anyone else; that is the
standard route for a lookalike bot to get into a server that is already having a bad day.

## Is it offline but still working?

A bot can set its presence to invisible and appear grey in the member list while running perfectly.

The test takes five seconds: run one of its commands. If it answers, the bot is fine and the grey
dot is cosmetic. If it does not answer but you are convinced it is running, the problem is more
likely to be [in your server than in the bot](/blog/discord-bot-not-responding) — a permission
overwrite produces silence that looks identical to downtime.

Reloading the Discord client (Ctrl+R on desktop) also clears a stale presence, which is worth doing
once before concluding anything.

## If you host the bot yourself

Three causes account for most self-hosted outages, and all three are on your side.

1. **The process died.** Check your process manager and the last hundred lines of the log. An
   out-of-memory kill leaves nothing useful in the application log itself, so check the system log
   too.
2. **The token was reset or the app was deleted.** A reset token means the running process cannot
   reconnect and cannot recover without a new one.
3. **A privileged intent was requested without approval.** Discord names three —
   `GUILD_PRESENCES`, `GUILD_MEMBERS` and `MESSAGE_CONTENT` — and states that "Apps that qualify
   for verification **must** be approved for the privileged intent(s) before they can use them." A
   bot asking for an intent it does not hold fails to connect at all, and the error is a startup
   error rather than a runtime one.

## Keep the server safe while the bot is dark

This is the section that matters, and it is the one missing from most pages on this subject.
Downtime is not neutral. Every automated defence your server relies on has just stopped, and the
gap is exactly when a raid is cheapest to run.

What stops when a moderation bot goes offline: automated filters, join gates, verification flows,
raid detection, punishment expiry, welcome messages, logging. Anything that was going to catch
something now does not, and nothing records the fact.

Four things that keep working, because they run at the platform level rather than in a bot:

- **Discord's own AutoMod.** It runs before a message is delivered, and it is unaffected by any bot
  being down. If you have not configured it, an outage is the moment you wish you had — see
  [how to set up Discord AutoMod properly](/blog/set-up-discord-automod).
- **Verification level.** Raise it in Server Settings. The Highest setting requires a verified
  phone number and stops most throwaway accounts outright.
- **Slowmode.** Set it on your busiest public channels. It costs a regular member almost nothing
  and makes a spam wave ineffective.
- **Invite pausing.** Discord can suspend invites server-wide. It is the most effective single lever during an active [raid](/blog/protect-against-raids), and it works with every bot offline.

Two more habits worth having before you need them. Write down which of your defences are
bot-dependent, so you know what you have lost the moment one goes grey. And keep one moderator
account with the permissions to act by hand — an outage plus a locked-down permission model is a
worse combination than either alone.

## Afterwards

When the bot returns, three things need attention.

**Check what it missed.** Most bots do not backfill. Members who joined during the outage may have
skipped auto-roles, the welcome flow and the verification gate entirely. Members who should have
been punished were not.

**Reconstruct the gap from the audit log.** Discord's own record covers the outage window, and it
is the only record you have if your logging bot was the thing that was down. It holds 45 days, so
do this within the week rather than the quarter.

**Undo the emergency settings.** Verification level, slowmode and paused invites are all fine
temporarily and corrosive permanently. Put them back.

## Common questions

**Does an offline bot lose my configuration?**
No. Configuration for a hosted bot lives on the bot's servers, not in Discord, and it is unaffected
by the bot disconnecting. What is lost is the events that happened while it was gone.

**Should I kick and re-invite the bot to fix an outage?**
No. It does nothing for an outage on the bot's side, and with some bots a removal starts a data
retention timer. Re-invite only when the bot is genuinely no longer in the server, or when you are
adding a scope it never had.

**How long should I wait before reporting it?**
Ten minutes. Shorter than that and you are likely watching a restart; longer and you are the last
person to notice. Report it with the server ID, the time it started, and whether the bot is green
in your other servers.