AI-Agent Production Checklist: Logging, Monitoring, Alerts, Rollback und Canary Releases

Es ist Freitagnachmittag. Sie wollen Ihren Customer-Support-Agent für 5% der Nutzer öffnen. Die Canary-Parameter sind vorbereitet: Traffic-Anteil, Beobachtungsfenster, Alert-Schwellen. Beim letzten Check fallen drei Probleme auf:

1. Es gibt kein feature flag; zum Abschalten müssten Sie neu deployen.
2. Niemand weiß, wie Aufgaben aus der menschlichen Freigabe-Queue zurück auf die alte Version geschoben werden.
3. Es ist unklar, ob bereits gesendete E-Mails als Tool-Nebeneffekt zählen und ob ein Rollback sie zurücknehmen soll.

Diese drei Probleme werden weder durch HTTP 500 noch durch Antwortzeiten sichtbar. Ein Agent-Launch braucht acht zusätzliche Dimensionen gegenüber einem Webservice: trace, tool calls, guardrails, HITL, eval, cost, secrets und checkpoint. Die folgende Checklist fasst sie in vier Gruppen: Pre-Release-Gates, Canary-Beobachtung, Monitoring nach dem Release und Incident-Rollback.

1. Pre-Release-Gates: zehn Checks, die bestehen müssen

1.1 Trace-Vollständigkeit prüfen

Vor dem Release muss klar sein, dass ein Trace einen vollständigen Agent run rekonstruieren kann. Sonst lässt sich ein Incident später kaum nachvollziehen. OpenAI Agents SDK hat eingebautes tracing und zeichnet LLM generations, tool calls, handoffs, guardrails und custom events auf. Ob diese Informationen in Produktion vollständig erhalten bleiben, müssen Sie jedoch einzeln prüfen.

Checklist:

• run ID, trace ID und span ID sind korrekt verknüpft, sodass ein Fehlerlog auf eine konkrete Anfrage zurückgeführt werden kann.
• model call, tool call und guardrail result werden vollständig aufgezeichnet, ohne fehlende Felder.
• Dauer, Token-Nutzung und Error-Code-Felder sind verfügbar, damit Kosten- und Performance-Baselines berechnet werden können.
• Trace-Retention und Maskierungsregeln sind klar, damit nützliche Daten nicht wegen Storage-Kosten oder Compliance-Risiken still verschwinden.
• Das Trace-Export-Verhalten ist in Entwicklungs- und Produktionsumgebung konsistent.

Wenn ein Trace nur den LLM call enthält, aber keine tool calls oder guardrail results, kann ein Canary trotz HTTP 200 gesund aussehen, obwohl Tool-Argumente falsch sind oder Berechtigungsgrenzen überschritten werden.

1.2 Richtlinie zur Maskierung sensibler Daten

Production-Traces können PII, Secrets und Kundendaten enthalten. Vor dem Launch müssen Sie entscheiden, was erfasst und wie es maskiert wird. OpenAI Agents SDK bietet die Einstellung trace_include_sensitive_data, mit der gesteuert wird, ob vollständige LLM- und Tool-Call-Eingaben sowie Ausgaben aufgezeichnet werden.

Checklist:

• Position und Default-Wert von trace_include_sensitive_data sind bekannt.
• PII-Erkennung und Maskierungsregeln decken typische Felder wie Namen, E-Mail-Adressen und Telefonnummern ab.
• Secret-Isolation ist umgesetzt, sodass API keys und Datenbankpasswörter nicht in Traces oder Logs erscheinen.
• Kundendaten sind in öffentlich, intern und vertraulich klassifiziert; jede Stufe hat eigene Maskierungsregeln.
• Maskierte Traces bleiben für Debugging nutzbar.

In Produktion empfiehlt sich automatische PII-Erkennung plus gestufte Maskierung. So erfüllen Sie Compliance-Anforderungen, ohne die Debugging-Fähigkeit zu verlieren.

1.3 Guardrails-Monitoring-Gate

guardrails validieren Nutzereingaben und Agent-Ausgaben und können mit einem schnelleren oder günstigeren Modell nicht konforme Anfragen blockieren. Der tool input guardrail des OpenAI Agents SDK läuft vor dem Aufruf eines Function Tools. Guardrails sind aber keine absolute Verteidigung. Vor dem Release müssen sie beobachtbar, alertfähig und rollbackfähig sein.

Checklist:

• Die Baseline der input guardrail Blockrate wurde gemessen.
• false-positive- und false-negative-Raten der output guardrail sind bekannt.
• tool input guardrail läuft vor dem Tool-Aufruf.
• Alert-Schwellen für guardrail trips sind konfiguriert.
• Für false positives gibt es einen schnellen Feedback-Pfad.

Das Gate für guardrails lautet: Blockrate hat eine Baseline, Fehlalarme haben Feedback, Alerts haben Schwellen.

1.4 Tool-Call-Observability

Tool-Call-Fehler gehören zu den häufigsten Agent-Fehlermodi. Die HTTP-Schnittstelle kann 200 zurückgeben, obwohl Tool-Argumente falsch sind, Berechtigungen überschritten werden oder ein externer Dienst timeoutet. Normales Service-Monitoring sieht diese Fehler meist nicht; sie stehen im Trace.

Checklist:

• Für jedes Tool wurde eine Baseline für Erfolgs- und Fehlerrate gemessen.
• Die Latenzverteilung der Tool Calls (P50/P95/P99) ist bekannt.
• Berechtigungsgrenzen sind klar, inklusive Allowlist oder Denylist dafür, welche Tools auf welche Ressourcen zugreifen dürfen.
• Fehlermodi sind vollständig klassifiziert; Timeout, Berechtigung, Argumentfehler und externer Serviceausfall haben unterschiedliche Behandlungen.
• Retry-Policy und Circuit-Breaker-Schwellen sind konfiguriert.

Tool-Observability heißt: Jedes Tool hat eine Erfolgsraten-Baseline, Fehler sind klassifiziert, Timeouts haben Circuit Breaker.

1.5 Vorbereitung des HITL-Queue-Monitorings

Staus in Human-in-the-Loop-(HITL)-Freigabe-Queues werden im Canary leicht übersehen. LangGraph checkpointers speichern den graph state bei jedem super-step und unterstützen HITL, time travel und fault tolerance. Queue-Länge und Freigabe-Timeouts brauchen trotzdem eigenes Monitoring.

Checklist:

• Alert-Schwellen für die HITL-Queue-Länge sind konfiguriert.
• Die automatische Behandlung von Freigabe-Timeouts ist klar; reject, Übergabe an Menschen und Degradation haben explizite Regeln.
• Der resume-Pfad nach einer Unterbrechung wurde verifiziert.
• Es ist definiert, was mit Aufgaben in der Queue beim Versionswechsel passiert.

Der HITL-Queue-Check lautet: Queue-Länge hat eine Schwelle, Timeout hat eine Strategie, Unterbrechung kann fortgesetzt werden.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

1.6 Eval Regression Suite

Vor dem Release muss eine eigene regression suite laufen, um Fähigkeitsrückschritte zu vermeiden. Die Suite sollte reale Aufgaben enthalten, nicht nur synthetic examples. Wenn die Erfolgsquote unter die Baseline fällt, ist die neue Version wahrscheinlich nicht bereit für Produktion.

Checklist:

• Die regression suite enthält genügend reale Aufgaben.
• Die Baseline für die Erfolgsquote ist klar (Empfehlung: ≥95%).
• Fehlgeschlagene Fälle sind sauber klassifiziert.
• Die Laufzeit der Suite ist kontrolliert (Empfehlung: ≤15 Minuten).
• Der Mechanismus, fehlgeschlagene Canary-Samples zurück in die Suite zu speisen, ist vorbereitet.

Die regression suite ist das letzte Gate. Liegt die Erfolgsquote unter 95%, sollte die Version vor dem Launch repariert werden.

1.7 Cost Budget und Rate Limit

Plattformweite Kosten- und Ratenlimits sind die letzte Sicherheitsgrenze. OpenAI empfiehlt usage tracking, billing limits, notification thresholds sowie projektweite spend/rate limits. Verlassen Sie sich nicht nur auf Budgetlogik im Business-Code.

Checklist:

• Projektweite spend limits sind konfiguriert.
• usage notification thresholds sind gesetzt (Empfehlung: 70%/90%).
• rate limits sind nach Nutzer oder Tenant gestaffelt.
• Alerts für Kostensprünge sind konfiguriert, etwa per Stundenvergleich.
• Die Degradationsstrategie ist klar: teure Tools abschalten, Modell wechseln oder Nutzer begrenzen, wenn das Budget überschritten wird.

Der Cost-Budget-Check lautet: Budget hat eine Obergrenze, Alerts haben Schwellen, Überschreitung hat einen Degradationspfad.

1.8 Secrets-Isolation und Audit

Secret-Leaks gehören zu den schwersten Agent-Sicherheitsvorfällen. Ein Agent kann über Tool Calls auf Datenbanken, Drittanbieter-APIs und interne Dienste zugreifen. Jeder Aufruf braucht Auditierbarkeit. Die Felder actor/subject/tool/resource müssen vollständig sein.

Checklist:

• actor/subject/tool/resource werden vollständig aufgezeichnet.
• Secret-Speicherung ist isoliert; API keys und Datenbankpasswörter erscheinen nicht in Umgebungsvariablen oder Konfigurationsdateien.
• Secret-Validierung läuft vor dem Tool-Aufruf.
• Die Aufbewahrungsdauer für Audit Logs ist klar (Empfehlung: 1 Jahr).
• Ein Plan für key rotation existiert.

Audit Logs sind eine wichtige Grundlage für Incident-Review.

1.9 Checkpoint-Recovery validieren

Ein lang laufender Agent muss nach einem Fehler in den korrekten Zustand zurückkehren können. LangGraph checkpointers speichern den graph state bei jedem super-step und unterstützen time travel debugging sowie fault-tolerant execution. Der Recovery-Pfad muss trotzdem separat getestet werden.

Checklist:

• Die Checkpoint-Speicherfrequenz ist klar; jeder super-step oder jeder wichtige Node wird gespeichert.
• Recovery nach Fehlern wurde getestet.
• Die Korrektheit des Zustands nach Recovery wurde verifiziert.
• Die Cleanup-Strategie für halb fertige Aufgaben ist klar.

Checkpoint-Recovery ist eine Grundfähigkeit für lang laufende Agents.

1.10 Feature Flag und Kill Switch

Sie müssen den Agent ohne erneutes Deployment abschalten können. OpenFeature bietet ein standardisiertes Feature-Flag-Modell und unterstützt Targeting nach Tenant, Nutzer oder Aufgabentyp sowie prozentuale Rollouts.

Checklist:

• feature flags sind nach Tenant, Nutzer oder Aufgabentyp scoped.
• Der kill switch wirkt innerhalb von 1 Minute.
• Prozentuale Verteilung wird unterstützt und kann für Canary Releases genutzt werden.
• Monitoring und Audit des Flag-Zustands sind konfiguriert.

Der Feature-Flag-Check lautet: gestufte Kontrolle, schnelle Wirkung, Zustandsaudit.

2. Canary-Beobachtung: worauf es in den ersten 10-30 Minuten ankommt

Bestandene Pre-Release-Gates bedeuten nicht, dass der Canary sauber läuft. Ein Agent-Canary braucht zwei Metrikschichten: Service-Metriken (HTTP-Fehlerrate, Antwortzeit) und Agent-Metriken (tool failure rate, guardrail trip rate, cost per run, HITL queue).

2.1 Traffic-Anteil und Beobachtungsfenster

Canaries dürfen nicht nach Bauchgefühl laufen. Kubernetes und AWS empfehlen, mit wenig Traffic zu starten, eine ausreichende Bewertungsphase zu setzen, Metriken zu überwachen und Traffic schrittweise zu erhöhen. Traffic- und Zeitparameter müssen explizit sein.

Checklist:

• Der initiale Traffic-Anteil ist klar (Empfehlung: 5-10%).
• Das minimale Beobachtungsfenster ist gesetzt (Empfehlung: 10-30 Minuten).
• Eine Mindestanzahl an Requests im Beobachtungsfenster ist konfiguriert.
• Die Bedingungen für schrittweise Traffic-Erhöhung sind definiert.

Traffic-Anteil und Beobachtungsfenster sind die Basisparameter des Canaries. Wenn 5% Traffic innerhalb von 10 Minuten Alerts auslösen, hat die neue Version ein ernstes Problem und sollte sofort zurückgerollt werden.

2.2 Monitoring von Service-Metriken

HTTP-Fehlerrate, Antwortzeit und Durchsatz sind die erste Metrikschicht im Canary; normale Services beobachten sie ebenfalls. Wenn Sie nur diese Schicht ansehen, verpassen Sie möglicherweise Agent-spezifische Fehlermodi.

Checklist:

• Die Schwelle für HTTP-5xx-Fehlerrate ist konfiguriert (Empfehlung: ≤1%).
• Die Schwelle für Antwortzeit P95 ist klar.
• Veränderung des Durchsatzes gegenüber der Baseline wird überwacht.
• CPU- und Speichernutzung werden überwacht.
• Netzwerkfehlerrate wird überwacht.

Service-Metriken sind die erste Verteidigungslinie, aber nicht das ganze Bild. Ein Agent kann HTTP 200 liefern, während Tool Calls fehlschlagen, Guardrails umgangen werden oder Kosten sprunghaft steigen.

2.3 Monitoring von Agent-Metriken

Agent-spezifische Metriken sind die zweite Canary-Schicht. Normales Service-Monitoring deckt sie meist nicht ab. Diese Signale stehen im Trace, nicht im HTTP log.

Checklist:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

• tool failure rate wird pro Tool überwacht.
• guardrail trip rate wird nach Typ überwacht.
• cost per run wird gegen die vorherige Baseline überwacht.
• HITL-Queue-Länge wird in Echtzeit überwacht.
• eval drift wird optional überwacht.

Agent-Metriken müssen nach Tool und Typ gruppiert werden, nicht als Durchschnittswert verschwinden.

2.4 Alert-Bedingungen und automatischer Rollback

Ein Canary muss automatisch zurückrollen können. Es reicht nicht, dass jemand ein Dashboard beobachtet. AWS-Dokumentation empfiehlt CloudWatch alarms als Auslöser für automatischen Rollback, mit klaren Triggerbedingungen und Rollback-Pfaden.

Checklist:

• Triggerbedingungen für automatischen Rollback sind definiert.
• Der Traffic-Switching-Pfad nach dem Rollback ist klar.
• Das Beobachtungsfenster nach dem Rollback ist gesetzt.
• Menschliche Bestätigung und Eskalationsfluss sind definiert.

Automatischer Rollback braucht klare Trigger, einen klaren Rollback-Pfad und bei Bedarf menschliche Bestätigung.

3. Monitoring nach dem Release: Production Readiness endet nicht beim Launch

Ein bestandener Canary ist nicht dasselbe wie Produktionsreife. Nach dem Release müssen Trace-Qualität, Kostennutzung, Guardrails-Wirkung und Eval Regression weiter überwacht werden, damit Fähigkeitsdrift oder Kostensprünge auffallen.

3.1 Trace-Qualität überwachen

Nach dem Release können Traces fehlen, sich verzögern oder Felder verlieren. Das erschwert Incident-Review und Debugging. Trace-Qualitätsmonitoring sollte getrennt vom Service-Monitoring laufen.

Checklist:

• Trace-Vollständigkeit wird überwacht; sinkt die run-ID-Korrelation unter die Baseline, wird alarmiert.
• Trace-Latenz wird überwacht; dauert es zu lange, bis ein Trace abfragbar ist, wird alarmiert.
• Trace-Sampling-Rate ist konfiguriert; bei hohem Traffic senkt Downsampling die Storage-Kosten.
• Trace-Speicherkosten werden überwacht.

Der Trace-Qualitätscheck lautet: Vollständigkeit hat eine Baseline, Latenz hat eine Schwelle, Kosten haben ein Budget.

3.2 Cost und Usage kontinuierlich überwachen

Kostensprünge gehören zu den häufigsten Agent-Produktionsvorfällen. Abnormale Token-Nutzung, Modellmissbrauch und sprunghaft steigende Tool-Call-Frequenz können Kosten explodieren lassen. OpenAI empfiehlt usage tracking und notification thresholds.

Checklist:

• Tägliche cost-Trends werden überwacht; Vergleiche zum Vortag und Vorwoche können Anomalien zeigen.
• Token-Nutzung wird nach Modell und Nutzer überwacht.
• Hochkosten-Tools sind identifiziert.
• Budget-Burn-Rate wird überwacht.
• Automatischer Circuit Breaker bei Budgetüberschreitung ist konfiguriert.

Cost-Monitoring heißt: Trends haben Vergleichswerte, Modelle sind klassifiziert, Budgets haben Circuit Breaker.

3.3 Guardrails kontinuierlich überwachen

Veränderungen der guardrail-Blockrate können Angriffe oder Fehlalarme bedeuten. Eine steigende input guardrail Blockrate kann mehr bösartige Prompts anzeigen. Eine steigende false-positive-Rate der output guardrail kann bedeuten, dass Regeln zu streng sind.

Checklist:

• Trend der input guardrail Blockrate wird überwacht.
• false-positive-Rate der output guardrail wird überwacht.
• Feedbacksammlung für guardrail false positives und false negatives ist vollständig.
• Guardrails-Regeln werden regelmäßig überprüft.

Guardrails-Monitoring heißt: Blockrate hat einen Trend, Fehlalarme haben Feedback, Regeln werden aktualisiert.

3.4 Eval kontinuierlich regressieren

Nach dem Release muss weiter geprüft werden, dass Fähigkeiten nicht schlechter werden. Führen Sie die regression suite täglich oder wöchentlich aus, alarmieren Sie bei Fehlfällen und nehmen Sie neue Fehlfälle in die Suite auf.

Checklist:

• Tägliche oder wöchentliche regression-suite-Läufe sind automatisiert.
• Fehlfälle lösen automatisch Alerts aus.
• Neue Fehlfälle werden in die Suite aufgenommen.
• Versionierung der regression suite ist gepflegt.

Eval Regression heißt: regelmäßige Läufe, Alerts bei Fehlern, Rückspeisung von Cases.

4. Incident-Rollback: schwierig sind die Tool-Nebeneffekte

Agent-Rollback ist komplexer als normaler Service-Rollback. Bei einem normalen Service genügt oft die Codeversion. Ein Agent-Rollback muss auch bereits ausgeführte Tool-Nebeneffekte, halb fertige Workflows und Aufgaben in menschlichen Freigabe-Queues behandeln.

4.1 Code-Rollback

Code-Rollback ist der einfachste Rollback-Weg. Kubernetes Deployment unterstützt rolling update und rollback, aber das Rollback-Fenster sollte innerhalb von 5 Minuten liegen.

Checklist:

• Der Rollback-Pfad für die Codeversion ist klar.
• Traffic-Switching nach dem Rollback wurde verifiziert.
• Validierung nach dem Rollback, etwa smoke test, wird ausgeführt.
• Das Rollback-Fenster ist gesetzt (Empfehlung: ≤5 Minuten).

Der Code-Rollback-Check lautet: klarer Pfad, verifiziertes Switching, begrenztes Fenster.

4.2 Rollback von Tool-Nebeneffekten

Der schwerste Teil des Agent-Rollbacks sind Tool-Nebeneffekte, die bereits passiert sind. E-Mails senden, Bestellungen erstellen, externe APIs aufrufen: Das wird nicht rückgängig, nur weil die Codeversion zurückgeht. Sie müssen idempotente und nicht idempotente Operationen unterscheiden und Kompensationsaktionen entwerfen.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Checklist:

• Ausgeführte Tool-Operationen sind identifiziert; alle ausgeführten Tool Calls sind im Trace auffindbar.
• Idempotente Operationen können sicher wiederholt werden.
• Nicht idempotente Operationen haben Kompensationsaktionen, etwa Korrekturmail senden, Bestellung stornieren oder Reversal API aufrufen.
• Die Cleanup-Strategie für halb fertige Aufgaben ist klar.
• Der menschliche Fallback-Prozess ist definiert.

Rollback von Tool-Nebeneffekten heißt: ausgeführte Operationen identifizieren, Idempotenz bewerten, Kompensationsaktionen entwerfen.

4.3 HITL-Queue bereinigen

Beim Rollback können halb fertige Aufgaben in der menschlichen Freigabe-Queue liegen bleiben. Die neue Agent-Version kann Aufgaben zu HITL hochgestuft haben, während die alte Version keine menschliche Freigabe braucht. Aufgaben in der Queue müssen neu zugewiesen oder zurückgeführt werden.

Checklist:

• Aufgaben in der Queue sind per Versionslabel identifizierbar.
• Die Strategie für erneute Zuweisung ist klar.
• Behandlung von Freigabe-Timeouts ist definiert.
• Menschlicher Bestätigungsfluss ist vollständig.

HITL-Queue-Bereinigung braucht versionsbasierte Identifikation, eine Reassignment-Strategie und Timeout-Behandlung.

4.4 Trace- und Audit-Log-Aufbewahrung

Incident-Review braucht vollständige Traces und Audit Logs. OpenTelemetry behandelt logs als eines der telemetry signals und kann sie mit bestehenden logging frameworks integrieren.

Checklist:

• Trace-Aufbewahrungsdauer ist klar (Empfehlung: 30-90 Tage).
• Audit-Log-Aufbewahrungsdauer ist klar (Empfehlung: 1 Jahr).
• Maskierungsregeln für sensible Daten sind vollständig.
• Compliance-Anforderungen der jeweiligen Branche werden erfüllt.

Trace- und Audit-Aufbewahrung heißt: passende Fristen, vollständige Maskierung, Compliance-Abdeckung.

4.5 Fehlersamples zurück in die Eval Suite speisen

Nach einem Incident gehören fehlgeschlagene Samples in die regression suite, damit derselbe Fehler nicht wiederkehrt. Die Sample-Extraktion muss fehlgeschlagene Cases im Trace finden; Menschen markieren Fehlerursache und erwartetes Verhalten.

Checklist:

• Es gibt ein Tool oder Skript zur Extraktion fehlgeschlagener Samples.
• Sample-Labeling hat menschliche Bestätigung.
• Es gibt einen Prozess, um Samples in die regression suite aufzunehmen.
• Es gibt einen Mechanismus, der die Wiederholung gleicher Incidents verhindert.

Rückspeisung fehlgeschlagener Samples heißt: Extraktion, menschliches Labeling, Suite-Update-Prozess und verifizierte Fixes.

Fazit

Ein Agent-Launch braucht acht zusätzliche Dimensionen gegenüber einem normalen Webservice: trace, tool calls, guardrails, HITL, eval, cost, secrets und checkpoint. Diese acht Dimensionen passen in vier Checklist-Gruppen:

Pre-Release-Gates (10 Checks): Trace-Vollständigkeit, Maskierung sensibler Daten, Guardrails-Monitoring, Tool-Call-Observability, HITL-Queue-Vorbereitung, Eval Regression Suite, Cost Budget und Rate Limit, Secrets-Isolation und Audit, Checkpoint-Recovery-Validierung sowie Feature Flag und Kill Switch. Prüfen Sie sie vor dem Release einzeln. Was nicht besteht, blockiert den Launch.

Canary-Beobachtung (4 Checks): Traffic-Anteil und Beobachtungsfenster, Monitoring von Service-Metriken, Monitoring von Agent-Metriken, Alert-Bedingungen und automatischer Rollback. Ein Canary schaut nicht nur auf HTTP-Fehlerrate, sondern auch auf tool failure rate, guardrail trip rate, cost per run und HITL queue length.

Monitoring nach dem Release (4 Checks): Trace-Qualitätsmonitoring, Cost- und Usage-Monitoring, kontinuierliches Guardrails-Monitoring und kontinuierliche Eval Regression. Ein sauberer Canary reicht nicht; laufendes Monitoring verhindert Fähigkeitsdrift und Kostensprünge.

Incident-Rollback (5 Checks): Code-Rollback, Rollback von Tool-Nebeneffekten, HITL-Queue-Bereinigung, Trace- und Audit-Log-Aufbewahrung sowie Rückspeisung fehlgeschlagener Samples in die Eval Suite. Rollback ist nicht nur Codeversion zurücksetzen. Es geht auch um ausgeführte Tool-Nebeneffekte, halb fertige Workflows und menschliche Freigabe-Queues.

Speichern Sie diese vier Checklist-Gruppen als Vorlage und gehen Sie sie vor jedem Release durch. Wenn ein Check scheitert, reparieren Sie ihn vor dem Livegang, statt ein bekanntes Problem in den Canary mitzunehmen.