Sazabi

npx add-mcp 'https://mcp.sazabi.com/mcp'

KI-native Observability und Sicherheit

Schnellstart: https://docs.sazabi.com/get-started/quickstart

Erste Schritte: npx @sazabi/cli start

Autonome Warnmeldungen, konversationsbasiertes Debugging und Integrationen für Coding-Agenten. Sazabi macht die Probleme sichtbar, die wirklich zählen, und gibt deinem Team den Kontext, um sie zu lösen.

Vertraut von

• Mastra
• Weave
• Sandstone
• Wajo
• Autumn
• Agree.com
• Inth
• Hoplite
• Taiga
• XMTP Labs

Sazabi ist eine KI-native Plattform für Observability und Sicherheit für Teams, die Software schnell ausliefern. Sie verbindet Produktionslogs mit dem Code, erkennt wichtige Probleme ohne handgebaute Monitore, untersucht Ursachen und sendet nützlichen Kontext an die Tools, in denen Ingenieure arbeiten. Stelle Fragen in natürlicher Sprache, verstehe, was sich geändert hat, und lass Coding-Agenten diesen Kontext nutzen, um Produktionsprobleme zu lösen.

Nutze Sazabi für autonome Warnmeldungen, konversationsbasiertes Debugging und Workflows mit Coding-Agenten. Sazabi ist für Engineering-Teams gebaut, die Produktionsprobleme finden und beheben müssen, ohne eine große Sammlung von Dashboards und statischen Monitoren zu pflegen. Erkunde das Produkt, die Integrationen, die Sicherheitspraktiken und die Entwicklerressourcen, um zu erfahren, wie Sazabi in deinen Stack passt.

Fähigkeiten

Zero-Touch-Erkennung

Erfasse die Probleme, die du nicht eingeplant hast

Monitore erfassen nur die Fehler, die du vorhergesehen hast. Sazabi überwacht jedes Log und markiert den Rest – von stillen Ausfällen und frustrierten Nutzern bis hin zu Agenten, die aus dem Ruder laufen –, und zwar ab der Minute, in der du dich verbindest.

• Automatische Erkennung: Finde Änderungen in deinen Logs, ohne Alarmregeln zu schreiben.
• Ursachenanalyse: Gruppiere zusammenhängende Fehler und verfolge sie bis in deinen Code zurück.
• Vorgeschlagene Fixes: Gib Ingenieuren und Coding-Agenten einen Plan zur Lösung jedes Problems.

Sicherheitsüberwachung

Erfahre im Moment der Exposition davon

Sazabi scannt deinen Code auf Sicherheitslücken und informiert dich, sobald eine neue CVE etwas trifft, das du betreibst. Wenn Botnets, Betrug oder Eindringlinge in deinen Logs auftauchen, erfährt dein Team es in Echtzeit.

• Code-Scanning: Finde Schwachstellen in deinen verbundenen Repositories.
• CVE-Tracking: Erfahre, wann eine neue Schwachstelle deine Abhängigkeiten betrifft.
• Bedrohungserkennung: Erkenne Botnets, Betrug und verdächtige Aktivitäten in deinen Logs.

Suche in natürlicher Sprache

Logs, gebaut für deine Agenten

Deine Coding-Agenten debuggen, indem sie Logs lesen, deshalb behält Sazabi alle und macht sie schnell durchsuchbar. Der Speicher ist günstig genug, dass du nie entscheiden musst, was du wegwirfst.

• Suche in natürlicher Sprache: Stelle eine Frage und erhalte eine Antwort mit passenden Log-Einträgen.
• Strukturierte Abfragen: Durchsuche Log-Felder und wiederkehrende Muster, um eine Untersuchung einzugrenzen.
• CLI & MCP: Lass Coding-Agenten Produktionslogs aus ihren eigenen Tools abfragen.

Immer aktive Dashboards

Stelle alles dar, was du bereits loggst

Wenn es in deinen Logs steht, kannst du es auf ein Live-Dashboard bringen: p99-Latenz, Speicher, langsame Abfragen, Anmeldungen. Du überspringst die Metrik-Pipeline komplett.

• KI-generierte Dashboards: Beschreibe, was du verfolgen möchtest, und verwandle deine Logs in Diagramme.
• Log-basierte Metriken: Stelle Log-Volumen, Speicher und CPU aus den Daten dar, die du bereits sendest.
• Live-Updates: Halte Diagramme aktuell, während neue Logs eintreffen.

So funktioniert Sazabi

1. GitHub und Slack verbinden: Installiere die GitHub- und Slack-Apps mit wenigen Klicks. Sazabi liest deine Codebasis für Kontext und tritt den Kanälen bei, in denen dein Team bereits arbeitet.
2. Logs senden: Leite Logs von den Plattformen weiter, die du bereits nutzt. Strukturiert oder unstrukturiert, Sazabi nimmt sie so, wie sie sind. Keine Schemas, Parsing-Regeln oder Dashboards zum Erstellen.
3. Warnmeldungen erhalten: Sazabi überwacht deine Logs auf Anomalien, untersucht jede einzelne gegen deinen Code und liefert das Problem an Slack, Microsoft Teams oder E-Mail – mit bereits identifizierter Ursache.

Oberflächliche Probleme aus Hunderten von Signalen

Angriffsversuche

Authentifizierungsanomalien

Fehlgeschlagene Login-Serien, Credential Stuffing, unmögliche Reisen, Session-Wiederverwendung.

Problemtyp: Aktiver Angriff (Credential Stuffing, Scanning, Ausnutzungsversuche.)

Credential Stuffing über 900 Konten

Status: Offen

Beschreibung

Ein koordinierter Login-Versuch testet Anmeldedaten über Hunderte von Konten, während er seine Quelladressen rotiert.

Was passiert ist

Authentifizierungslogs enthalten 2.000 fehlgeschlagene Logins gegen 900 Konten. Dieselbe Kontosequenz erscheint über verschiedene IPs hinweg, anders als die verstreuten Fehler im normalen Anmeldeverkehr. Die Fehler deuten auf einen automatisierten Übernahmeversuch hin; sie belegen nicht, dass auf ein Konto zugegriffen wurde.

So untersuchst du es

Gruppiere die Versuche nach Konto und Session-Fingerprint, prüfe erfolgreiche Logins in dieser Menge und rate-limitiere den missbräuchlichen Verkehr.

Angriffs-Payloads

SQL-Injection-, Path-Traversal-, SSRF- oder Template-Injection-Versuche in Anfragen.

Problemtyp: Aktiver Angriff (Credential Stuffing, Scanning, Ausnutzungsversuche.)

SQL-Injection-Sonden gegen ein Observability-Tool

Status: Offen

Beschreibung

Nicht authentifizierte SQL-Injection-Sonden erreichten die Datenbank über ein selbst gehostetes Observability-Tool und entgingen dem Error-Tracking des Teams.

Was passiert ist

Jemand ohne Session sandte SQL-Injection-Sonden an ein selbst gehostetes Observability-Tool, das sie direkt an seine Datenbank weiterleitete. Das Error-Tracking des Teams sah sie nie; sie sahen aus wie ein paar fehlgeschlagene Anfragen.

So untersuchst du es

Verfolge den betroffenen Anfragepfad und prüfe die Datenbank-Abfrage-Logs auf unbefugten Zugriff. Prüfe die Version des exponierten Tools und beschränke den Ingress während der Untersuchung.

Ausnutzungsversuche

Verkehr, der auf einen bekannten Exploit gegen deinen Stack passt.

Problemtyp: Aktiver Angriff (Credential Stuffing, Scanning, Ausnutzungsversuche.)

Sonden für einen verwundbaren Endpunkt

Status: Offen

Beschreibung

Anfragen zielen auf den in einem neuen Sicherheitshinweis genannten Endpunkt und stellen die Exposition der bereitgestellten Anwendung infrage.

Was passiert ist

Access-Logs zeigen wiederholte Sonden mit der Route und der Payload-Form, die im Hinweis beschrieben sind. Diese Anfragen umgehen die normale Navigation und gehen direkt an den betroffenen Endpunkt. Passender Verkehr belegt einen versuchten Exploit, aber weder eine verwundbare Bereitstellung noch eine erfolgreiche Ausführung ist bestätigt.

So untersuchst du es

Vergleiche die bereitgestellte Paketversion und die aktivierten Routen mit dem Hinweis, prüfe dann Antworten und nachgelagerte Auswirkungen, bevor du entscheidest, ob ein Patch oder eine Eindämmung nötig ist.

Bots und Scraping

Clients mit hoher Rate, Headless-Browser, rotierende IPs.

Problemtyp: Missbrauch und Betrug (Promo- oder Empfehlungsmissbrauch, gefälschte Anmeldungen, Spam, Scraping.)

Verzeichnis wird gescrapt

Status: Offen

Beschreibung

Automatisierte Clients durchlaufen das Firmenverzeichnis der Reihe nach, erzeugen anhaltende Leselast und sammeln Profildaten in großem Umfang.

Was passiert ist

Anfragen aus einem Netzwerk durchlaufen jede Verzeichnisseite mit regelmäßigen Abständen und ohne zwischenzeitliche Navigation. Rotierende Client-Adressen teilen dieselbe Seitenfolge und Anfrageform. Die Aktivität unterscheidet sich vom interaktiven Browsen und setzt das Verzeichnis einer systematischen Sammlung aus.

So untersuchst du es

Prüfe, welche Felder öffentlich lesbar sind, gruppiere die Clients nach Verhalten und wende verzeichnisspezifische Rate-Limits an, ohne normales Browsen zu blockieren.

Verdächtiger Zugriff

Zugriffsanomalien

Ein Akteur liest weit mehr Daten als normal oder durchläuft IDs der Reihe nach.

Problemtyp: Verdächtiger Zugriff (Kompromittierte Konten, Insider-Missbrauch, Datenexfiltration.)

Datensätze der Reihe nach gelesen

Status: Offen

Beschreibung

Ein authentifiziertes Konto zählt Tausende von Datensätzen auf, statt seinem üblichen Browsing-Muster zu folgen.

Was passiert ist

Das Konto fordert die Datensatz-IDs 1 bis 5.000 der Reihe nach an. Erfolgreiche Lesezugriffe setzen sich über Datensätze fort, die die Session nicht über Suche oder Navigation erreicht hat. Dies deutet auf Massensammlung hin und rechtfertigt eine Prüfung des Zugriffsbereichs, bevor angenommen wird, dass jeder zurückgegebene Datensatz autorisiert war.

So untersuchst du es

Prüfe die Session, ihre erwartete Arbeitslast und die Autorisierungsentscheidungen auf Datensatzebene. Widerrufe den Zugriff, falls er unbefugt war, und identifiziere, welche Datensätze zurückgegeben wurden.

Berechtigungsänderungen

Neue Admins, Rolleneskalationen, neue API-Schlüssel.

Problemtyp: Verdächtiger Zugriff (Kompromittierte Konten, Insider-Missbrauch, Datenexfiltration.)

Admin-Rolle um 3 Uhr morgens vergeben

Status: Offen

Beschreibung

Ein Konto erhielt Administratorrechte von einem unbekannten Ort außerhalb seiner normalen Aktivität, was einen neuen Pfad zu privilegierten Operationen schafft.

Was passiert ist

Der Audit-Trail verzeichnet eine Admin-Vergabe um 3 Uhr morgens von einem Ort, der in den früheren Sessions des Akteurs nicht vorkam. Der nachfolgende Zugriff nutzt die neue Rolle. Die Vergabe könnte legitime Wartung sein, aber ihr Akteur, ihr Zeitpunkt und ihr Umfang müssen überprüft werden, bevor das Privileg vertraut wird.

So untersuchst du es

Bestätige die Vergabe mit dem Kontoinhaber, prüfe die autorisierende Session und überprüfe nachfolgende privilegierte Aktionen. Widerrufe die Rolle, falls sie nicht genehmigt wurde.

Ungewöhnlicher Datenabfluss

Große Exporte oder Antworten an einen einzelnen Akteur.

Problemtyp: Verdächtiger Zugriff (Kompromittierte Konten, Insider-Missbrauch, Datenexfiltration.)

Export 50-mal größer als üblich

Status: Offen

Beschreibung

Ein Export bewegt deutlich mehr Daten, als dieses Konto normalerweise abruft, was die Möglichkeit eines versehentlichen oder unbefugten Massenzugriffs aufwirft.

Was passiert ist

Eine CSV-Antwort ist 50-mal größer als die üblichen Exporte des Kontos. Die Anfrage entfernt die in früheren Exporten verwendeten Filter und gibt eine viel breitere Datensatzmenge zurück. Die Größenänderung belegt ungewöhnlichen Abfluss; Autorisierung und beabsichtigter Umfang müssen noch geprüft werden.

So untersuchst du es

Vergleiche die Exportfilter, zurückgegebenen Felder und Kontoberechtigungen mit der angeforderten Aufgabe. Prüfe das Ziel und widerrufe die Session, falls der Export unbefugt war.

Bösartige Agenten

KI-Agenten, deine oder die eines Drittanbieters, handeln außerhalb ihres normalen Bereichs.

Problemtyp: Fehlverhalten von Agenten (KI-Agenten, die außerhalb ihres Bereichs handeln, Prompt-Injection, außer Kontrolle geratene Schleifen.)

Support-Agent ruft einen Admin-Endpunkt auf

Status: Offen

Beschreibung

Ein Support-Agent ruft eine administrative Operation außerhalb der Tools und des Bereichs auf, die für seine normalen Support-Aufgaben verwendet werden.

Was passiert ist

Tool-Call-Logs zeigen, dass der Agent einen Admin-Endpunkt erreicht, den er noch nie zuvor verwendet hat. Der Aufruf folgt kundenseitig bereitgestelltem Inhalt statt einer Operator-Anweisung. Diese Sequenz wirft eine mögliche Bereichsverletzung auf; die Antwort und das Audit-Log müssen belegen, ob die Operation tatsächlich etwas verändert hat.

So untersuchst du es

Prüfe den auslösenden Inhalt, die Tool-Argumente und das Autorisierungsergebnis. Beschränke die Tools des Agenten auf seinen Support-Bereich und verlange eine Genehmigung für administrative Aktionen.

Schwachstellen

Secrets oder personenbezogene Daten in Logs

Tokens, Schlüssel, E-Mails oder ID-Nummern, die in Logs geschrieben werden.

Problemtyp: Exposition (Eine CVE, die dich betrifft, ein verwundbarer Codepfad, eine Fehlkonfiguration, geleakte Secrets.)

API-Schlüssel in einem Fehler ausgegeben

Status: Offen

Beschreibung

Ein Error-Handler kopiert eine Anmeldedaten in die Diagnoseausgabe und setzt sie so Systemen und Personen mit Log-Zugriff aus.

Was passiert ist

Eine fehlgeschlagene ausgehende Anfrage enthält ihren API-Schlüssel in der protokollierten Fehlermeldung. Der Wert wird mit der Exception weitergegeben, statt an der Logging-Grenze redigiert zu werden. Jeder, der diesen Datensatz lesen kann, kann den Schlüssel möglicherweise wiederverwenden, bis er widerrufen wird.

So untersuchst du es

Widerrufe den exponierten Schlüssel, identifiziere, wohin der Datensatz geliefert und wo er aufbewahrt wurde, und redigiere Anmeldedaten, bevor Anfragefehler serialisiert werden.

Neuer Hinweis betrifft dich

Eine neu veröffentlichte CVE passt zu deinen Abhängigkeiten oder deiner Laufzeit (über cve.now).

Problemtyp: Exposition (Eine CVE, die dich betrifft, ein verwundbarer Codepfad, eine Fehlkonfiguration, geleakte Secrets.)

Neuer Hinweis passt zu deiner Lockfile

Status: Offen

Beschreibung

Ein neu veröffentlichter Framework-Hinweis enthält die in der Lockfile der Anwendung festgelegte Version, was eine Expositionsprüfung gegen den bereitgestellten Build erfordert. Was passiert ist

Der Versionsbereich der Sicherheitsmeldung stimmt mit der aufgelösten Framework-Abhängigkeit überein. Der Treffer in der Lockdatei weist auf ein potenziell anfälliges Artefakt hin, zeigt aber nicht, ob das betroffene Feature aktiviert oder erreichbar ist. Der bereitgestellte Build und seine Routenkonfiguration bestimmen die tatsächliche Gefährdung.

So untersuchen Sie den Vorfall

Prüfen Sie die bereitgestellte Version und das betroffene Feature, sehen Sie sich die Abhilfemaßnahmen der Sicherheitsmeldung an, aktualisieren Sie anschließend auf eine korrigierte Version und testen Sie die betreffende Route.

Riskanter Code

Die Codeanalyse kennzeichnet fehlende Authentifizierungsprüfungen, Authentifizierungsumgehungen oder Injektionsrisiken in neuen Commits.

Problemtyp: Gefährdung (Eine CVE, die Sie betrifft, ein anfälliger Codepfad, eine Fehlkonfiguration, offengelegte Geheimnisse.)

Hostdateien in Bereitstellungsfehlern offengelegt

Status: Offen

Beschreibung

Bei fehlgeschlagenen Bereitstellungen wurden Dateien vom Builder-Host über Fehlermeldungen, die wie gewöhnliche Parse-Fehler wirkten, für Benutzer offengelegt.

Was passiert ist

Ein Bereitstellungs-Builder las Dateien von seinem eigenen Host und gab sie in Fehlermeldungen zur Bereitstellung an Benutzer zurück, darunter Inhalte im Stil von /etc/passwd. Oberflächlich betrachtet handelte es sich um fehlgeschlagene Bereitstellungen mit einem Parse-Fehler.

So untersuchen Sie den Vorfall

Verfolgen Sie, wie Build-Eingaben auf Hostdateien und Fehlerausgaben zugreifen können. Prüfen Sie die Grenzen der Dateiextraktion und entfernen Sie Hostdateiinhalte aus benutzerseitig sichtbaren Fehlermeldungen.

Lieferkette

Eine Abhängigkeit wechselt den Besitzer, wird durch Typosquatting nachgeahmt oder als bösartig eingestuft.

Problemtyp: Gefährdung (Eine CVE, die Sie betrifft, ein anfälliger Codepfad, eine Fehlkonfiguration, offengelegte Geheimnisse.)

Kompromittierte Paketversion

Status: Offen

Beschreibung

Eine Abhängigkeitsversion wurde als kompromittiert eingestuft, und die Lockdatei weist darauf hin, dass sie in Anwendungs-Builds enthalten sein könnte.

Was passiert ist

Die markierte Paketversion stimmt mit der aufgelösten Abhängigkeit überein und nicht nur mit einem großzügigen Versionsbereich. Build-Datensätze müssen belegen, wo diese Version installiert wurde und ob ihr Code oder ihre Installationsskripte ausgeführt wurden. Der Treffer begründet ein Gefährdungsrisiko, beweist aber nicht, dass Zugangsdaten oder Daten entwendet wurden.

So untersuchen Sie den Vorfall

Ermitteln Sie betroffene Builds, vergleichen Sie das Paket mit der vertrauenswürdigen Version, ersetzen Sie es und rotieren Sie Zugangsdaten nur dort, wo ihre Ausführung sie offengelegt haben könnte.

Protokollmuster

Verschwundenes Ereignis

Etwas, das normalerweise passiert, ist ausgeblieben, obwohl der Datenverkehr normal ist.

Problemtyp: Stiller Fehler (Ein Feature scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Anwendungen werden nicht mehr übermittelt

Status: Offen

Beschreibung

Ereignisse zur Übermittlung von Bewerbungen sind ausgeblieben, während Benutzer weiterhin das Formular aufrufen. Das deutet darauf hin, dass Arbeit ohne explizite Fehlermeldung verloren geht.

Was passiert ist

Das Ereignis „Application submitted“ verschwindet nach 14:14 Uhr, während Formularaufrufe und Übermittlungsversuche weiterlaufen. Das übliche Abschlussereignis folgt diesen Versuchen nicht mehr. Der Datenverkehr wirkt insgesamt gesund, doch der fehlende Übergang bedeutet, dass Bewerbungen möglicherweise nicht ihren gespeicherten Zustand erreichen.

So untersuchen Sie den Vorfall

Verfolgen Sie einen Übermittlungsversuch durch Validierung, Speicherung und Ereignisausgabe. Vergleichen Sie gespeicherte Bewerbungen mit den Versuchen, um eine Protokollierungslücke von verlorenen Übermittlungen zu unterscheiden.

Volumenverschiebung

Die Rate eines Ereignisses steigt oder fällt weit außerhalb des üblichen Musters.

Problemtyp: Missbrauch und Betrug (Missbrauch von Werbeaktionen oder Empfehlungen, gefälschte Registrierungen, Spam, Scraping.)

Anstieg bei Passwortzurücksetzungen

Status: Offen

Beschreibung

Passwortzurücksetzungsanfragen liegen deutlich über dem üblichen Wochenmuster. Dadurch steigt die E-Mail-Last, und Kontoinhaber könnten mit unerwünschten Nachrichten überflutet werden.

Was passiert ist

Ereignisse für Zurücksetzungs-E-Mails treten sechsmal so häufig auf wie an einem normalen Dienstag, während der gewöhnliche Anmeldeverkehr nahe am Ausgangswert bleibt. Wiederholt angefragte Zielkonten und ähnliche Anfragefolgen machen einen großen Teil des Anstiegs aus. Das deutet eher auf Missbrauch oder eine versehentliche Wiederholungsschleife als auf ein allgemeines Nutzerwachstum hin.

So untersuchen Sie den Vorfall

Gruppieren Sie Anfragen nach Zielkonto und Initiator, prüfen Sie auf eine Wiederholungsschleife im Client und setzen Sie für missbräuchlichen Datenverkehr kontobezogene Limits für Zurücksetzungen durch.

Unterbrochene Abfolge

Auf A folgt normalerweise B; jetzt tritt A ohne B auf.

Problemtyp: Stiller Fehler (Ein Feature scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Uploads werden nie abgeschlossen

Status: Offen

Beschreibung

Upload-Anfragen beginnen normal, erreichen aber nicht den Abschlussschritt. Dadurch bleiben Dateien nicht verfügbar, obwohl Benutzer die Übertragung gestartet haben.

Was passiert ist

„Upload started“-Einträge treffen weiterhin ein, aber zu ihren Anforderungs-IDs gibt es kein passendes „upload complete“-Ereignis. Die fehlenden Abschlüsse häufen sich nach der Übergabe an den Speicher. Benutzer warten auf eine Datei, die nicht finalisiert wurde, ohne dass ein entsprechender Anwendungsfehler angezeigt wird.

So untersuchen Sie den Vorfall

Verfolgen Sie die betroffenen Upload-IDs durch Speicherung und Finalisierung. Prüfen Sie auf abgebrochene Multipart-Uploads, fehlgeschlagene Callbacks und fehlende Zeitüberschreitungs- oder Fehlerbehandlung.

Geänderte Reihenfolge oder Zeitabstände

Schritte treten in falscher Reihenfolge oder mit längeren Abständen auf.

Problemtyp: Datenintegrität (Verlorene Schreibvorgänge, Duplikate, Beschädigungen, nicht übereinstimmende Datensätze.)

Webhooks werden vor ihren Datensätzen verarbeitet

Status: Offen

Beschreibung

Die Verarbeitung von Webhooks konkurriert mit der Erstellung des Datensatzes, den sie aktualisiert. Dadurch kann ein ansonsten gültiges Ereignis verworfen werden, weil die Daten fehlen.

Was passiert ist

Webhook-Handler suchen nach einem Datensatz, bevor die zugehörige Erstellungstransaktion abgeschlossen ist. Die Suche liefert nichts zurück, aber eine spätere Abfrage findet den Datensatz ohne angewendete Webhook-Aktualisierung. Aufgrund der Ereignisreihenfolge bleibt der lokale Zustand hinter dem des Anbieters zurück, obwohl beide Anfragen abgeschlossen werden.

So untersuchen Sie den Vorfall

Stellen Sie einen zeitlichen Zusammenhang zwischen dem Empfang des Webhooks und den Transaktions-Commits her, behalten Sie nicht zugeordnete Ereignisse für Wiederholungsversuche bei und sorgen Sie dafür, dass eine erneute Verarbeitung sicher ist, sobald der Zieldatensatz existiert.

Feldabweichung

Werte in Ereignissen verändern sich: neue Kategorien, Nullwerte, leere Zeichenfolgen, ungewöhnliche Größen.

Problemtyp: Datenintegrität (Verlorene Schreibvorgänge, Duplikate, Beschädigungen, nicht übereinstimmende Datensätze.)

Schreibvorgänge ohne zugehöriges Unternehmen

Status: Offen

Beschreibung

Bei einem Teil der Schreibvorgänge geht die Zuordnung zum Unternehmen verloren. Dadurch entstehen Datensätze, die sich im erwarteten Geltungsbereich nicht zuverlässig zuordnen oder abrufen lassen.

Was passiert ist

Das Feld company_id ist bei 3 % der Schreibvorgänge null, obwohl es zuvor einen Wert enthielt. Diese Datensätze stammen alle aus einem Eingabepfad, der den Unternehmenskontext vor der Speicherung auslässt. Die Schreibvorgänge sind erfolgreich, aber nachgelagerte unternehmensbezogene Abfragen können sie nicht mehr in der erwarteten Sammlung finden.

So untersuchen Sie den Vorfall

Verfolgen Sie, wie der Unternehmenskontext diesen Schreibpfad erreicht, weisen Sie fehlende erforderliche Eigentumsfelder zurück und ermitteln Sie betroffene Datensätze, bevor Sie eine gezielte Reparatur versuchen.

Sprung bei der Kardinalität

Ein Feld weist plötzlich deutlich mehr unterschiedliche Werte auf.

Problemtyp: Kapazitätsrisiko (Ein Limit rückt näher, bevor es zum Problem wird.)

Zunehmende Cache-Schlüssel

Status: Offen

Beschreibung

Der Cache erstellt für ansonsten ähnliche Anfragen neue Schlüssel. Dadurch sinkt die Wiederverwendung und der Speicherbedarf steigt.

Was passiert ist

Für dieselbe kleine Gruppe von Routen erscheinen jede Minute Tausende unterschiedlicher Cache-Schlüssel. Die Schlüssel unterscheiden sich durch ein anfragespezifisches Suffix, sodass wiederholte Anfragen Einträge verfehlen, die wiederverwendbar sein sollten. Die wachsende Schlüsselmenge erhöht den Speicherverbrauch und verlagert zugleich mehr Arbeit auf den zugrunde liegenden Dienst.

So untersuchen Sie den Vorfall

Vergleichen Sie die alte und neue Schlüsselerstellung, entfernen Sie unbeabsichtigte anfragespezifische Felder und prüfen Sie die Ablaufzeiten, bevor Sie nicht mehr erreichbare Einträge bereinigen.

Verharmlosende Fehlerprotokollierung

Ereignisse beschreiben einen Fehler, werden aber mit dem Schweregrad „info“ oder „debug“ protokolliert.

Problemtyp: Stiller Fehler (Ein Feature scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Preisaktualisierung übersprang das größte Konto

Status: Offen

Beschreibung

Ein Preisaktualisierungsjob behandelte ein übersprungenes Konto als erfolgreich abgeschlossen. Dadurch zahlen die Benutzer des größten Kontos weiterhin die bisherigen Credit-Kosten.

Was passiert ist

Ein Job zur Anwendung von Preisänderungen übersprang das größte Konto aufgrund eines fest codierten Limits und meldete anschließend „completed“. Das Überspringen wurde mit dem Schweregrad „info“ protokolliert, sodass die Benutzer dieses Kunden weiterhin die alten Credit-Kosten zahlten.

So untersuchen Sie den Vorfall

Prüfen Sie das Limit und die Behandlung übersprungener Konten, führen Sie die Aktualisierung für das ausgeschlossene Konto erneut aus und überprüfen Sie die angewendeten Preise, bevor Sie den Abschluss protokollieren.

Wiederholungssturm

Derselbe Vorgang wird in kurzen Schleifen wiederholt.

Problemtyp: Fehler bei Hintergrundjobs (Versäumte, doppelte, festgefahrene oder leere geplante Arbeit.)

Job wird in einer engen Schleife wiederholt

Status: Offen

Beschreibung

Ein Hintergrund-Worker wiederholt dieselben fehlerhaften Datensätze, ohne Fortschritte zu erzielen. Dadurch wird Kapazität verbraucht, die andere Jobs benötigen.

Was passiert ist

Ein Job versucht, jeden betroffenen Datensatz 30-mal in einer engen Schleife zu verarbeiten. Fehler und Eingabe bleiben zwischen den Versuchen unverändert, und es gibt keine zunehmende Verzögerung. Die wiederholten Fehler belegen den Worker, statt unabhängige Datensätze weiterzuverarbeiten oder die blockierte Arbeit sichtbar zu machen.

So untersuchen Sie den Vorfall

Ordnen Sie den wiederholten Fehler als vorübergehend oder dauerhaft ein, implementieren Sie begrenztes Backoff und verschieben Sie Datensätze nach ausgeschöpften Versuchen in einen überprüfbaren Fehlerzustand.

Korrelationsbruch

Zwei Dienste, die normalerweise im Gleichschritt arbeiten, entwickeln sich auseinander.

Problemtyp: Fehler bei Hintergrundjobs (Versäumte, doppelte, festgefahrene oder leere geplante Arbeit.)

Worker kommen nicht mehr hinterher

Status: Offen

Beschreibung

Der API-Datenverkehr steigt, ohne dass die Zahl der abgeschlossenen Worker-Aufträge entsprechend zunimmt. Das deutet darauf hin, dass angenommene Arbeit die Warteschlange nicht mehr erreicht oder nicht mehr verlässt.

Was passiert ist

Die API nimmt weiterhin Anfragen an, während die Zahl abgeschlossener Worker-Jobs unverändert bleibt. Zuvor entwickelten sich beide Zahlen parallel. Die Abweichung bedeutet, dass erfolgreiche API-Antworten nicht mehr belegen, dass die angeforderte Hintergrundarbeit abgeschlossen wurde. Ein Fehler in der Warteschlange oder Weiterleitung könnte dazwischen verborgen sein.

So untersuchen Sie den Vorfall

Vergleichen Sie die Zahlen für angenommene, eingereihte, gestartete und abgeschlossene Jobs nach Job-ID, um die Unterbrechung zu lokalisieren, bevor Sie Arbeit erneut abspielen oder skalieren.

Neues Ereignis

Eine Ereignisart, die noch nie zuvor aufgetreten ist.

Problemtyp: Regression (Verhalten, das durch eine bestimmte Bereitstellung oder Konfigurationsänderung beeinträchtigt wurde.)

Entwürfe werden nach der Bereitstellung übersprungen

Status: Offen

Beschreibung

Ein neuer Speicherpfad überspringt nach einer Veröffentlichung gesperrte Entwürfe. Dadurch werden Änderungen der Benutzer nicht angewendet, ohne dass eine Ausnahme ausgelöst wird.

Was passiert ist

Die Meldung „skipping save, draft locked“ erscheint erstmals nach der Bereitstellung. Betroffene Anfragen werden ohne das übliche Ereignis für den gespeicherten Entwurf zurückgegeben, während spätere Lesevorgänge weiterhin die vorherige Revision anzeigen. Der neue Zweig verhindert das Speichern, statt lediglich Diagnoseprotokolle hinzuzufügen.

So untersuchen Sie den Vorfall

Prüfen Sie die mit der Veröffentlichung eingeführte Sperrprüfung, untersuchen Sie die Bereinigung veralteter Sperren und stellen Sie sicher, dass ein abgelehnter Speichervorgang dem Benutzer klar mitgeteilt wird.

Nutzerverhalten

Aktion ohne Wirkung

Ein Klick ohne Serveranfrage oder eine Anfrage ohne gespeichertes Ergebnis.

Problemtyp: Stiller Fehler (Ein Feature scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Bildschirm verbunden, kein Token

Status: Offen

Beschreibung

Der Kontoverknüpfungsablauf zeigte Erfolg an, obwohl das OAuth-Token nie gespeichert wurde. Dadurch konnte sich die Verbindung nicht authentifizieren.

Was passiert ist

Ein Benutzer, der ein Konto verknüpfte, sah die Meldung „connected“, aber das OAuth-Token wurde nie gespeichert. Ein doppelter Callback leitete ihn zur Erfolgsseite weiter, während die ursprüngliche Anfrage im Hintergrund fehlschlug.

So untersuchen Sie den Vorfall

Prüfen Sie gemeinsam die Ergebnisse des ursprünglichen und des doppelten Callbacks. Melden Sie die Verbindung erst dann als erfolgreich, wenn das Token gespeichert wurde, und verknüpfen Sie betroffene Konten erneut.

Wütende und wiederholte Klicks

Dieselbe Schaltfläche wird immer wieder angeklickt.

Problemtyp: Stiller Fehler (Ein Feature scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Benutzer hämmern auf „Save“

Status: Offen

Beschreibung Nutzer klicken wiederholt auf „Speichern“, weil das Formular nicht bestätigt, ob ihre Änderungen übernommen wurden. Das verleitet sie zu erneuten Versuchen, die möglicherweise doppelte Arbeit verursachen.

Was passiert ist

Innerhalb einer Sitzung wird dieselbe Schaltfläche innerhalb von zehn Sekunden fünfmal angeklickt. Die erste Anfrage bleibt ausstehend, während weitere Klicks zusätzliche Anfragen auslösen. Das Formular zeigt weder einen Erfolgs- noch einen Fehlerstatus an. Das Interaktionsmuster deutet auf einen hängenden Speichervorgang oder fehlende Rückmeldung hin.

So untersuchen Sie das Problem

Verfolgen Sie die erste Speicheranfrage, zeigen Sie ihren Status während der Verarbeitung und bei Fehlern an und verhindern Sie doppelte Übermittlungen. Prüfen Sie dabei, ob erneute Versuche sicher sind.

Abbruch im Funnel

Die Conversion zwischen den einzelnen Schritten sinkt.

Problemtyp: Unterbrechung eines Geschäftsablaufs (Ein Rückgang einer wichtigen Kennzahl mit technischer Ursache.)

Abschluss der Registrierung auf 50 % gesunken

Status: Offen

Beschreibung

Mehr Personen beginnen die Registrierung, als sie abschließen. Der Verlust konzentriert sich auf den Zeitraum zwischen dem Absenden des Formulars und der Erstellung des Kontos.

Was passiert ist

Der Abschluss der Registrierung sinkt von 80 % auf 50 %, während die Anzahl der gestarteten Sitzungen vergleichbar bleibt. Sitzungen erreichen den Schritt zum Absenden, aber es wird kein Ereignis zur Kontoerstellung erfasst. Der Rückgang ist auf einen unvollständigen Onboarding-Prozess zurückzuführen und nicht einfach darauf, dass weniger Besucher die Website erreichen.

So untersuchen Sie das Problem

Vergleichen Sie fehlgeschlagene und erfolgreiche Registrierungsabläufe ab dem ersten fehlenden Schritt. Segmentieren Sie anschließend nach Validierungsergebnis, Client-Version und Identitätsanbieter.

Navigationsschleifen

Nutzer wechseln zwischen denselben Seiten hin und her.

Problemtyp: Stilles Versagen (Eine Funktion scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Nutzer zwischen Einstellungen und Abrechnung festgefahren

Status: Offen

Beschreibung

Nutzer werden zwischen den Einstellungen und der Abrechnung hin- und hergeleitet, ohne den Bildschirm zu erreichen, den sie zum Abschließen ihrer Aufgabe benötigen.

Was passiert ist

Sitzungen folgen wiederholt dem Ablauf Einstellungen → Abrechnung → Einstellungen, ohne dass dazwischen ein Abschlussereignis auftritt. Jede Zielseite leitet Nutzer anhand einer anderen Prüfung des Kontostatus zurück. Die Schleife verhindert den Zugriff auf die Abrechnungsfunktionen, obwohl beide Routen erfolgreiche Antworten zurückgeben.

So untersuchen Sie das Problem

Vergleichen Sie die Zugriffsbedingungen und den Kontostatus, die von beiden Routen verwendet werden. Beheben Sie die widersprüchlichen Weiterleitungen und überprüfen Sie den Ablauf anhand einer betroffenen Sitzung.

Sackgassen

Sitzungen enden auf Fehlerzuständen, leeren Bildschirmen oder endlosen Ladeanzeigen.

Problemtyp: Frontend-Fehler (Funktioniert in einem bestimmten Browser, auf einem bestimmten Gerät oder mit einer bestimmten App-Version nicht.)

Ladeanzeige des Dashboards verschwindet nie

Status: Offen

Beschreibung

Das Dashboard bleibt im Ladezustand, bis Nutzer die Seite verlassen. Dadurch wird eine hängende Anfrage verborgen, statt nutzbare Inhalte oder eine Fehlermeldung anzuzeigen.

Was passiert ist

Sitzungen zeigen die Ladeanzeige des Dashboards länger als 30 Sekunden, bevor der Tab geschlossen wird. Die erste Datenanfrage führt nie zu einem angezeigten Erfolgs- oder Fehlerzustand. Andere Seitenressourcen werden normal geladen. Das grenzt den Fehler auf den Datenladepfad ein und spricht gegen einen vollständigen Seitenausfall.

So untersuchen Sie das Problem

Prüfen Sie die ausstehende Anfrage und die Fehlergrenze der Komponente, fügen Sie einen wiederherstellbaren Timeout-Zustand hinzu und bestätigen Sie, dass Nutzer fehlgeschlagene Ladevorgänge erneut versuchen können.

Clientfehler

JavaScript-Ausnahmen, fehlgeschlagene Fetches, Hydration-Fehler.

Problemtyp: Regression (Verhalten, das durch ein bestimmtes Deployment oder eine Konfigurationsänderung beeinträchtigt wurde.)

Neuer TypeError nach dem Release

Status: Offen

Beschreibung

Eine neu veröffentlichte Seite löst beim Rendern einen TypeError aus und verhindert so, dass betroffene Nutzer ihre Inhalte erreichen.

Was passiert ist

Die Ausnahme tritt erstmals in Sitzungen mit dem neuen Release auf und verweist auf dieselbe Stelle im Stack. Der fehlerhafte Code liest vor dem Rendern der Seite eine Eigenschaft aus einem fehlenden Antwortobjekt. Anfragen können auf Netzwerkebene erfolgreich sein, während die Benutzeroberfläche ihre Ergebnisse trotzdem nicht anzeigt.

So untersuchen Sie das Problem

Ordnen Sie den Stack dem veröffentlichten Quellcode zu, prüfen Sie die Antwortstruktur in betroffenen Sitzungen und behandeln Sie den fehlenden Wert vor dem Rendern.

Regression bei Web Vitals

Seitenladezeit und Reaktionsfähigkeit verschlechtern sich.

Problemtyp: Leistungseinbußen (Seiten, Jobs oder APIs werden plötzlich oder allmählich langsamer.)

Interaktionslatenz verdoppelt

Status: Offen

Beschreibung

Interaktionen auf einer Seite benötigen deutlich länger, bis eine visuelle Reaktion erfolgt, obwohl der Server weiterhin normal antwortet.

Was passiert ist

Die Interaktionslatenz auf der Seite verdoppelt sich gegenüber dem vorherigen Ausgangswert. Browser-Traces führen die zusätzliche Wartezeit auf lange Arbeit auf dem Hauptthread nach einer Nutzereingabe zurück, während die Netzwerkzeiten vergleichbar bleiben. Nutzer erleben eine verzögerte Benutzeroberfläche, ohne dass ein entsprechender API-Fehler oder Latenzanstieg auftritt.

So untersuchen Sie das Problem

Erstellen Sie ein Profil der langen Aufgabe nach der Eingabe, vergleichen Sie den geänderten Renderpfad und verschieben oder reduzieren Sie synchrone Arbeit, bevor Sie die Reaktionsfähigkeit erneut messen.

Verhalten in bestimmten Segmenten

Nur ein Browser, Betriebssystem, eine App-Version, Region oder ein Kunde ist betroffen.

Problemtyp: Frontend-Fehler (Funktioniert in einem bestimmten Browser, auf einem bestimmten Gerät oder mit einer bestimmten App-Version nicht.)

Checkout schlägt in Safari 18 fehl

Status: Offen

Beschreibung

Der Checkout schlägt in Sitzungen mit Safari 18 fehl, während andere Browser denselben Ablauf abschließen. Dadurch bleibt die Regression in der Gesamterfolgsrate verborgen.

Was passiert ist

Fehlgeschlagene Checkout-Sitzungen konzentrieren sich auf Safari 18. Die Client-Traces dieser Sitzungen enden vor der Zahlungsanfrage, während derselbe Warenkorb in anderen Browsern den Zahlungsschritt erreicht. Der browserspezifische Fehler verhindert Käufe, ohne einen entsprechenden Fehler beim Zahlungsanbieter auszulösen.

So untersuchen Sie das Problem

Reproduzieren Sie die fehlerhafte Interaktion in Safari 18, prüfen Sie die Kompatibilität der Browser-APIs und Client-Ausnahmen und verifizieren Sie anschließend die Korrektur in den funktionierenden Browsern.

Deployments und Konfiguration

Änderung nach dem Deployment

Jedes andere Signal, das innerhalb weniger Minuten nach einem Deployment auftritt und mit dem Commit zusammenhängt.

Problemtyp: Regression (Verhalten, das durch ein bestimmtes Deployment oder eine Konfigurationsänderung beeinträchtigt wurde.)

Funnel direkt nach dem Release eingebrochen

Status: Offen

Beschreibung

Ein Release fällt mit weniger abgeschlossenen Nutzerabläufen und einem neuen Ablehnungsereignis zusammen. Das deutet auf einen Zusammenhang zwischen der Regression und einem geänderten Anfragepfad hin.

Was passiert ist

Vier Minuten nach dem Release tritt ein zuvor unbekanntes Validierungsereignis auf und die Funnel-Abschlussrate sinkt. Fehlgeschlagene Sitzungen erreichen denselben Schritt und enthalten die neue Build-Kennung; Sitzungen mit dem vorherigen Build werden weiterhin abgeschlossen. Der Vergleich legt nahe, den veröffentlichten Pfad als Nächstes zu untersuchen.

So untersuchen Sie das Problem

Vergleichen Sie die Validierung und Antwortverarbeitung zwischen den beiden Builds. Reproduzieren Sie die betroffene Eingabe und prüfen Sie einen Rollback, während Sie die Änderung isolieren.

Änderung an Konfiguration oder Feature-Flag

Das Verhalten ändert sich nach einer Änderung an einem Feature-Flag, einer Umgebungsvariable oder der Infrastruktur.

Problemtyp: Regression (Verhalten, das durch ein bestimmtes Deployment oder eine Konfigurationsänderung beeinträchtigt wurde.)

Feature-Flag-Rollout beeinträchtigt Speichervorgänge

Status: Offen

Beschreibung

Ein teilweise aktiviertes Feature-Flag leitet einen Teil der Speichervorgänge über einen fehlerhaften Pfad, während der übrige Traffic normal weiterläuft.

Was passiert ist

Das Flag ist für 10 % des Traffics aktiviert, und fehlgeschlagene Speichervorgänge machen denselben Anteil aus. Fehlerdatensätze gehören zur aktivierten Kohorte; in der deaktivierten Kohorte werden Änderungen weiterhin gespeichert. Die Rollout-Grenze ermöglicht einen direkten Vergleich, um die Regression zu lokalisieren.

So untersuchen Sie das Problem

Deaktivieren Sie die betroffene Flag-Kohorte, vergleichen Sie die beiden Speicherpfade und überprüfen Sie die gespeicherten Ergebnisse, bevor Sie den Rollout erneut ausweiten.

Abhängigkeitsänderung

Ein aktualisiertes Paket fällt zeitlich mit einem neuen Verhalten zusammen.

Problemtyp: Leistungseinbußen (Seiten, Jobs oder APIs werden plötzlich oder allmählich langsamer.)

Abfragen nach ORM-Upgrade 20-mal langsamer

Status: Offen

Beschreibung

Ein ORM-Upgrade ändert die Ausführung eines häufigen Lesezugriffs und verlangsamt dadurch Anfragen, ohne die von Nutzern angeforderte Datenmenge zu verändern.

Was passiert ist

Langsame Abfragen treten erstmals mit dem aktualisierten Build auf und häufen sich bei einer generierten Abfrage. Die vorherige Version verwendet für dieselbe Eingabe eine andere Abfrageform, während das Anfragevolumen vergleichbar bleibt. Die Abhängigkeitsänderung ist eine plausible Ursache für die zusätzliche Datenbankarbeit.

So untersuchen Sie das Problem

Vergleichen Sie das generierte SQL und die Abfragepläne zwischen den ORM-Versionen, prüfen Sie das geänderte Ladeverhalten und testen Sie eine korrigierte Abfrage oder einen Rollback der Abhängigkeit.

Fehler werden abgefangen und verschluckt

Ein Commit fügt auf einem wichtigen Pfad eine allgemeine Fehlerbehandlung hinzu.

Problemtyp: Stilles Versagen (Eine Funktion scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

Controller verbirgt alle Ausnahmen

Status: Offen

Beschreibung

Ein Controller wandelt fehlgeschlagene Vorgänge nun in erfolgreiche Antworten um. Dadurch können Aufrufer und Fehlerüberwachung nicht erkennen, dass die Arbeit nicht abgeschlossen wurde.

Was passiert ist

Der geänderte Controller umschließt seinen Hauptvorgang mit einem allgemeinen Fehlerhandler, der Erfolg zurückgibt. Anfrage-Traces enthalten vor der Antwort eine Ausnahme, aber kein entsprechendes gespeichertes Ergebnis. Der neue Handler maskiert Fehler, statt sie zu beheben. Dadurch können Nutzer Änderungen verlieren, ohne eine Fehlermeldung zu sehen.

So untersuchen Sie das Problem

Prüfen Sie den allgemeinen Fehlerbehandlungspfad, geben Sie bei fehlgeschlagenen Vorgängen weiterhin Fehlerantworten zurück und stellen Sie sicher, dass Erfolg erst nach Abschluss des Schreibvorgangs gemeldet wird.

Auswirkungen einer Migration

Eine Schema-Migration ändert das Abfrageverhalten.

Problemtyp: Leistungseinbußen (Seiten, Jobs oder APIs werden plötzlich oder allmählich langsamer.)

Abfragen nach der Migration 20-mal langsamer

Status: Offen

Beschreibung

Eine Schema-Migration entfernt den Index, den eine häufig ausgeführte Abfrage verwendet. Dadurch verlängert sich ihre Ausführungszeit und die davon abhängigen Anfragen werden langsamer.

Was passiert ist

Die betroffene Abfrage dauert nach der Migration 20-mal länger. Ihr Plan wechselt von einer indexgestützten Suche zu einem umfassenden Scan, während die Anfrageform unverändert bleibt. Durch den fehlenden Index muss jede Anfrage deutlich mehr Zeilen prüfen, was die Datenbankarbeit bei normalem Traffic erhöht.

So untersuchen Sie das Problem

Vergleichen Sie die Migration und die Abfragepläne, bestätigen Sie die erforderliche Indexstruktur und stellen Sie mithilfe des sicheren Migrationsverfahrens der Datenbank einen geeigneten Index wieder her.

Leistung

Plötzlicher Latenzanstieg

Ein abrupter Anstieg.

Problemtyp: Regression (Verhalten, das durch ein bestimmtes Deployment oder eine Konfigurationsänderung beeinträchtigt wurde.)

Seitenladezeit auf 1,2 s gestiegen

Status: Offen

Beschreibung

Seiten werden unmittelbar nach einem Deployment viermal langsamer geladen. Dadurch entsteht eine spürbare Wartezeit in einem ansonsten erfolgreichen Nutzerablauf.

Was passiert ist

Die Seitenladezeit steigt nach dem Deployment von 300 ms auf 1,2 s. Anfrage-Traces zeigen, dass der Anstieg im serverseitigen Datenladeabschnitt und nicht beim Herunterladen von Ressourcen auftritt. Die Antworten sind weiterhin erfolgreich, sodass sich die langsamere Nutzungserfahrung nicht allein anhand der Fehlerzahlen erkennen lässt.

So untersuchen Sie das Problem

Vergleichen Sie den Code zum Laden der Daten und die Abfragezeiten vor und nach dem Deployment. Überprüfen Sie anschließend den langsamen Pfad mit derselben Anfrageeingabe.

Allmählicher Latenzanstieg

Eine schleichende Verschlechterung über Tage oder Wochen, die niemand bemerkt.

Problemtyp: Leistungseinbußen (Seiten, Jobs oder APIs werden plötzlich oder allmählich langsamer.)

Suche wird jede Woche langsamer

Status: Offen

Beschreibung

Die Suche wird nach und nach langsamer. So summiert sich eine für Nutzer spürbare Verzögerung, die nicht als einzelner Vorfall mit einem deutlichen Ausschlag erscheint.

Was passiert ist

Vergleichbare Suchanfragen dauern jede Woche etwa 5 % länger. Der Anstieg bleibt auch nach Berücksichtigung des Anfragevolumens bestehen und konzentriert sich auf die Datensuche statt auf die Übertragung der Antwort. Zunehmender Aufwand pro Abfrage ist eine mögliche Ursache, auch wenn kein einzelnes Deployment den Trend erklärt.

So untersuchen Sie das Problem

Vergleichen Sie Abfragepläne, untersuchte Zeilen und Indexgröße über die Ausgangszeiträume hinweg. Prüfen Sie, ob das Datenwachstum die Kosten des häufig genutzten Suchpfads verändert hat.

Tail-Latenz

Nur die langsamsten Anfragen werden langsamer.

Problemtyp: Leistungseinbußen (Seiten, Jobs oder APIs werden plötzlich oder allmählich langsamer.)

p99-Latenz verdreifacht

Status: Offen

Beschreibung

Die langsamsten Anfragen dauern deutlich länger, während typische Anfragen schnell bleiben. Dadurch bleibt eine verschlechterte Nutzungserfahrung für eine kleinere Nutzergruppe verborgen.

Was passiert ist p99-Latenz verdreifacht sich, während der Median unverändert bleibt. Langsame Traces verbringen den Großteil ihrer zusätzlichen Zeit damit, vor der Ausführung auf eine gemeinsam genutzte Ressource zu warten. Durchschnittswerte über alle Anfragen hinweg verbergen diese Wartezeiten, aber betroffene Anfragen bleiben lange genug blockiert, um Client-Timeouts zu riskieren.

So untersuchen Sie das Problem

Gruppieren Sie langsame Traces nach Ressource und Workload, vergleichen Sie deren Wartezeit mit der Ausführungszeit und untersuchen Sie die Ressourcenkonkurrenz, bevor Sie die Kapazität erhöhen.

Auftreten langsamer Abfragen

Eine neue langsame Abfrage oder ein neues N+1-Muster.

Problemtyp: Leistungsverschlechterung (Langsamere Seiten, Jobs oder APIs, plötzlich oder schleichend.)

Eine Seite führt 400 Abfragen aus

Status: Offen

Beschreibung

Eine Seite führt für jedes angezeigte Element eine separate Datenbanksuche aus. Dadurch steigen Antwortzeit und Datenbanklast mit zunehmender Listengröße.

Was ist passiert

Eine Seitenanfrage führt jetzt 400 Abfragen mit derselben Anweisungsform und unterschiedlichen Datensatz-IDs aus. Die wiederholten Lesevorgänge erfolgen nacheinander nach der anfänglichen Listenabfrage. Dieses N+1-Muster verursacht Arbeit proportional zur Anzahl der angezeigten Elemente, statt die zugehörigen Daten gemeinsam abzurufen.

So untersuchen Sie das Problem

Verfolgen Sie die Suche pro Element, fassen Sie die zugehörigen Lesevorgänge in Stapeln zusammen oder verwenden Sie einen Join und vergleichen Sie Abfrageanzahl und Antwortzeit mit einer repräsentativen Liste.

Zunehmende Start- und Kaltstartzeiten

Der Start von Diensten dauert länger.

Problemtyp: Kapazitätsrisiko (Hinweis auf eine Grenze, bevor sie zum Problem wird.)

Deployments werden langsamer betriebsbereit

Status: Offen

Beschreibung

Neue Instanzen benötigen länger, bis sie bereit sind. Dadurch verlangsamen sich Deployments und der Dienst kann langsamer auf zusätzliche Nachfrage reagieren.

Was ist passiert

Das Intervall vom Prozessstart bis zur Betriebsbereitschaft ist dreimal so lang wie zuvor. Die Startprotokolle zeigen die zusätzliche Verzögerung vor Abschluss der Initialisierung, während die Latenz von Anfragen im laufenden Betrieb ähnlich bleibt. Rollouts und Skalierungen warten daher länger auf nutzbare Kapazität.

So untersuchen Sie das Problem

Unterteilen Sie den Start in das Laden von Abhängigkeiten, die Initialisierung und Bereitschaftsprüfungen, vergleichen Sie jede Phase mit dem vorherigen Build und entfernen Sie unnötige Arbeit aus dem Bereitschaftspfad.

Zunehmende Wartezeit in der Warteschlange

Arbeit wartet länger, bevor sie beginnt.

Problemtyp: Fehler bei Hintergrundjobs (Geplante Arbeit wurde verpasst, dupliziert, hängt fest oder bleibt aus.)

E-Mails werden mit 20 Minuten Verspätung versendet

Status: Offen

Beschreibung

E-Mail-Jobs warten lange vor ihrer Ausführung in der Warteschlange. Dadurch verzögert sich der Versand, obwohl die Zustellung selbst weiterhin erfolgreich ist.

Was ist passiert

Der Abstand zwischen einem E-Mail-Auslöser und dem Sendeversuch wächst auf 20 Minuten. Sobald ein Worker einen Job startet, bleiben Verarbeitungs- und Antwortzeiten des Anbieters normal. Die Verzögerung entsteht vor der Ausführung. Daher lässt sich anhand der Anzahl erfolgreicher Zustellungen allein nicht erkennen, dass die Nachrichten verspätet ankommen.

So untersuchen Sie das Problem

Vergleichen Sie das Alter der Warteschlange, die Worker-Konkurrenz und konkurrierende Jobtypen. Beseitigen Sie den Engpass oder trennen Sie dringende E-Mails ab, ohne sicheres Wiederholungsverhalten zu beeinträchtigen.

Infrastruktur

Annäherung an eine Grenze

Cloud-Kontingente, Burst-Credits, API-Ratenlimits, Dateihandles, Tariflimits.

Problemtyp: Kapazitätsrisiko (Hinweis auf eine Grenze, bevor sie zum Problem wird.)

Burst-Credits gehen zur Neige

Status: Offen

Beschreibung

Dateisystem-Burst-Credits werden schneller verbraucht, als sie sich erholen. Dadurch drohen beim Start und bei anderen speicherintensiven Arbeiten Drosselungen.

Was ist passiert

Der Credit-Kontostand sinkt über aufeinanderfolgende Intervalle, da die Lesevorgänge den bereitgestellten Basiswert überschreiten. Der Start neuer Instanzen überschneidet sich mit diesen Lesevorgängen und hängt von der verfügbaren Durchsatzrate ab. Der Trend weist auf begrenzte verbleibende Burst-Kapazität hin, beweist aber nicht, dass das Volume bereits gedrosselt wurde.

So untersuchen Sie das Problem

Vergleichen Sie den Speicherdurchsatz mit dem Basiswert und der Credit-Erholungsrate, ermitteln Sie die Hauptverursacher der Lesevorgänge und passen Sie die Bereitstellung oder die E/A beim Start an, bevor die Credits aufgebraucht sind.

Auslastung

CPU, Arbeitsspeicher, Verbindungspools, Thread-Pools, Datenträger.

Problemtyp: Kapazitätsrisiko (Hinweis auf eine Grenze, bevor sie zum Problem wird.)

Verbindungspool fast ausgelastet

Status: Offen

Beschreibung

Der Datenbank-Verbindungspool hat während Lastspitzen kaum Reserven. Dadurch warten Anfragen, bevor sie eine Abfrage ausführen können.

Was ist passiert

Die Pool-Auslastung erreicht bei Spitzenlast 95 %, und die Wartezeiten beim Abrufen von Verbindungen steigen gleichzeitig an. Sobald eine Verbindung verfügbar ist, bleibt die Abfrageausführungszeit vergleichsweise stabil. Der Engpass liegt an der Pool-Grenze und kann dazu führen, dass normale Anfrage-Spitzen Timeouts verursachen.

So untersuchen Sie das Problem

Untersuchen Sie lange gehaltene Verbindungen und Transaktionslaufzeiten, prüfen Sie die Datenbankkapazität und beheben Sie unnötig lange Verbindungsbelegungen, bevor Sie das Pool-Limit erhöhen.

Zunehmender Rückstand

Eine Warteschlange wächst schneller, als sie abgearbeitet wird.

Problemtyp: Fehler bei Hintergrundjobs (Geplante Arbeit wurde verpasst, dupliziert, hängt fest oder bleibt aus.)

Job-Warteschlange wächst seit 6 Stunden

Status: Offen

Beschreibung

Es kommen mehr Jobs hinzu, als abgeschlossen werden. Dadurch wächst die Menge der angenommenen, aber noch nicht verarbeiteten Arbeit stetig.

Was ist passiert

Die Job-Warteschlange wächst sechs Stunden in Folge, weil die Anzahl eingereihter Jobs die Anzahl abgeschlossener Jobs übersteigt. Ältere Jobs warten weiterhin, obwohl Worker aktiv sind. Der Dienst verarbeitet zwar einen Teil der Arbeit, aber sein Durchsatz reicht nicht aus, um die eingehende Last zu bewältigen.

So untersuchen Sie das Problem

Vergleichen Sie Eingangs- und Abschlussraten nach Jobtyp, ermitteln Sie langsame oder wiederholte Jobs und stellen Sie genügend Verarbeitungskapazität bereit, um den ältesten Rückstand abzubauen.

Ausgebliebener Zeitplan

Ein Cron-Job wurde nicht oder doppelt ausgeführt oder dauerte zu lange.

Problemtyp: Fehler bei Hintergrundjobs (Geplante Arbeit wurde verpasst, dupliziert, hängt fest oder bleibt aus.)

Nächtlicher Export ausgefallen

Status: Offen

Beschreibung

Ein geplanter Export wurde nicht gestartet. Dadurch fehlen nachgelagerten Verbrauchern die aktuellen Daten, die dieser Lauf normalerweise erzeugt.

Was ist passiert

Für den nächtlichen Export gibt es am Sonntag weder einen Start- noch einen Abschlussdatensatz, obwohl die benachbarten geplanten Läufe vorhanden sind. Auch für dieses Zeitintervall gibt es keine Ausgabe. Die Lücke deutet auf einen ausgebliebenen Auslöser oder eine fehlgeschlagene Zulassung hin, nicht auf einen Job, der ausgeführt wurde und einen Fehler zurückgab.

So untersuchen Sie das Problem

Prüfen Sie die Ausführung des Schedulers, die Zeitzonenbehandlung und Sperren gegen überlappende Läufe. Füllen Sie anschließend das fehlende Intervall nach, nachdem Sie sichergestellt haben, dass die erneute Ausführung keine Exporte dupliziert.

Neustartschleifen

Neustarts, Beendigungen wegen Speichermangels, fehlschlagende Zustandsprüfungen.

Problemtyp: Fehler bei Hintergrundjobs (Geplante Arbeit wurde verpasst, dupliziert, hängt fest oder bleibt aus.)

Worker startet alle 12 Minuten neu

Status: Offen

Beschreibung

Ein Worker wird wiederholt neu gestartet, bevor er die normale Verarbeitung dauerhaft aufrechterhalten kann. Dadurch werden laufende Jobs unterbrochen und Jobs in der Warteschlange verzögert.

Was ist passiert

Der Worker startet, verarbeitet Jobs und wird in einem Zyklus von ungefähr 12 Minuten beendet. Bei jedem Neustart geht der aktuelle Prozesszustand verloren, woraufhin nicht abgeschlossene Arbeit erneut zugestellt wird. Das Muster weist auf wiederholte Prozessfehler hin. Der Beendigungsgrund muss jedoch zwischen einem Absturz, einer ressourcenbedingten Beendigung und einer fehlgeschlagenen Zustandsprüfung unterscheiden.

So untersuchen Sie das Problem

Prüfen Sie die Exit-Codes, den Speicherverbrauch und Ereignisse der Zustandsprüfungen rund um jeden Neustart. Beheben Sie den Fehler und verifizieren Sie, dass unterbrochene Jobs ohne doppelte Nebenwirkungen fortgesetzt werden.

Ablaufdatum rückt näher

Zertifikate, Domains, API-Tokens, OAuth-Berechtigungen.

Problemtyp: Kapazitätsrisiko (Hinweis auf eine Grenze, bevor sie zum Problem wird.)

TLS-Zertifikat läuft ab

Status: Offen

Beschreibung

Ein Zertifikat im aktiven Auslieferungspfad läuft bald ab, ohne dass erkennbar ist, dass ein Ersatz installiert wurde.

Was ist passiert

Das vom Endpunkt bereitgestellte TLS-Zertifikat läuft in sechs Tagen ab. Wiederholte Prüfungen liefern weiterhin dasselbe Zertifikat, sodass die Erneuerung die Auslieferungsebene noch nicht erreicht hat. Verbindungen funktionieren derzeit, schlagen aber bei der Validierung fehl, wenn dieses Zertifikat nach Ablauf seiner Gültigkeit weiterhin aktiv ist.

So untersuchen Sie das Problem

Prüfen Sie die Automatisierung der Erneuerung und die Zertifikatsbereitstellung, installieren Sie das Ersatz-Zertifikat und verifizieren Sie das Zertifikat, das Clients tatsächlich bereitgestellt wird.

Fehler beim Cloud-Anbieter

Drosselungen oder Fehler bei AWS- oder GCP-APIs.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder vorgelagerter Dienst ist ausgefallen oder hat sich geändert.)

S3 verlangsamt Uploads

Status: Offen

Beschreibung

Bei Objekt-Uploads wird mehr Zeit für Wiederholungsversuche bei Speicheranbieter-Anfragen aufgewendet. Dadurch verlangsamen sich Dateiübertragungen für Nutzer, und Upload-Worker werden gebunden.

Was ist passiert

S3-Anfragen geben während Uploads SlowDown-Antworten zurück, woraufhin wiederholt Versuche für dieselben Objekte unternommen werden. Die zusätzliche Dauer entsteht durch Wiederholungen beim Speicheranbieter und nicht durch die lokale Dateiverarbeitung. Erfolgreiche abschließende Antworten können die zusätzliche Wartezeit und den Ressourcenverbrauch entlang des Upload-Pfads verschleiern.

So untersuchen Sie das Problem

Prüfen Sie die Anfragekonkurrenz und die Wiederholungsverzögerung, vergleichen Sie betroffene Objektpräfixe und stellen Sie sicher, dass gedrosselte Uploads sicher fortgesetzt werden, ohne bereits abgeschlossene Arbeit erneut zu starten.

Drittanbieter

Webhook-Lücke

Erwartete eingehende Webhooks treffen nicht mehr ein.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder vorgelagerter Dienst ist ausgefallen oder hat sich geändert.)

Webhooks zur E-Mail-Zustellung werden nicht mehr empfangen

Status: Offen

Beschreibung

E-Mails werden weiterhin versendet, aber Zustellungs-Callbacks bleiben aus. Dadurch kann der lokale Zustellungsstatus nicht mehr widerspiegeln, was der Anbieter tatsächlich getan hat.

Was ist passiert

Eine Stunde lang treffen keine E-Mail-Zustellungsereignisse ein, während ausgehende Sendeanfragen weiterhin Anbieter-IDs erhalten. Die Lücke betrifft nur Callbacks und nicht die gesamte E-Mail-Aktivität. Nachrichten könnten zugestellt worden oder fehlgeschlagen sein, ohne dass eines der beiden Ergebnisse die Anwendung erreicht.

So untersuchen Sie das Problem

Vergleichen Sie die Zustellungsdatensätze des Anbieters mit den lokal empfangenen Webhooks, prüfen Sie den Callback-Endpunkt und die Signaturvalidierung und spielen Sie anschließend fehlende Ereignisse sicher erneut ein.

Beeinträchtigung beim Anbieter

Fehler oder Latenz bei einem Anbieter, von dem Sie abhängig sind.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder vorgelagerter Dienst ist ausgefallen oder hat sich geändert.)

Anmeldecodes werden nie versendet

Status: Offen

Beschreibung

Anmeldeanfragen schienen erfolgreich zu sein, während der E-Mail-Anbieter die Nachrichten ablehnte, die Nutzer zum Abschließen der Authentifizierung benötigten.

Was ist passiert

Anmeldecodes kamen nie an, weil der E-Mail-Anbieter die sendende Domain nicht mehr als verifiziert einstufte. Der Versand lief als Hintergrundaufgabe, sodass die API weiterhin 200 zurückgab.

So untersuchen Sie das Problem

Stellen Sie die Verifizierung der sendenden Domain wieder her und prüfen Sie die Ergebnisse der Hintergrundversandaufgaben. Machen Sie die Ablehnung der Codezustellung sichtbar, statt die 200-Antwort der API als Zustellungsnachweis zu behandeln.

Ratenbegrenzung durch den Anbieter

Sie werden gedrosselt.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder vorgelagerter Dienst ist ausgefallen oder hat sich geändert.)

Kontingent der Ticketing-API täglich ausgeschöpft

Status: Offen

Beschreibung

Ein wiederkehrender Ticket-Abruf überschritt das Kontingent des Anbieters und ließ die letzte Region teilweise veraltet zurück, während der Vorgang weiterhin als normal abgeschlossen gemeldet wurde.

Was ist passiert

Ein täglicher Abruf erreichte zwei Wochen lang jeden Tag das Kontingent der Ticketing-API: etwa 10,5k Anfragen bei einem Limit von 10k. Die letzte Region wurde nie vollständig aktualisiert, und der Job endete jedes Mal normal.

So untersuchen Sie das Problem

Verteilen Sie die Anfragen auf die Regionen, setzen Sie den Abruf nach Wiederherstellung des Kontingents ab dem unvollständigen Abschnitt fort und erfassen Sie einen Teilabschluss, wenn der Abruf am Anbieterlimit endet.

Vertragsänderung

Das Antwortformat eines Anbieters ändert sich.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder vorgelagerter Dienst ist ausgefallen oder hat sich geändert.)

Anbieterfeld wird leer zurückgegeben

Status: Offen

Beschreibung

Eine Anbieterantwort enthält ein von der Anwendung benötigtes Feld nicht mehr. Dadurch wird die Verarbeitung unterbrochen, obwohl die vorgelagerte Anfrage erfolgreich ist.

Was ist passiert

Zuvor ausgefüllte Werte werden in erfolgreichen Anbieterantworten leer zurückgegeben. Die Anwendung geht weiterhin davon aus, dass das Feld vorhanden ist, und kann die entsprechende Aktualisierung nicht abschließen. Die Änderung erfolgt an der Integrationsgrenze, ohne dass ein HTTP-Fehler auftritt. Daher bleibt die Überwachung auf Transportebene unauffällig.

So untersuchen Sie das Problem

Vergleichen Sie die tatsächlichen Antwortformate mit dem erwarteten Vertrag und den Änderungen des Anbieters, validieren Sie erforderliche Felder und behandeln Sie den fehlenden Wert ausdrücklich, bevor Sie Aktualisierungen wiederholen.

Übereinstimmung mit einem Anbieter-Vorfall

Die Statusseite eines Anbieters meldet einen Vorfall, der zeitlich mit Ihren Fehlern zusammenfällt.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder ein vorgelagerter Dienst ist ausgefallen oder wurde geändert.)

Anmeldefehler stimmen mit einem Vorfall beim Anbieter überein

Status: Offen

Beschreibung

Anmeldefehler treten zeitgleich mit einem Vorfall beim Identitätsanbieter auf. Das deutet eher auf ein Problem mit einer vorgelagerten Abhängigkeit als auf einen umfassenden Anwendungsausfall hin.

Was passiert ist

Anmeldefehler beginnen im selben Zeitraum und in derselben Region, die auf der Statusseite des Identitätsanbieters beschrieben werden. Die Fehler treten während des Austauschs mit dem Anbieter auf, während nicht damit zusammenhängende Anwendungsanfragen weiterhin funktionieren. Zeitpunkt und betroffene Abhängigkeit stützen den Zusammenhang, schließen aber einen zusätzlichen lokalen Fehler nicht aus.

So untersuchen Sie den Vorfall

Vergleichen Sie fehlgeschlagene Austausche mit dem Umfang des Vorfalls beim Anbieter, prüfen Sie die lokale Konfiguration und beobachten Sie die Wiederherstellung. Bieten Sie Nutzern dabei eine klare Möglichkeit, es erneut zu versuchen.

Abweichungen im LLM-Verhalten

Modellausgaben ändern sich: Länge, Ablehnungen, fehlerhaftes JSON, Tokenverbrauch.

Problemtyp: Abhängigkeitsfehler (Ein Anbieter oder ein vorgelagerter Dienst ist ausgefallen oder wurde geändert.)

Strukturierte Ausgabe schlägt in 4 % der Fälle fehl

Status: Offen

Beschreibung

Modellantworten verletzen häufiger den Vertrag für strukturierte Ausgaben. Dadurch können nachgelagerte Aufgaben ansonsten erfolgreiche Abschlüsse nicht verarbeiten.

Was passiert ist

Fehler beim Parsen strukturierter Ausgaben steigen bei derselben Funktion von 0,1 % auf 4 %. Ungültige Antworten enthalten fehlende Felder oder Text außerhalb des erwarteten JSON-Formats. Anfragen an den Anbieter werden weiterhin abgeschlossen, aber die Anwendung kann diese Ergebnisse nicht sicher verwenden und muss die betroffenen Aufgaben ablehnen oder erneut versuchen.

So untersuchen Sie den Vorfall

Vergleichen Sie Modellversion, Prompts und Schema-Validierung vor und nach der Änderung, prüfen Sie ungültige Ausgaben und verifizieren Sie eine Lösung mit eingeschränkter Ausgabe, bevor Sie die normale Verarbeitung wieder aufnehmen.

Datenintegrität

Schreiben ohne Persistierung

Ein Speichervorgang wird bestätigt, aber später ist nichts davon zu sehen.

Problemtyp: Stiller Fehler (Eine Funktion scheint zu funktionieren, tut es aber nicht: wirkungslose Aktionen, abgefangene Ausnahmen, unvollständige Ausführung, falsche Ergebnisse, festgefahrene Zustände.)

CI-Synchronisierung speicherte nichts und meldete Erfolg

Status: Offen

Beschreibung

Eine CI-Synchronisierung meldete Erfolg, nachdem sie Pipelines abgerufen, aber keine gespeichert hatte. Dadurch konnten veraltete Projektdaten wie eine erfolgreiche Aktualisierung wirken.

Was passiert ist

Eine CI-Synchronisierung lief die vollen 30 Minuten, rief Tausende von Pipelines ab, speicherte keine davon und markierte sich als erfolgreich. Fehler einzelner Projekte wurden abgefangen und ignoriert. Dadurch wirkte der Synchronisierungsverlauf unauffällig, während die Daten veralteten.

So untersuchen Sie den Vorfall

Prüfen Sie die abgefangenen und ignorierten Fehler einzelner Projekte, gleichen Sie abgerufene Pipelines mit den gespeicherten Datensätzen ab und führen Sie die Synchronisierung betroffener Projekte erst erneut aus, wenn die Schreibvorgänge verifiziert sind.

Doppelte Verarbeitung

Dasselbe Ereignis, derselbe Auftrag oder dieselbe Zahlung wird zweimal verarbeitet.

Problemtyp: Datenintegrität (Verlorene Schreibvorgänge, Duplikate, Beschädigungen, nicht übereinstimmende Datensätze.)

Zwei Willkommens-E-Mails pro Anmeldung

Status: Offen

Beschreibung

Jedes neue Konto erhält zwei Willkommens-E-Mails, weil dasselbe Anmeldeereignis den Versand mehr als einmal auslösen kann.

Was passiert ist

Zwei abgeschlossene Versandversuche haben dieselbe Anmeldeereignis-ID und denselben Empfänger, aber unterschiedliche Versand-IDs. Ein erneut zugestelltes Ereignis gelangt wieder in den Handler für Willkommens-E-Mails, ohne dass eine Versandsperre erfasst wurde. Der doppelte Nebeneffekt erreicht den Nutzer, obwohl beide Versuche einzeln erfolgreich sind.

So untersuchen Sie den Vorfall

Verfolgen Sie die erneute Zustellung des Ereignisses und die Versandsperre, gestalten Sie den Versand für jedes Anmeldeereignis idempotent und verifizieren Sie, dass eine erneute Verarbeitung nur eine E-Mail erzeugt.

Abweichungen beim Abgleich

Zählwerte stimmen zwischen Systemen nicht überein.

Problemtyp: Datenintegrität (Verlorene Schreibvorgänge, Duplikate, Beschädigungen, nicht übereinstimmende Datensätze.)

Einzahlung ausgezahlt, aber nie gutgeschrieben

Status: Offen

Beschreibung

Die spätere Auszahlung einer Einzahlung aktualisierte das Wallet des Nutzers nicht, nachdem der Anbieter die Einzahlung zuvor als fehlgeschlagen gemeldet hatte.

Was passiert ist

Ein Zahlungsanbieter meldete eine Einzahlung als fehlgeschlagen und zahlte sie 40 Minuten später aus. Das Geld ging ein, aber dem Wallet des Nutzers wurde nichts gutgeschrieben, und es trat kein Fehler auf.

So untersuchen Sie den Vorfall

Vergleichen Sie den endgültigen Einzahlungsstatus beim Anbieter mit dem Wallet-Ledger. Gleichen Sie die fehlende Gutschrift ab und verifizieren Sie, dass spätere Statusänderungen ohne doppelte Gutschrift verarbeitet werden.

Abweichungen bei Geschäftsmetriken

Anmeldungen, Anträge, Zahlungen oder Nachrichten weichen stark von ihrem üblichen Umfang ab.

Problemtyp: Störung eines Geschäftsablaufs (Ein Rückgang einer wichtigen Metrik mit technischer Ursache.)

Anträge um 35 % gesunken

Status: Offen

Beschreibung

Es werden weniger Anträge als üblich abgeschlossen, obwohl die Zahl der Zugriffe vergleichbar ist. Das deutet auf ein Problem innerhalb des Übermittlungsablaufs hin.

Was passiert ist

Die Zahl der Anträge liegt 35 % unter der des gleichen Zeitraums der Vorwoche, während die Besuche des Antragsformulars vergleichbar bleiben. Die Abweichung beginnt zwischen den Übermittlungsversuchen und den gespeicherten Anträgen. Dieses Muster deutet eher auf ein Verarbeitungs- oder Validierungsproblem als auf einen einfachen Nachfragerückgang hin.

So untersuchen Sie den Vorfall

Vergleichen Sie Übermittlungsergebnisse und Validierungsgründe mit dem Basiszeitraum und verfolgen Sie betroffene Versuche bis zur Persistierung, bevor Sie den Rückgang dem Nutzerverhalten zuschreiben.

Leere Ausgabe

Aufträge melden Erfolg, erzeugen aber keine Ergebnisse.

Problemtyp: Fehler bei Hintergrundaufträgen (Geplante Arbeit wird ausgelassen, dupliziert, bleibt hängen oder liefert keine Ergebnisse.)

Bereinigung zur Datenaufbewahrung hat nichts unkenntlich gemacht

Status: Offen

Beschreibung

Ein Bereinigungsauftrag zur Datenaufbewahrung wurde wiederholt abgeschlossen, ohne die Prompt-Daten unkenntlich zu machen, die er für Organisationen ermittelt hatte, die der Aufbewahrung widersprochen hatten.

Was passiert ist

Für Organisationen, die der Aufbewahrung von Prompts widersprochen hatten, fand ein Bereinigungsauftrag wiederholt zu bereinigende Daten, machte jedoch null Zeilen unkenntlich und fuhr fort. Einen Monat lang lief er planmäßig und ohne Ausnahmen für 11 Organisationen.

So untersuchen Sie den Vorfall

Vergleichen Sie die Auswahl der Kandidaten mit dem Prädikat für die Unkenntlichmachung und der Anzahl betroffener Zeilen. Verifizieren Sie, dass berechtigte Daten entfernt werden, bevor Sie die betroffene Bereinigung erneut ausführen.

Veraltete Daten

Caches und Synchronisierungsaufträge werden nicht mehr aktualisiert.

Problemtyp: Datenintegrität (Verlorene Schreibvorgänge, Duplikate, Beschädigungen, nicht übereinstimmende Datensätze.)

Verzeichnisdaten seit drei Tagen veraltet

Status: Offen

Beschreibung

Verzeichnisabfragen liefern einen alten Snapshot, obwohl sich die vorgelagerte Quelle geändert hat. Nutzer erhalten dadurch veraltete Datensätze.

Was passiert ist

Die letzte erfolgreiche Aktualisierung des Verzeichnisses liegt drei Tage zurück. Abfragen liefern weiterhin diesen Snapshot, während Synchronisierungsversuche den Aktualitätsmarker nicht voranbringen. Verfügbarkeitsprüfungen bleiben erfolgreich, weil der Cache weiterhin antwortet, aber neu hinzugefügte oder geänderte Einträge fehlen.

So untersuchen Sie den Vorfall

Verfolgen Sie den Aktualisierungsauftrag und die Aktualisierung des Checkpoints, vergleichen Sie Quelldatensätze mit dem Cache-Snapshot und verifizieren Sie die Aktualität nach einer sicheren erneuten Synchronisierung.

Kosten

Anstieg des Protokollvolumens

Nach einer Bereitstellung wird es plötzlich sehr laut.

Problemtyp: Kostenanomalie (Ausgaben für Protokolle, Cloud- oder LLM-Nutzung steigen stark an.)

Debug-Zeile wird 40 Mio. Mal pro Tag protokolliert

Status: Offen

Beschreibung

Eine neu häufig ausgegebene Debug-Meldung dominiert den Protokollstrom und erhöht den Aufwand für Erfassung und Speicherung, ohne dass der Datenverkehr entsprechend zunimmt.

Was passiert ist

Nach einer Bereitstellung wird eine Debug-Zeile 40 Millionen Mal pro Tag protokolliert. Ihr Aufruf befindet sich innerhalb eines wiederholt ausgeführten Vorgangs, sodass jede Anfrage nun viele Kopien erzeugt. Die Zunahme des Volumens ist auf das Protokollierungsverhalten zurückzuführen und nicht auf einen vergleichbaren Anstieg nützlicher Anwendungsaktivität.

So untersuchen Sie den Vorfall

Finden Sie den wiederholt ausgeführten Protokollaufruf, reduzieren oder sampeln Sie redundante Ausgaben und bestätigen Sie, dass die Diagnoseabdeckung nach der Rückkehr des Volumens zum Basiswert weiterhin nützlich ist.

Cloud-Kostenanomalie

Die Ausgaben für einen Dienst oder eine Ressource steigen sprunghaft an.

Problemtyp: Kostenanomalie (Ausgaben für Protokolle, Cloud- oder LLM-Nutzung steigen stark an.)

Kosten für Datenübertragung verdoppelt

Status: Offen

Beschreibung

Die Ausgaben für Datenübertragung haben sich ohne vergleichbares Verkehrswachstum verdoppelt. Das deutet darauf hin, dass Anfragen über einen kostspieligeren Pfad geleitet werden.

Was passiert ist

Die Übertragungskosten verdoppeln sich über Nacht, während die Anzahl der Anwendungsanfragen ähnlich bleibt. Der Anstieg konzentriert sich auf den Datenverkehr zwischen Diensten und nicht auf die Größe nutzerseitiger Antworten. Eine Änderung an Routing oder Platzierung könnte wiederholte oder regionsübergreifende Übertragungen verursachen, die gewöhnliche Anfragemetriken nicht sichtbar machen.

So untersuchen Sie den Vorfall

Schlüsseln Sie die Übertragungsnutzung nach Quelle, Ziel und Bereitstellungsänderung auf und prüfen Sie, ob Routing oder doppelte Abrufe die zusätzlichen Bytes erklären.

Anstieg der LLM-Ausgaben

Der Tokenverbrauch steigt für eine Funktion oder einen Kunden sprunghaft an.

Problemtyp: Kostenanomalie (Ausgaben für Protokolle, Cloud- oder LLM-Nutzung steigen stark an.)

Agent-Schleife verbrauchte das Budget einer Woche

Status: Offen

Beschreibung

Ein Agent führt wiederholt ähnliche Modellaufrufe aus, ohne seine Aufgabe abzuschließen. Dadurch konzentriert sich ein ungewöhnlich hoher Tokenverbrauch auf einen einzelnen Arbeitsablauf.

Was passiert ist

Der Agent-Lauf eines Kontos verbraucht an einem Tag das übliche Tokenbudget einer Woche. Aufeinanderfolgende Aufrufe wiederholen dasselbe Tool-Ergebnis und enthalten immer mehr Kontext, aber es erscheint kein abschließendes Aufgabenergebnis. Die wiederholte Schleife erhöht die Kosten, ohne zusätzlichen nützlichen Fortschritt zu erzielen.

So untersuchen Sie den Vorfall

Prüfen Sie die wiederholte Entscheidung und das Tool-Ergebnis, stoppen Sie den unproduktiven Lauf und ergänzen Sie begrenzte Wiederholungsversuche sowie einen Abbruch bei ausbleibendem Fortschritt, bevor Sie die Aufgabe erneut starten.

Telemetrielücken

Dienst verstummt

Eine Quelle sendet keine Protokolle mehr.

Problemtyp: Beobachtbarkeitslücke (Bereiche, in denen Sie im Dunkeln tappen, oder Telemetrie, die Risiken birgt.)

Worker-Flotte verstummt

Status: Offen

Beschreibung

Nach einer Konfigurationsänderung hat eine Worker-Flotte keine Protokolle mehr ausgegeben. Dadurch fehlt die Diagnosespur, die zum Verständnis ihrer laufenden Arbeit benötigt wird.

Was passiert ist

Das Protokollvolumen der Worker fällt auf null, während die Warteschlangenaktivität zeigt, dass Aufträge weiterhin verarbeitet werden. Das Verstummen beginnt mit der Konfigurationsänderung und betrifft die Flotte statt eines einzelnen Hosts. Das deutet auf den Protokollierungs- oder Übermittlungspfad hin, beweist aber nicht, dass alle Worker angehalten haben.

So untersuchen Sie den Vorfall

Vergleichen Sie die Logger- und Exporter-Konfiguration mit der vorherigen Version, prüfen Sie Übermittlungsfehler und verfolgen Sie ein bekanntes Worker-Ereignis von der Ausgabe bis zur Erfassung.

Unlesbares Format

Ein neues Protokollformat kann nicht geparst werden.

Problemtyp: Beobachtbarkeitslücke (Bereiche, in denen Sie im Dunkeln tappen, oder Telemetrie, die Risiken birgt.)

Neues Protokollformat unlesbar

Status: Offen

Beschreibung

Ein Logger-Upgrade hat die Formatierung von Datensätzen geändert. Dadurch fehlen eingehenden Protokollen die strukturierten Felder, die für Analyse und Korrelation verwendet werden.

Was passiert ist

Die Quelle sendet weiterhin Datensätze, aber mit dem Upgrade des Loggers beginnen Parsing-Fehler. Die Rohzeilen enthalten einen neuen Umschlag um Felder, die der Parser auf oberster Ebene erwartet. Ereignisse treffen ohne verlässliche Angaben zu Schweregrad, Nachricht oder Anfragekontext ein, was ihren diagnostischen Wert mindert.

So untersuchen Sie den Vorfall

Vergleichen Sie alte und neue Rohdatensätze, aktualisieren Sie den Parsing-Vertrag und verifizieren Sie repräsentative mehrzeilige Ereignisse und Fehler, bevor Sie die Quelle als fehlerfrei einstufen.

Blinder Fleck

Für eine wichtige Route oder einen wichtigen Auftrag gibt es keine Telemetrie.

Problemtyp: Beobachtbarkeitslücke (Bereiche, in denen Sie im Dunkeln tappen, oder Telemetrie, die Risiken birgt.)

Zahlungsendpunkt protokolliert nichts

Status: Offen

Beschreibung

Ein neuer Zahlungsendpunkt verarbeitet Anfragen, ohne Anwendungs-Telemetrie zu erzeugen. Dadurch lassen sich Fehler und unvollständige Vorgänge nur schwer untersuchen.

Was passiert ist

Ingress-Datensätze zeigen, dass Anfragen den Endpunkt erreichen, aber im Protokollstrom erscheint keine passende Anwendungsstartmeldung, kein Ergebnis und keine Anfrage-ID. Andere Zahlungsrouten geben diese Ereignisse weiterhin aus. Wegen der fehlenden Abdeckung lässt sich eine Anfrage nicht durch Validierung, Anbieteraufrufe und Persistierung verfolgen.

So untersuchen Sie den Vorfall

Verfolgen Sie die Protokollierungs-Middleware der Route, fügen Sie strukturierte Ergebnisereignisse mit Korrelations-IDs hinzu und verifizieren Sie die Spur, ohne Zahlungsdaten oder sensible Nutzdaten zu protokollieren.

Zeitabweichung

Zeitstempel weichen zwischen Quellen voneinander ab.

Problemtyp: Beobachtbarkeitslücke (Bereiche, in denen Sie im Dunkeln tappen, oder Telemetrie, die Risiken birgt.)

Host 4 Minuten zurück

Status: Offen

Beschreibung Ein Host versieht Ereignisse mit früheren Zeitstempeln als seine Peers, sodass eine einzelne Anfrage über mehrere Dienste hinweg scheinbar in der falschen Reihenfolge ausgeführt wird.

Was passiert ist

Ereignisse des Hosts liegen vier Minuten hinter den passenden Anfrage-IDs aus anderen Quellen zurück. Die Eingangszeiten liegen weiterhin nah beieinander, die Abweichung liegt also in der aufgezeichneten Ereigniszeit und nicht in einer Transportverzögerung. Die Zeitabweichung verzerrt Zeitachsen und kann Analysen zu Latenz oder Reihenfolge in die Irre führen.

So untersuchen Sie das Problem

Prüfen Sie die Zeitsynchronisierung des Hosts und die Serialisierung der Zeitstempel, korrigieren Sie die Uhr und vergleichen Sie korrelierte Ereignisse erneut, bevor Sie sich auf dienstübergreifende Zeitangaben verlassen.

Beispiele aus dem Sazabi Detection Catalog. Einige Signale sind noch in Arbeit.

Funktioniert mit Ihrem Stack

Alle Integrationen durchsuchen

Chat-Anbieter (3 Integrationen)

• Slack
• Microsoft Teams
• Discord

Git-Anbieter (2 Integrationen)

• GitHub
• Bitbucket

Issue-Tracker und Bereitschaftsdienste (6 Integrationen)

• Linear
• Atlassian
• PagerDuty
• incident.io
• Rootly
• VictorOps

Protokollquellen (73 Integrationen)

• AWS
• Vercel
• Supabase
• Cloudflare
• OpenTelemetry
• Fluent Bit
• GitHub
• Linear
• Webhooks
• Cursor
• GitHub Copilot
• Factory Droid
• OpenHands
• OpenClaw
• Hermes Agent
• Claude Agent SDK
• Google Cloud
• Railway
• Render
• Fly.io
• Netlify
• DigitalOcean
• Porter
• Modal
• Northflank
• Neon
• Convex
• Inngest
• Trigger.dev
• Temporal
• Mastra
• LangChain
• E2B
• Daytona
• OpenRouter
• Datadog
• Sentry
• PostHog
• Prometheus
• Elastic Cloud
• SigNoz
• Vector
• Respan
• New Relic
• evlog
• Plain
• Shopify
• Okta
• Auth0
• WorkOS
• SentinelOne
• Palo Alto Networks
• Zscaler
• HashiCorp Vault
• Jamf Pro
• osquery
• Linux auditd
• Stripe
• Claude Code
• Codex
• Devin
• Doppler
• Gemini
• Grafana Alloy
• oh-my-pi
• Sazabi Browser SDK
• Tailscale
• Unkey
• Jenkins
• Buildkite
• RunsOn
• WarpBuild
• Sazabi React Native SDK

Infrastruktur-Tools (17 Integrationen)

• AWS
• Google Cloud
• Vercel
• Cloudflare
• Kubernetes
• Terraform
• Railway
• Render
• Fly.io
• Netlify
• DigitalOcean
• Porter
• Argo CD
• Azure
• Heroku
• RunPod
• Tailscale

Datenbank-Tools (12 Integrationen)

• Supabase
• Neon
• Postgres
• MySQL
• Redis
• ClickHouse
• Convex
• PlanetScale
• Airbyte
• Aiven
• MongoDB Atlas
• MongoDB Shell

KI- und Workflow-Tools (32 Integrationen)

• Codex
• Cursor
• Gemini
• OpenCode
• Temporal
• Inngest
• Claude Agent
• Warp Oz
• Capy
• Tembo
• Hoplite
• Replicas
• Composio
• Exa
• The Context Company
• RentAHuman
• Cekura
• Langfuse
• Braintrust
• Respan
• Tines
• DeepWiki
• Context.dev
• AgentCat
• CodeRabbit
• Dagster
• DBOS Cloud
• Deepsec
• Devin
• ElevenLabs
• LangSmith
• Rivet

Team- und Betriebs-Tools (43 Integrationen)

• Notion
• Google Drive
• Grafana
• Attio
• 1Password
• Intercom
• Axiom
• Honeycomb
• Better Stack
• Pydantic Logfire
• down.guide
• Pylon
• Clay
• Calendly
• Circleback
• Granola
• Happenstance
• Superhuman
• Mercury
• X
• Wiz
• Vanta
• Drata
• Semgrep
• Socket
• GitGuardian
• Google Security Operations
• VirusTotal
• Have I Been Pwned
• cve.now
• Clerk
• Resend
• Autumn
• Arize
• Checkly
• DoorDash
• Graphite
• GrowthBook
• Herd
• Mobbin
• Secureframe
• Stream
• Twilio

Fallstudien

Fallstudien lesen

Weave

Wie Weave durch den Ersatz manueller Erkennung durch Sazabi jede Woche mehr als 20 Engineering-Stunden zurückgewinnt

Sazabi hat aus blinden Flecken Probleme gemacht, die wir erkennen und beheben, bevor Kunden sie überhaupt bemerken. Das Nächstbeste, nachdem man ein Problem vollständig verhindert hat, ist, sofort davon zu erfahren – und genau das ermöglicht uns Sazabi.

Andrew Churchill, Mitgründer und CTO bei Weave

• 8,5 Min.: Zeit bis zur Ermittlung der Ursache eines Produktionsproblems
• 9 Min.: Einrichtungszeit

Fallstudie lesen

Mastra

Wie Mastra 45-minütige Untersuchungen durch Sazabi-Warnmeldungen zur Fehlerursache ersetzt

Sazabi verschaffte uns die nötige Transparenz in der Produktion für den Launch, ohne dass wir unser übliches Observability-Setup aufbauen mussten. Jetzt ist es ein Sicherheitsnetz, dem wir bei jedem Deployment vertrauen.

Abhi Aiyer, Mitgründer und CTO bei Mastra

• 45 Min.: Dauer einer manuellen Untersuchung vor Sazabi
• 150 Probleme: In zwei Wochen erkannte Produktionsprobleme

Fallstudie lesen

XMTP Labs

Wie XMTP Labs mit Sazabi die Fehlererkennung von Tagen auf Minuten verkürzte

Seit Sazabi Teil unseres Observability-Stacks ist, finden wir die Ursachen viel schneller als mit allen bisherigen Ansätzen.

Nick Molnar, CTO bei XMTP Labs

• 5 Min.: Zeit bis zur Meldung eines größeren Vorfalls
• 20 Min.: Zeit bis zur Bereitstellung einer Korrektur für ein kritisches Problem

Fallstudie lesen

Aus unserem Blog

• Sazabi BYOC: Sazabi in Ihrer eigenen Cloud ausführen: Mit Sazabi BYOC läuft der Teil von Sazabi, der Ihre Logs empfängt, verarbeitet und speichert, in Ihrem eigenen Cloud-Konto, und Sazabi betreibt ihn.
• cve.now: Ein kostenloser Feed mit Sicherheitslücken für Agents: cve.now ist ein kostenloser Feed mit CVEs und Sicherheitshinweisen für Agents und die Teams, die sie einsetzen. Keine Anmeldung, Registrierung oder API-Schlüssel erforderlich.
• Sazabi 1.0 und allgemeine Verfügbarkeit angekündigt: Sazabi 1.0 ist allgemein verfügbar – mit zwei neuen Funktionen, Dashboards und Log Search, sowie einer vollständig selbstständigen Registrierung in weniger als zehn Minuten.

Alle Artikel ansehen

Ein anderer Ansatz für Observability und Sicherheit

01 Alles ist ein Log

Metriken, Traces, Anwendungsereignisse, Agent-Aktionen. Sie alle beschreiben, was passiert ist. Logs bieten Menschen und Agents eine gemeinsame Grundlage, um ein System zu verstehen.

02 Logs ermöglichen Anomalieerkennung

Sie sollten nicht jeden Ausfall vorhersagen müssen, um ihn zu erkennen. Eine Grundlage aus Logs ermöglicht es Sazabi, Veränderungen im Verhalten Ihres Systems zu entdecken und zu untersuchen, was passiert ist.

03 Für eine KI-native Welt entwickelt

KI verändert, wie Software entwickelt und betrieben wird. Sazabi ermöglicht Menschen und Agents den gemeinsamen Zugriff auf die Belege und Tools, die sie zum Handeln benötigen.

Was Kunden sagen

In den ersten zwei Tagen hat Sazabi etwa 8 Probleme erkannt, die uns sonst entgangen wären – sogar mit Sentry.

Bence R., Hoplite

Leben in der Zukunft: Sazabi öffnet den PR, Cursor bewertet das Risiko und genehmigt ihn, CI ist komplett grün.

Evan, AGREE

Nicht jede Warnmeldung hat hohe Priorität, aber jede ist umsetzbar. Die Qualität beeindruckt mich sehr.

Yash N., Sandstone

Einige der von Sazabi gemeldeten Probleme lassen mich 🤯 staunen – auf sehr hilfreiche Weise. Das wird immer wichtiger, je mehr unsere Microservices wachsen.

Nanda G., Taiga

Die Slack-Warnmeldungen sind so gut, dass ich das Dashboard gar nicht öffnen muss. Ein Coding-Agent behebt Fehler, sobald sie auftreten.

Charlie L., Autumn

Sazabi ist das Rückgrat unseres Bereitschaftsdienstes. Und mit den neuen Sicherheitswarnmeldungen können wir in Echtzeit in Panik geraten.

Ed P., WAJO

Bereit für den Unternehmenseinsatz

Bringen Sie Ihre eigene Cloud mit

Führen Sie die Protokollaufnahme, -verarbeitung und -speicherung in Ihrem eigenen AWS-Konto aus. Sazabi betreibt die Bereitstellung.

• Speicher, über den Ihre Organisation verfügt
• Ihre Aufbewahrungsrichtlinie
• Zugriff, den Sie widerrufen können

Ankündigung zu BYOC lesen

Compliance

Sicherheitsstandards und Datenschutzverpflichtungen zur Unterstützung der Prüfung durch Ihr Team.

• SOC 2
• SOC 1
• ISO 27017
• ISO 27001
• GDPR

Trust Center besuchen

Zugriff und Sicherheit

Verbinden Sie Ihren Identitätsanbieter und steuern Sie den Zugriff in Ihrer gesamten Organisation.

• SSO mit SAML / OIDC
• SCIM-Bereitstellung
• Rollenbasierte Berechtigungen
• Eingeschränkter Projektzugriff
• Zwei-Faktor-Authentifizierung

Zugriffskontrollen ansehen

FAQ

Was ist Sazabi?

Sazabi ist eine KI-native Observability- und Sicherheitsplattform für Engineering-Teams und Coding-Agents. Sie liest Ihre Produktions-Logs zusammen mit Ihrem Code, erkennt relevante Probleme, untersucht jedes bis zu seiner Ursache und sendet die Ergebnisse an die Tools, die Ihr Team bereits verwendet.

Muss ich Monitore oder Alarmregeln erstellen?

Nein. Sazabi überwacht Ihre Logs auf Veränderungen, die genauer untersucht werden sollten, etwa ein Ereignis, das plötzlich ausbleibt, ein Schritt, der unbemerkt fehlschlägt, oder eine Latenz, die nach einem Deployment sprunghaft ansteigt. Der Agent untersucht diese Signale, bestätigt, dass sie tatsächlich Auswirkungen haben, und erstellt erst dann ein Issue – ganz ohne Monitore, Schwellenwerte oder Alarmregeln, die gepflegt werden müssen.

Mit welchen Logs und Tools verbindet sich Sazabi?

Sende Logs aus Quellen wie Datadog, PostHog, Sentry, Google Cloud, Supabase und Cloudflare und verbinde deinen Code aus GitHub, damit Sazabi Probleme bis zum zugrunde liegenden Commit und der betreffenden Datei zurückverfolgen kann. Probleme erreichen dein Team über Slack, Microsoft Teams, E-Mail oder SMS.

Wie arbeitet Sazabi mit Coding-Agenten zusammen?

Zu jedem Problem erhältst du die Ursache und einen Behebungsplan, den du direkt an einen Coding-Agenten wie Claude Code, Codex oder Cursor weitergeben kannst. Agenten können Sazabi während ihrer Arbeit auch über die CLI und MCP zu deinen Logs befragen.

Können meine Logs in meiner eigenen Cloud bleiben?

Ja. Mit Sazabi BYOC laufen Log-Eingang, Verarbeitung und Speicherung in deinem eigenen AWS-Konto. Deine Logs bleiben in einem Speicher, der deiner Organisation gehört, während Sazabi die Bereitstellung betreibt. Abfrageergebnisse und Log-Auszüge können Sazabi und Modellanbietern weiterhin zugänglich sein.

Wie viel kostet Sazabi?

Hobby kostet $50, Startup $200 und Growth $1,000 pro 30-Tage-Zyklus. Bei jedem Tarif ist ein bestimmtes Nutzungsvolumen enthalten. Für Enterprise gelten individuelle Preise und Konditionen. Auf der Preisseite erfährst du, was die einzelnen Tarife beinhalten.

Wie kann ich loslegen?

Führe npx @sazabi/cli start in deinem Terminal aus, um Sazabi einzurichten, oder folge der Kurzanleitung in der Dokumentation.

Kanonische URL

https://www.sazabi.com