Du deployest am Freitagmittag (ja, ich weiß), alles sieht gut aus, und dann leuchtet dein Monitoring wie ein Weihnachtsbaum. Benutzer bekommen 429-Fehler. Deine API lehnt Anfragen ab. Oder vielleicht auch andersherum — du rufst eine Drittanbieter-API auf und sie lehnt dich ab. Wie dem auch sei, der HTTP 429 Too Many Requests Statuscode ist gerade das Wichtigste in deinem Tag.

Ich war schon auf beiden Seiten davon. Ich habe aus Versehen eine CMS-API DDoS-t, weil ein Build-Prozess falsch konfiguriert war, und ich habe Rate Limiting implementiert, um unsere eigenen Server vor unkontrollierten Clients zu schützen. Beide Erfahrungen haben mir Dinge beigebracht, die die Dokumentation nicht abdeckt. Lass uns alles durchgehen.

Inhaltsverzeichnis

HTTP 429 Too Many Requests: Ursachen, Lösungen und Rate Limiting

Was bedeutet HTTP 429 wirklich?

HTTP 429 ist in RFC 6585 definiert, veröffentlicht 2012. Die Spezifikation ist überraschend kurz. Hier die Essenz: Der Benutzer (oder Client) hat zu viele Anfragen in einer gegebenen Zeitspanne gesendet.

Das ist alles. Es ist eine Rate-Limiting-Response. Der Server sagt: "Ich habe deine Anfrage verstanden, sie ist wahrscheinlich gültig, aber du musst langsamer werden."

Das ist anders als 403 Forbidden (du darfst nicht) oder 503 Service Unavailable (der ganze Server hat Probleme). 429 ist gezielt. Es geht um deine Anfragerate speziell.

Die Response SOLLTE einen Retry-After Header enthalten, der dem Client sagt, wie lange er warten soll, bevor er es erneut versucht. Ich sagte "sollte", denn viele APIs kümmern sich darum nicht, was das Leben allen schwerer macht.

Wo du 429s in der Praxis siehst

  • Drittanbieter-APIs: Stripe, OpenAI, GitHub, Contentful, Sanity — alle haben Rate Limits
  • CDNs und Hosting-Plattformen: Vercel, Cloudflare und AWS geben 429s zurück, wenn du ihre Edge-Rate-Limits überschreitest
  • Deine eigenen APIs: Wenn du Rate Limiting implementiert hast (und du solltest)
  • Build-Prozesse: Statische Website-Generierung, die für jede Seite eine CMS-API aufruft, kann einfach Rate Limits auslösen
  • Web-Scraping: Wenn du aggressiv Daten aus externen Quellen abrufst

Häufige Ursachen für 429-Fehler

Lass mich die Szenarien aufschlüsseln, denen ich tatsächlich in Production begegnet bin, grob nach Häufigkeit geordnet.

1. Statische Website-Builds, die eine Headless CMS bombardieren

Das ist das, das Teams, die mit Headless-Architekturen arbeiten, am meisten beißt. Du hast eine Site mit 2.000 Seiten, jede braucht Daten von deinem CMS. Dein Build-Prozess feuert all diese Anfragen parallel ab, das CMS sieht einen massiven Anstieg und fängt an, 429s zurückzugeben. Dein Build schlägt fehl.

Wir sehen das regelmäßig, wenn wir an Headless-CMS-Projekten arbeiten. Die Lösung beinhaltet Request-Queuing und Concurrency-Limits, die ich unten behandle.

2. Fehlender oder kaputtes Caching

Wenn jedes Seiten-Load ein frischer API-Aufruf auslöst, weil deine Caching-Schicht nicht funktioniert, wirst du schnell Rate Limits treffen — besonders bei Traffic-Spitzen. Ich habe einmal eine Next.js-App debuggt, bei der revalidate versehentlich auf 0 gesetzt war, was bedeutete, dass ISR effektiv deaktiviert war. Jeder Besucher löste einen neuen API-Aufruf zu Contentful aus. Es brauchte etwa 45 Minuten echter Traffic, um 429s zu bekommen.

3. Retry-Schleifen ohne Backoff

Dein Code bekommt einen Fehler, versucht es sofort erneut, bekommt einen anderen Fehler, versucht es sofort erneut... herzlichen Glückwunsch, du hast eine Rate-Limit-Trigger-Maschine gebaut. Ich habe dieses Muster in Webhook-Handlern, Background-Jobs und sogar Client-seitigen Fetch-Aufrufen gesehen.

4. Mehrere Services teilen einen API-Key

Deine Staging-Umgebung, deine Production-Umgebung, dein lokales Dev-Setup und deine CI/CD-Pipeline verwenden alle denselben API-Key. Jeder sieht einzeln in Ordnung aus, aber zusammen verbrennen sie dein Rate-Limit-Budget.

5. Client-seitiger Fetch ohne Debouncing

Eine Search-as-you-type-Funktion, die bei jedem Tastendruck einen API-Aufruf auslöst. Ein Dashboard, das alle 500ms abfragt. Ein Infinite Scroll, der Fetches schneller auslöst, als der Benutzer scrollen kann. Diese Muster können absolut 429s auslösen, besonders wenn sie über alle deine Benutzer multipliziert werden.

6. Tatsächlicher Missbrauch oder Angriff

Manchmal macht 429 genau das, was es sollte — deinen Server vor jemandem schützen, der eine unangemessene Anzahl von Anfragen sendet. Bots, Credential Stuffing, Scraping — Rate Limiting ist deine erste Verteidigungslinie.

Der Retry-After Header erklärt

Der Retry-After Header ist die Art des Servers, dir genau zu sagen, wann du es erneut versuchen solltest. Er kann in zwei Formaten kommen:

Sekunden zum Warten:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Spezifisches Datum/Uhrzeit:

HTTP/1.1 429 Too Many Requests
Retry-After: Thu, 01 Jan 2026 00:00:00 GMT

Das Sekundenformat ist bei weitem häufiger. Das Datumsformat verwendet HTTP-date, wie in RFC 7231 definiert.

Hier ist, was die meisten Tutorials dir nicht sagen: viele APIs senden Retry-After gar nicht, oder sie senden es inkonsistent. OpenAIs API enthält es generell. GitHubs API enthält es zusammen mit X-RateLimit-Reset. Viele kleinere APIs senden nur 429 und lassen dich raten.

Einige APIs senden auch zusätzliche Rate-Limit-Header:

Header Zweck Beispiel
X-RateLimit-Limit Max erlaubte Anfragen pro Fenster 100
X-RateLimit-Remaining Verbleibende Anfragen im aktuellen Fenster 0
X-RateLimit-Reset Unix-Zeitstempel, wenn das Fenster zurückgesetzt wird 1735689600
Retry-After Sekunden zum Warten vor erneutem Versuch 30

Prüfe immer auf diese Header. Sie ermöglichen es dir, klügere Retry-Logik zu implementieren und sogar proaktiv langsamer zu werden, bevor du die Grenze erreichst.

HTTP 429 Too Many Requests: Ursachen, Lösungen und Rate Limiting - Architektur

429-Fehler als Client behandeln

Wenn du 429-Fehler erhältst, hier ist, wie du sie richtig behandelst.

Exponentieller Backoff mit Jitter

Das ist der Gold-Standard. Warte nicht einfach eine feste Zeit — erhöhe die Verzögerung exponentiell bei jedem Retry und addiere etwas Zufall hinzu (Jitter), um "Thundering Herd"-Probleme zu vermeiden.

async function fetchWithRetry(
  url: string,
  options: RequestInit = {},
  maxRetries: number = 5
): Promise<Response> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);

    if (response.status !== 429) {
      return response;
    }

    if (attempt === maxRetries) {
      throw new Error(`Still getting 429 after ${maxRetries} retries`);
    }

    // Check for Retry-After header first
    const retryAfter = response.headers.get('Retry-After');
    let delay: number;

    if (retryAfter) {
      // Could be seconds or a date
      const parsed = parseInt(retryAfter, 10);
      if (!isNaN(parsed)) {
        delay = parsed * 1000;
      } else {
        delay = new Date(retryAfter).getTime() - Date.now();
      }
    } else {
      // Exponential backoff with jitter
      const baseDelay = Math.pow(2, attempt) * 1000;
      const jitter = Math.random() * 1000;
      delay = baseDelay + jitter;
    }

    console.log(`Rate limited. Waiting ${Math.round(delay / 1000)}s before retry ${attempt + 1}`);
    await new Promise(resolve => setTimeout(resolve, delay));
  }

  // TypeScript wants this, though we'll never reach it
  throw new Error('Unexpected end of retry loop');
}

Request Queuing für Build-Prozesse

Für statische Website-Generierung, wo du hunderte oder tausende API-Aufrufe machen musst, verwende eine Queue mit Concurrency-Kontrolle:

import pLimit from 'p-limit';

// Limit to 5 concurrent requests
const limit = pLimit(5);

const pages = await getAllPageSlugs(); // Returns ['/', '/about', '/blog/post-1', ...]

const results = await Promise.all(
  pages.map(slug =>
    limit(() => fetchWithRetry(`https://api.cms.com/pages/${slug}`))
  )
);

Die p-limit Bibliothek (2,5M+ wöchentliche npm-Downloads im Jahr 2025) ist meine Go-to für das. Du kannst auch eine Verzögerung zwischen Anfragen hinzufügen:

const limit = pLimit(3);

const delay = (ms: number) => new Promise(r => setTimeout(r, ms));

const results = await Promise.all(
  pages.map((slug, i) =>
    limit(async () => {
      if (i > 0) await delay(200); // 200ms between requests
      return fetchWithRetry(`https://api.cms.com/pages/${slug}`);
    })
  )
);

Rate Limiting in Next.js API Routes implementieren

Jetzt drehen wir den Spieß um — du baust eine API und musst sie schützen. Wenn du mit Next.js baust, hier ist, wie du deinen API Routes Rate Limiting hinzufügst.

Einfacher In-Memory Rate Limiter

Für ein Single-Server-Deployment oder während der Entwicklung, das funktioniert:

// lib/rate-limit.ts
type RateLimitEntry = {
  count: number;
  resetTime: number;
};

const rateLimitMap = new Map<string, RateLimitEntry>();

export function rateLimit({
  windowMs = 60 * 1000,
  maxRequests = 100,
}: {
  windowMs?: number;
  maxRequests?: number;
} = {}) {
  return function check(identifier: string): {
    allowed: boolean;
    remaining: number;
    resetIn: number;
  } {
    const now = Date.now();
    const entry = rateLimitMap.get(identifier);

    if (!entry || now > entry.resetTime) {
      rateLimitMap.set(identifier, {
        count: 1,
        resetTime: now + windowMs,
      });
      return { allowed: true, remaining: maxRequests - 1, resetIn: windowMs };
    }

    if (entry.count >= maxRequests) {
      return {
        allowed: false,
        remaining: 0,
        resetIn: entry.resetTime - now,
      };
    }

    entry.count++;
    return {
      allowed: true,
      remaining: maxRequests - entry.count,
      resetIn: entry.resetTime - now,
    };
  };
}

Verwendung in einer Next.js App Router API Route:

// app/api/data/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { rateLimit } from '@/lib/rate-limit';

const limiter = rateLimit({ windowMs: 60_000, maxRequests: 30 });

export async function GET(request: NextRequest) {
  const ip = request.headers.get('x-forwarded-for') ?? 'anonymous';
  const { allowed, remaining, resetIn } = limiter(ip);

  if (!allowed) {
    return NextResponse.json(
      { error: 'Too many requests. Please slow down.' },
      {
        status: 429,
        headers: {
          'Retry-After': String(Math.ceil(resetIn / 1000)),
          'X-RateLimit-Limit': '30',
          'X-RateLimit-Remaining': '0',
        },
      }
    );
  }

  // Your actual route logic here
  return NextResponse.json(
    { data: 'Here you go' },
    {
      headers: {
        'X-RateLimit-Limit': '30',
        'X-RateLimit-Remaining': String(remaining),
      },
    }
  );
}

Production Rate Limiting mit Upstash Redis

Der In-Memory-Ansatz funktioniert nicht, wenn du auf Serverless-Plattformen wie Vercel läufst, denn jeder Funktionsaufruf könnte eine andere Instanz treffen. Du brauchst einen gemeinsamen Store. Upstash Redis ist die beliebteste Wahl dafür im Jahr 2025.

npm install @upstash/ratelimit @upstash/redis

// lib/rate-limit.ts
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

export const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(30, '60 s'),
  analytics: true,
  prefix: 'api-ratelimit',
});

// app/api/data/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { ratelimit } from '@/lib/rate-limit';

export async function GET(request: NextRequest) {
  const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
  const { success, limit, remaining, reset } = await ratelimit.limit(ip);

  if (!success) {
    const retryAfter = Math.ceil((reset - Date.now()) / 1000);
    return NextResponse.json(
      { error: 'Rate limit exceeded' },
      {
        status: 429,
        headers: {
          'Retry-After': String(retryAfter),
          'X-RateLimit-Limit': String(limit),
          'X-RateLimit-Remaining': '0',
          'X-RateLimit-Reset': String(reset),
        },
      }
    );
  }

  return NextResponse.json({ data: 'Success' }, {
    headers: {
      'X-RateLimit-Limit': String(limit),
      'X-RateLimit-Remaining': String(remaining),
    },
  });
}

Upstash kostenlos gibt dir 10.000 Anfragen/Tag, was für kleine Projekte ausreicht. Ihr Pro-Plan beginnt bei $10/Monat für 500K tägliche Befehle ab Anfang 2025.

Middleware-Level Rate Limiting

Wenn du Rate Limiting über all deine API Routes haben möchtest, ist Next.js Middleware der richtige Ort:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
import { ratelimit } from '@/lib/rate-limit';

export async function middleware(request: NextRequest) {
  if (request.nextUrl.pathname.startsWith('/api/')) {
    const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
    const { success, reset } = await ratelimit.limit(ip);

    if (!success) {
      return NextResponse.json(
        { error: 'Too many requests' },
        {
          status: 429,
          headers: {
            'Retry-After': String(Math.ceil((reset - Date.now()) / 1000)),
          },
        }
      );
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: '/api/:path*',
};

Rate-Limiting-Strategien verglichen

Nicht alle Rate-Limiting-Algorithmen sind gleich. Hier ist, wie die Hauptalgorithmen verglichen werden:

Algorithmus Wie es funktioniert Vorteile Nachteile Am besten für
Fixed Window Zählt Anfragen in festen Zeitfenstern (z.B. pro Minute) Einfach zu implementieren Burst an Fenstergrenzen kann das 2x Limit ermöglichen Einfache APIs, interne Tools
Sliding Window Zählt Anfragen über einen rollierenden Zeitraum Glattere Verteilung Leicht komplexer, mehr Speicher Die meisten Production APIs
Token Bucket Token füllen sich in gleichmäßiger Rate auf, jede Anfrage kostet einen Token Erlaubt kontrollierte Bursts Komplexeres State Management APIs, die Burst-Toleranz brauchen
Leaky Bucket Anfragen treten in eine Queue ein und werden in fester Rate verarbeitet Sehr glatte Ausgaberate Kann Latenz hinzufügen, Anfragen können gesenkt werden Webhook-Zustellung, Job-Verarbeitung
Sliding Window Log Speichert Zeitstempel jeder Anfrage Am genauesten Hoher Speicherverbrauch in skalierter Weise Low-Volume, High-Accuracy-Anforderungen

Für die meisten Web-Anwendungen ist Sliding Window das beste Gleichgewicht. Das ist, was Upstash standardmäßig verwendet, und das würde ich empfehlen, es sei denn, du hast einen bestimmten Grund, etwas anderes zu wählen.

Rate Limiting in Astro und anderen Frameworks

Wenn du mit Astro baust, funktioniert Rate Limiting anders, denn Astro ist hauptsächlich ein Static-First-Framework. Aber mit Astro Server Endpoints (verfügbar im SSR-Modus) sind die Konzepte gleich:

// src/pages/api/data.ts
import type { APIRoute } from 'astro';
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(30, '60 s'),
});

export const GET: APIRoute = async ({ request }) => {
  const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
  const { success, reset } = await ratelimit.limit(ip);

  if (!success) {
    return new Response(JSON.stringify({ error: 'Rate limit exceeded' }), {
      status: 429,
      headers: {
        'Content-Type': 'application/json',
        'Retry-After': String(Math.ceil((reset - Date.now()) / 1000)),
      },
    });
  }

  return new Response(JSON.stringify({ data: 'Hello' }), {
    status: 200,
    headers: { 'Content-Type': 'application/json' },
  });
};

Für Edge-deployed Anwendungen auf Cloudflare Workers solltest du auch Cloudflare's eingebaute Rate Limiting Rules in Betracht ziehen, die auf Infrastruktur-Level funktionieren und weit mehr Traffic als Application-Level-Lösungen verarbeiten können. Ihr Advanced Rate Limiting kostet $0,05 pro 10.000 gute Anfragen im Business-Plan.

Monitoring und Debugging von 429-Fehlern in Production

Du kannst nicht beheben, was du nicht sehen kannst. Hier ist meine Checkliste für den Umgang mit 429-Fehlern in Production:

Wenn du 429s erhältst

  1. Prüfe, welche API 429 zurückgibt — Schau auf die Response-URL, nicht nur auf den Status-Code
  2. Protokolliere den Retry-After Header — Wenn er konsistent sehr lang ist, brauchst du möglicherweise einen höheren Plan
  3. Überprüfe deine Anfrage-Muster — Machst du redundante Aufrufe? Kannst du Anfragen batchen?
  4. Implementiere Caching — Verwende stale-while-revalidate, Redis Caching oder Next.js ISR, um API-Aufrufe zu reduzieren
  5. Prüfe, ob mehrere Umgebungen API-Keys teilen — Das ist die häufigste "Geheimnis"-429-Ursache

Wenn du 429s sendest

  1. Richte Dashboards auf — Verfolge 429-Response-Raten über Zeit
  2. Identifiziere Top-Offenders — Welche IP-Adressen oder API-Keys treffen Limits am häufigsten?
  3. Überprüfe deine Limits — Sind sie zu restriktiv? Zu locker? Prüfe deine Server-Kapazität und passe dich an
  4. Sende immer Retry-After — Sei ein guter API-Bürger
  5. Füge eine hilfreiche Fehlermeldung ein — Sage dem Client, welches Limit sie treffen und wann sie es erneut versuchen sollen

Eine gut gestaltete 429-Response-Body sieht so aus:

{
  "error": {
    "type": "rate_limit_exceeded",
    "message": "You've exceeded 30 requests per minute. Please wait before retrying.",
    "retryAfter": 42,
    "documentation": "https://docs.yourapi.com/rate-limits"
  }
}

Das ist unendlich hilfreicher als nur { "error": "Too many requests" }.

Wenn du mit anhaltenden Rate-Limiting-Problemen bei einer Headless-Architektur umgehen musst — ob während Builds, zur Laufzeit oder beidem — könnte es sich lohnen, Kontakt aufzunehmen, um deine Architektur zu besprechen. Wir haben viele dieser Probleme bei verschiedenen CMS- und Framework-Kombinationen gesehen, und es gibt normalerweise eine Musterlösung auf Ebene statt nur Symptom-Bandagen.

FAQ

Was bedeutet HTTP 429 Too Many Requests?

HTTP 429 ist ein Status-Code, der bedeutet, dass du zu viele Anfragen an einen Server innerhalb eines bestimmten Zeitraums gesendet hast. Der Server begrenzt deine Rate — er bittet dich, langsamer zu werden. Es ist kein Authentifizierungsfehler oder Server-Fehler; deine Anfragen sind wahrscheinlich gültig, es gibt einfach zu viele davon. Der Server sollte einen Retry-After Header enthalten, der dir sagt, wann du es erneut versuchen solltest.

Wie behebe ich einen 429-Fehler?

Wenn du 429-Fehler von einer API erhältst, implementiere exponentiellen Backoff mit Jitter in deiner Retry-Logik, reduziere deine Anfragerate, addiere Caching, um redundante Aufrufe zu vermeiden, und respektiere den Retry-After Header. Wenn du die Grenze während Builds erreichst, verwende Request-Queuing mit Concurrency-Limits. Wenn es konsistent passiert, brauchst du möglicherweise ein Upgrade zu einem höheren API-Plan mit großzügigeren Rate Limits.

Was ist der Retry-After Header?

Der Retry-After Header wird mit einer 429 (oder 503) Response gesendet, um dem Client zu sagen, wie lange er warten soll, bevor er eine andere Anfrage stellt. Er kann als Anzahl von Sekunden angegeben werden (z.B. Retry-After: 60) oder als HTTP-Datum (z.B. Retry-After: Thu, 01 Jan 2026 00:00:00 GMT). Nicht alle APIs enthalten diesen Header, aber die gut gestalteten tun es.

Wie implementiere ich Rate Limiting in Next.js?

Für Entwicklung oder Single-Server-Deployments kannst du eine In-Memory-Map verwenden, um Request-Zähler pro IP-Adresse zu verfolgen. Für Production-Serverless-Deployments auf Plattformen wie Vercel, verwende Upstash Redis mit dem @upstash/ratelimit Paket. Du kannst Rate Limiting auf der einzelnen Route-Ebene oder über all deine API Routes mit Next.js Middleware anwenden.

Was ist der Unterschied zwischen 429 und 503 Fehlern?

429 Too Many Requests ist spezifisch für Rate Limiting — dein Client sendet zu viele Anfragen. 503 Service Unavailable bedeutet, dass der Server überbelastet oder unter Wartung ist und alle Anfragen von jedem nicht verarbeiten kann. Beide können einen Retry-After Header enthalten, aber sie zeigen sehr unterschiedliche Probleme an. 429 ist auf dich gerichtet; 503 betrifft alle.

Kann Rate Limiting DDoS-Angriffe verhindern?

Rate Limiting ist eine Schicht der Verteidigung gegen DDoS-Angriffe, aber allein nicht ausreichend. Application-Level-Rate-Limiting (wie das, das du in Next.js implementieren würdest) kann mäßigen Missbrauch verarbeiten, aber ein ernsthafter DDoS-Angriff muss auf Infrastruktur-Level mitigiert werden — mit Diensten wie Cloudflare, AWS Shield oder den eingebauten Schutzmaßnahmen deines Hosting-Anbieters. Denk an App-Level-Rate-Limiting als einen Bouncer und Infrastruktur-Level-Schutz als die Festungsmauern.

Was sollte ich als Rate Limit für meine API setzen?

Es hängt völlig von deinem Use Case ab. Ein häufiger Startpunkt für öffentliche APIs sind 60 Anfragen pro Minute pro IP oder 1.000 Anfragen pro Stunde pro API-Schlüssel. Für authentifizierte Benutzer darfst du möglicherweise mehr erlauben. Der Schlüssel ist, tatsächliche Usage-Muster zu überwachen, Limits zu setzen, die legitime Verwendung mit etwas Spielraum unterstützen, und auf Basis echter Daten anzupassen. Starte restriktiver und lockere es dann — es ist einfacher, als Limits zu verschärfen, nachdem Benutzer von höheren Raten abhängig sind.

Warum bekomme ich 429-Fehler während meines statischen Website-Builds?

Statische Website-Generatoren wie Next.js und Astro holen Daten für jede Seite beim Build-Zeit. Wenn du hunderte oder tausende Seiten hast, sind das hunderte oder tausende API-Aufrufe in schneller Folge. Die meisten CMS-APIs haben Rate Limits zwischen 5-20 Anfragen pro Sekunde. Verwende p-limit oder ähnliche Bibliotheken, um Concurrency auf 3-5 simultane Anfragen zu begrenzen, addiere kleine Verzögerungen zwischen Batches und erwäge inkrementelle Builds (ISR in Next.js oder Astro inkrementelle Content Collections), um nicht alles auf einmal zu bauen.