Wer schon einmal einen Discord-Bot veröffentlicht hat, kennt es: ein ganz normaler Dienstag, und plötzlich steht überall increased api errors, und die Hälfte deiner Befehle schlägt fehl. Google Trends hat die Wendung Mitte 2026 als „Breakout“-Suchbegriff erfasst. Das passiert so oft, dass Endnutzer direkt danach suchen. So kommst du durch solche Phasen, und was die Server-API von Noxyr aus diesen Erfahrungen übernommen hat.

A request gets a 429, waits out a countdown, then retries and succeeds with a 200. Server 429 200 3 2 1 Retry-After

Die drei häufigsten Fehlerarten der Discord-API

  • Globaler Ausfall / Teilausfall: sichtbar auf discordstatus.com. Symptome: jede Anfrage kann fehlschlagen, das Gateway kann abbrechen, die Latenz steigt überall.
  • 429 Too Many Requests: du hast das Limit eines Buckets überschritten. Discord sendet einen Retry-After-Header, der genau angibt, wie lange du warten sollst.
  • Gateway invalid session: deine WebSocket-Sitzung ist veraltet. Verbinde dich mit deinem Resume-Token neu. Schlägt das fehl, identifiziere dich neu.

Auf Fehler auslegen, nicht auf Sonnenschein

  • Retry-After respektieren. Versuch es nicht mit deinem eigenen Timer erneut. Warte genau die Zeit, die Discord angibt, und versuche es dann einmal erneut. Bots, die sich durch 429er hämmern, werden gesperrt.
  • Exponentielles Backoff mit Jitter. Bei 5xx-Fehlern wartest du 1 s, 2 s, 4 s, 8 s, plus einen kleinen Zufallsversatz, damit eine Flotte von Neustarts nicht gleichzeitig loslegt.
  • Unkritische Aufrufe mit einem Circuit Breaker absichern. Postet dein Bot eine wöchentliche Zusammenfassung und ist die Discord-API gerade beeinträchtigt, überspringst du diesen Durchlauf, statt die Last zu erhöhen. Die Zusammenfassung kann warten, der Ausfall nicht.
  • Alles zwischenspeichern, was nicht in Echtzeit sein muss. Servernamen, Kanallisten, Rollen-IDs lokal cachen. Während eines Ausfalls kannst du mit den gecachten Daten weiter antworten.
  • Status anzeigen. Schlagen die Befehle deines Bots fehl, weil Discord gerade down ist, sag es den Nutzern. Eine Zeile wie „Discord hat gerade Probleme“ ist besser als stille Timeouts.

Wie die Noxyr-Server-API diese Erkenntnisse anwendet

Die Noxyr-Server-API ist nicht die Discord-API. Sie liest aus der eigenen Datenbank. Dieselben Prinzipien gelten aber trotzdem und haben ihr Design geprägt:

  • Vorhersehbare Fehler: jeder Fehler ist JSON mit einem stabilen error-Code. Kein HTML, keine wechselnden Formate.
  • Ratenlimit-Header: standardisierte RateLimit-*-Header, damit Clients zurückschalten, bevor sie einen 429 bekommen.
  • Sanfter Rückzug: der Endpunkt /api/v1/server greift auf gecachte Serverdaten zurück, wenn der zugrunde liegende Discord-Abruf fehlschlägt.
  • Keine Kaskadenfehler: jeder Endpunkt fällt unabhängig aus. Ist Discord down, bricht dein Endpunkt für Ticket-Analysen nicht, weil er aus Mongo liest und nicht von Discord.
  • Sofortiger Notausschalter: das Deaktivieren eines Schlüssels oder eines Bereichs wirkt bereits bei der nächsten Anfrage, ohne Neustart.

Ablauf, wenn Discord aus dem Ruder läuft

  • 1. Prüfe zuerst discordstatus.com. Bist nur du betroffen?
  • 2. Schau in deine eigenen Fehlerprotokolle: 429er, 5xx, Gateway-Trennungen.
  • 3. Liegt es an Discord: pausiere unkritische Schreibvorgänge, halte dich an Retry-After und warte ab.
  • 4. Liegt es an dir: prüfe letzte Deployments, Cache-Invalidierungen und neue Funktionen.
  • 5. Kommuniziere. Ein kurzer, ehrlicher Hinweis im Support-Kanal verhindert 100 doppelte Meldungen.

Mehr zur API-Schicht: die Noxyr-Server-API, Discord-API vs. Noxyr-API, Prinzipien für API-Design.