Claude und OpenAI wieder ausgefallen: So bauen Sie ausfallsichere LLM-Produkte bei großen API-Störungen

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Ich habe in den letzten sechs Monaten bei DennisCraft AI Studio vierzehn produktive KI-Agenten für DACH-B2B-Kunden (Logistik, Fintech, industrielle Automatisierung) ausgeliefert – Stack: Claude, Supabase, n8n, Doppler, selbstgehostetes Postgres. Letzte Woche waren OpenAI und Anthropic gleichzeitig für zwei Stunden nicht erreichbar. Das führte zu echten Ausfällen, SLA-Brüchen und kritischen Kundenanrufen. Ein Einzelfall? Nein – 2024 häufen sich massive API-Störungen, und die betroffenen Systeme sind meist geschäftskritisch.

Warum große LLM-Ausfälle zur neuen Realität gehören

Wenn Sie KI-Lösungen für regulierte DACH-Kunden entwickeln, sind API-Ausfälle keine Randnotiz, sondern ein Produktionsrisiko. In den letzten sechs Monaten habe ich vier größere Ausfälle (je 20 bis 90 Minuten) dokumentiert – OpenAI und Anthropic waren gleichzeitig betroffen (status.openai.com, status.anthropic.com). Die Ursachen reichen von Überlastung, Wartung, DDoS bis zu regionalen Cloud-Problemen.

Typische Ausfallmuster

• OpenAI API (gpt-4o/gpt-4-turbo): 5XX-Fehler oder Timeouts über 20+ Minuten
• Claude API (claude-3-opus, sonnet): Degradierte Performance oder „silent failures“
• Plötzliche Rate-Limits auch bei normaler Nutzung

Das Resultat: Automatisierte Reports werden nicht erzeugt, Rechnungen bleiben liegen, kritische Prozesse stoppen. Besonders gefährlich in Fintech und Logistik, wo SLA-Brüche direkt finanzielle Folgen haben – und oft vertraglich sanktioniert sind.

Architektur-Muster für ausfallsichere LLM-Produkte

1. Multi-Vendor-Fallback (Provider-Wechsel im Fehlerfall)

Das Standardmuster: Bei Ausfall des primären LLM-Providers sofort auf einen alternativen Anbieter umschalten. Praxistauglich wird es erst durch Details:

• Eingabe-/Ausgabeformate unterscheiden sich – Claude und OpenAI nutzen unterschiedliche Prompt-Konventionen, Tokenisierung und Limits.
• Feature-Parität ist nicht garantiert – z.B. Funktionalitäten wie Function Calling.
• Beide APIs können gleichzeitig ausfallen.

In meinen Systemen setze ich das Fallback mit n8n und eigenen Node.js-Skripten um:

const callClaude = async (input) => {
  // Anthropic SDK
};
const callOpenAI = async (input) => {
  // OpenAI SDK
};

let result;
try {
  result = await callClaude(payload);
} catch (e) {
  // Fehler loggen, OpenAI als Backup nutzen
  result = await callOpenAI(payload);
}
return result;

2. Queue und Retry mit Message-Broker

Statt synchronen API-Calls werden Aufgaben in eine Queue (Supabase, RabbitMQ, Postgres LISTEN/NOTIFY) gelegt. Vorteile:

• Aufgaben gehen bei kurzzeitigen Ausfällen nicht verloren
• Wiederholungsversuche mit Backoff (z.B. nach 1, 5, 15 Minuten)
• Zustand bleibt erhalten – Fehler lassen sich gezielt analysieren

import time
import supabase

def process_task(task):
    try:
        # LLM-API-Aufruf
        pass
    except Exception as e:
        # Mit Verzögerung erneut versuchen
        time.sleep(300)
        process_task(task)

3. Ergebnis-Caching

In meinen Projekten sind rund 40 % der LLM-Anfragen Wiederholungen. Ein Cache in Postgres (Hash des Inputs, Output, TTL=7 Tage) reduziert API-Last und minimiert Ausfälleffekte. Besonders bewährt für Standardberichte, E-Mail-Templates und wiederkehrende FAQ.

CREATE TABLE llm_cache (
  prompt_hash VARCHAR PRIMARY KEY,
  result TEXT,
  created_at TIMESTAMP DEFAULT NOW()
);

SELECT result FROM llm_cache WHERE prompt_hash = $1 AND created_at > NOW() - INTERVAL '7 days';

4. Graceful Degradation – Fallback auf Templates oder regelbasierte Logik

Nicht jede Funktion ist kritisch. Wenn LLMs ausfallen, schalten Sie temporär auf statische Texte (“Service derzeit nicht verfügbar, bitte später versuchen”) oder eingeschränkte regelbasierte Workflows. Das hält Kernprozesse am Leben und schützt vor Totalausfall.

Validierung und Monitoring – was sich im Produktivbetrieb bewährt

API-Statusüberwachung

Verlassen Sie sich nicht auf manuelle Checks. Ich binde die offiziellen Status-Endpunkte (OpenAI, Anthropic) direkt in n8n ein – Alerts gehen automatisiert an Slack/Telegram.

const fetch = require('node-fetch');
const url = "https://status.openai.com/api/v2/status.json";

async function checkStatus() {
  const res = await fetch(url);
  const data = await res.json();
  if (data.status.indicator !== 'none') {
    // Alert senden
  }
}

Fehler-Log-Analyse

Loggen Sie alle Fehler und Timeouts inkl. Endpoint, Payload, Zeitstempel. Für die Ursachenanalyse setze ich semgrep und bandit ein – mehrfach habe ich in Deployments denselben Serialisierungsfehler als Auslöser von 5XX bei Provider-Ausfällen identifiziert.

Realistische SLA und Kommunikation

Kommunizieren Sie offen: „LLM-Komponenten sind 0,5–2% der Monatszeit potenziell nicht verfügbar“. Versprechen Sie keine 100% Uptime – gerade in regulierten Sektoren (DSGVO, BSI Grundschutz, NIS2) ist ein zu optimistisches SLA schnell ein Haftungsrisiko.

FAQ

Was tun, wenn OpenAI und Claude gleichzeitig ausfallen?

Setzen Sie auf „Graceful Degradation“: statische Texte, regelbasierte Workflows, Nutzer-Info. Bei kritischen Flows Automatisierung temporär abschalten und an Operations-Teams eskalieren.

Sind selbstgehostete LLMs (Llama, Mistral) eine echte Ausfallschutz-Alternative?

Teilweise. Für eng umrissene Aufgaben ja, bei komplexen Code- oder Dokumentengenerierungen hinken Self-Hosted-Modelle noch hinterher (vgl. Stanford HELM 2024).

Wie lässt sich API-Status effizient überwachen?

Nutzen Sie die offiziellen Status-Endpunkte, binden Sie diese in n8n oder ein Alerting-System ein. Automatisierte Checks sind Pflicht – manuelle Überwachung ist unzuverlässig.

Welche Queue-Lösung eignet sich für Retry?

Im kleinen/mittleren Rahmen: Supabase oder Postgres. Bei hoher Last: RabbitMQ oder Redis Streams. Wichtig: Die Queue muss unabhängig von der LLM-API arbeiten.

Wie kommuniziert man Ausfallrisiken gegenüber Kunden?

Offen: Große Ausfälle sind kein Systemfehler, sondern Realität bei Cloud-LLMs. SLA realistisch auf 98–99% ansetzen – nicht höher.

In welchem Bereich Ihrer LLM-Pipeline treten im Produktivbetrieb die meisten Störungen auf – API, Queue, Cache oder Geschäftslogik? Ich freue mich auf Ihre Erfahrungen. Ich biete einen kostenlosen 30-min Stack-Audit für DACH-Unternehmen, die KI unter strengen Regulierungen bauen. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.