API Monitoring Guide
Get alerted when the Discord API has issues before your bot goes silent, commands stop responding, or your community wonders why nothing works. Know the Discord API status in real time, not 15 minutes later.
Discord powers millions of communities, and bots are the backbone of moderation, support, games, and notifications. When the REST API at discord.com/api/v10 degrades or the gateway starts dropping sessions, your bot stops sending messages, slash commands time out, and webhook deliveries fail — usually with no error on your end.
This guide covers everything you need to monitor Discord API status: which endpoints to track, how the 50 req/s global limit and per-route buckets work, how to tell a Discord outage from a bot-side problem, and what to do when the API goes down.
Discord maintains a status page at discordstatus.com covering the API, gateway, voice, and media proxy. It's useful for confirming a platform-wide incident, but relying on it alone has real gaps.
External synthetic monitoring catches Discord API issues in 1-2 minutes, not 10-15. That head start lets you pause outbound jobs, fail over to a queue, or post a heads-up in your community before everyone notices the bot is dead.
"Discord API" spans several surfaces that fail independently. Knowing which one your bot depends on tells you what to monitor.
Always use a versioned path like /api/v10. Calling /api without a version defaults to an old, deprecated version that can change behavior or return errors that look like an outage.
Bot requests authenticate with Authorization: Bot <token>. Always send a descriptive User-Agent — Discord may reject default or missing user agents, which would look like a failure to your monitor.
Each endpoint below tests a different layer. Monitoring several lets you pinpoint whether it's REST, auth, the gateway, or your own bot host.
GET https://discord.com/api/v10/gateway
Gateway URL. Unauthenticated and cheap — returns the WebSocket URL bots should connect to. A great no-token reachability check for the Discord REST API edge. Validate the body contains "url".
GET https://discord.com/api/v10/users/@me
Bot identity. With Authorization: Bot <token>, this confirms your token is valid and the API is responding. A 401 here means your token was reset or revoked. Validate the body contains your bot's "id".
GET https://discord.com/api/v10/gateway/bot
Authenticated gateway info. Returns recommended shard count and your session_start_limit. Monitoring this warns you before you exhaust daily identify sessions, which would block reconnection.
GET https://your-bot-host.example.com/health
Your bot's own health endpoint. Catches crashes, OOMs, and stuck event loops on your side — failures Discord's status page will never show. Pair it with the Discord checks to separate "Discord is down" from "my bot is down".
GET https://your-interactions.example.com/discord
HTTP interactions endpoint (if you use one instead of the gateway). Discord posts signed slash-command payloads here. If it's down or fails signature verification, every slash command fails. Monitor reachability and TLS.
Rate limit note: Bots get a global limit of 50 requests/second plus per-route buckets. A monitor hitting a few endpoints every minute is well within budget. Just make sure your monitor sends a valid User-Agent and a correct token so it doesn't add to the invalid-request counter that triggers Cloudflare bans.
Discord's rate limiting can make a healthy API look broken from your bot's perspective. Understanding it is essential for both reliable bots and accurate alerting.
Bots are capped at 50 requests per second globally. Exceed it and you get HTTP 429 with X-RateLimit-Global: true and a retry_after value. Interaction responses are exempt from this global limit.
Each route (often per channel or guild) has its own bucket. Discord tells you which bucket and how much is left via headers:
When Remaining hits 0, wait Reset-After seconds before retrying that bucket.
Roughly 10,000 invalid requests (401/403/429) per 10 minutes per IP gets you a temporary Cloudflare ban — an HTML 429, not JSON, lasting up to an hour. A bot in a crash loop with a bad token can trigger this and take itself fully offline.
A JSON 429 with retry_after means you're throttled — back off and retry. An HTML 429 means a Cloudflare ban from invalid requests. A 503 or widespread timeouts point to an actual Discord incident. UptimeSignal records status codes and response times so you can tell these apart instantly.
Your bot runs on the Discord API. Monitor it yourself.
Get alerted when the REST API, gateway, or your bot host start failing — before your community notices the bot went quiet. Free for 25 endpoints, checks every 5 minutes.
Monitor Discord API free →Knowing the common failure patterns helps you configure monitoring that catches real problems and avoids false alerts.
If you regenerate the token in the Developer Portal or it leaks and gets reset, every authenticated call returns 401 Unauthorized. Monitoring /users/@me catches this immediately so you can redeploy with the new token.
Every reconnect with a fresh identify consumes a daily session start. A crash loop can burn the limit and lock your bot out of reconnecting. Monitoring /gateway/bot and watching session_start_limit.remaining warns you before that happens.
Sending in a loop without respecting headers triggers per-route or global 429s. Sustained 429s on your monitor signal a misbehaving deploy that could escalate to a Cloudflare ban.
Too many invalid requests get your host IP banned by Cloudflare with an HTML error page. Body validation distinguishes this from a normal JSON 429 — they need very different fixes (fix the bot vs. wait out the ban).
During Discord incidents, the gateway can stop delivering events or reject resumes while REST partially works. Your bot looks "online" but is deaf. Combining gateway-endpoint checks with your bot's own health endpoint surfaces this gap.
In the Discord Developer Portal → your application → Bot, copy the bot token (or reset it if you've lost it). You'll send it as Authorization: Bot <token>.
Security tip: A bot token is a full credential. Store it as a secret in your monitor, and consider a dedicated low-privilege bot just for health checks if your main bot has sensitive permissions.
Sign up at app.uptimesignal.io and add a new HTTP monitor:
For an unauthenticated check, point a second monitor at /api/v10/gateway with no token.
Add the gateway endpoint (edge reachability), /gateway/bot (sessions), and your bot's own health endpoint. Together they tell you whether a problem is Discord's or yours.
Route alerts where you'll see them fast:
If your bot serves large or active communities, use 1-minute checks (Pro plan) so you detect a token reset, ban, or gateway issue within a minute instead of five.
Configure your monitors to alert on these conditions:
For /gateway, check for "url"; for /users/@me, check for "id". Body validation distinguishes a real JSON response from a Cloudflare HTML error page returned with a 429 or 5xx — a status-only check can't tell them apart.
When monitoring alerts you to a Discord problem, here's how to respond and limit the impact on your community.
Check discordstatus.com by component. Determine if it's auth (401), rate limiting (JSON vs HTML 429), a gateway issue, or a REST outage (5xx). Each needs a different response.
If you're getting 429s, pause outbound message jobs and back off. Continuing to retry into a Cloudflare ban only makes the outage longer and more total.
If your bot sends time-sensitive notifications, queue them with idempotency keys so they go out once the API recovers instead of being lost. Prioritize critical alerts over chatty ones.
If only your bot's health endpoint is failing while Discord's endpoints are fine, the problem is yours — restart the process, check memory, and inspect your gateway connection logic.
Post a heads-up in a channel that's still reachable, or update your status page. If it's an upstream Discord incident, link the official status post to cut down on "is the bot broken?" questions.
curl -H "Authorization: Bot YOUR_TOKEN" https://discord.com/api/v10/users/@me. For continuous monitoring, set up UptimeSignal to poll every 1-5 minutes and alert you instantly when the status changes.
/api/v10/gateway as an unauthenticated reachability check, add /api/v10/users/@me to confirm your bot token, and /api/v10/gateway/bot to watch your session-start limit. Monitor your bot's own health endpoint too, so you can separate Discord outages from bot crashes.
X-RateLimit-Bucket, X-RateLimit-Remaining, and X-RateLimit-Reset-After headers. Exceeding a limit returns HTTP 429 with retry_after. Interaction endpoints are exempt from the global limit. Invalid requests (401/403/429) are themselves capped at ~10,000 per 10 minutes per IP before a Cloudflare ban.
/gateway and /gateway/bot endpoints let you health-check gateway availability over plain HTTPS.
X-RateLimit-Remaining. Read the headers and back off using retry_after. Cloudflare can also issue an HTML 429 (a temporary IP ban) when invalid requests pile up, so watch for sustained 429s after a deploy.
/api/v10/gateway/bot with your bot token — the response includes session_start_limit (total, remaining, reset_after, max_concurrency). Monitoring remaining session starts warns you before you exhaust your daily identify budget, which would block reconnection. Pair it with an HTTP health endpoint on your bot host to also catch crashes on your side.
UptimeSignal checks your endpoints from outside your network and catches errors before users do.
25 monitors free, unlimited for $10/month.
No password needed. We'll send a magic link.