PagerDuty Paige ist live: KI-Agenten reparieren Störungen – aber nicht ohne Grenzen

PagerDuty führt den SRE-Agenten Paige als Teil der am 3. November 2026 allgemein verfügbaren PD Reliability Platform ein. Die Plattform verbindet Signal Intelligence, Incident Management und Automation; Paige soll aus Alarmdaten, Runbooks und früheren Vorfällen den nächsten sinnvollen Schritt vorbereiten. Der Hersteller beschreibt eine gemeinsame Arbeit von menschlichen Bereitschaftsteams und Agenten in Slack oder Microsoft Teams.

Der interessante Fortschritt liegt weniger im Chatfenster als in der Verknüpfung von Vorfallskontext und Handlungswegen. Ein Agent, der ein plausibles Problem benennt, hat noch keine Ursache nachgewiesen. Erst wenn er Alarm, Zeitpunkt der Änderung, betroffenen Dienst und erlaubte Abhilfe in derselben nachvollziehbaren Kette zeigen kann, wird aus einer Textantwort eine operative Entscheidungshilfe.

Die offizielle Markteinführung bezeichnet Paige und die PD Reliability Platform am 3. November als allgemein verfügbar. Das schließt aber nicht jede in der Produktgeschichte gezeigte Fähigkeit ein: Automatisches Lösen gut verstandener Vorfälle ohne Wecken des Bereitschaftsdiensts markiert PagerDuty ausdrücklich als «coming soon».

Auch Topology, Deep Investigation und SRE Workbench gehören zunächst in PD Labs. Das sind Experimente, deren Zugang und Eigenschaften gesondert zu prüfen sind. Die Produktbeschreibung zeigt Deep Investigation als paralleles Testen von Hypothesen samt Begründung, was ausgeschlossen wurde. Redaktionell ist es unzulässig, solche Preview-Bausteine als bereits im allgemein verfügbaren Paige-Paket enthalten zu verkaufen.

Paige kann nach Herstellerbeschreibung bekannte Runbooks ausführen und eine genehmigte Auflösung durchführen, etwa einen Service-Neustart. Dabei bleibt die wichtige Entscheidung beim verantwortlichen Menschen: Eingreifen oder weiter untersuchen, den Fix freigeben oder einen anderen Pfad wählen. Der Rechteumfang soll von der Organisation gesteuert werden.

Die AgentenCode-Schlussfolgerung: Ein Approval-Button ist nur dann ausreichend, wenn er an den konkreten Runbook-Schritt, die betroffene Umgebung und eine zeitlich begrenzte Identität gebunden ist. Sonst kann die Freigabe zu breit sein. Ein automatisch erstellter Incident-Report und gespeicherte Erfahrungen ersetzen keine Prüfung, ob die Abhilfe tatsächlich funktionierte oder Nebenwirkungen hatte.

Mit Honeycombs ebenfalls am 3. November vorgestellten Personal und Team Agents verfolgt ein zweiter Anbieter einen anderen Einstieg: Honeycomb setzt auf hochdimensionale Traces und fortlaufende Ziele wie Release-Überwachung; diese neuen Agenten sind noch Early Access. PagerDuty startet vom Incident- und Bereitschaftsworkflow, inklusive Eskalationen, Teamkanälen und Runbooks – Paige selbst ist GA.

Daraus folgt kein pauschaler Sieger. Ein Team mit unzureichenden Traces braucht bessere Telemetrie, bevor es Root-Cause-Vorschläge automatisiert. Ein Team mit belastbaren Traces, aber schlechter Eskalation und Runbook-Kontrolle muss eher Freigaben und Zuständigkeiten verbessern. Die Produkte adressieren überlappende, aber nicht identische Probleme; Preise und echte Wirksamkeit müssen beide Anbieter in einem kundeneigenen Test belegen.

Unsere eigenständige Matrix bewertet fünf Situationen nach technischer Reife, möglichem Eingriff und menschlichem Entscheidungspunkt. Der Befund ist quellenbasiert, aber nicht durch einen AgentenCode-Produkttest bestätigt. Gerade der Status von PD-Labs-Funktionen muss im Beschaffungsprozess sichtbar bleiben.

Die wichtigste Priorität gehört dem Übergang vom Lesen zum Schreiben. Ein automatischer Alarmtext ist reversibel; ein Kubernetes-Restart oder eine geänderte Cloud-Konfiguration möglicherweise nicht. Wer Verantwortlichkeiten und Rollback nicht festlegt, sollte das Schreibrecht selbst bei guter Diagnose vorerst deaktiviert lassen.

Ein reproduzierbarer Pilot beginnt mit einem künstlich ausgelösten Fehler in einer nicht produktiven Umgebung. Die Testleitung dokumentiert Alarmzeit, zugeordnete Services, Paige-Empfehlung, tatsächlich sichtbare Evidenz, gewählten Runbook-Schritt und die Identität des genehmigenden Menschen. Danach wird überprüft, ob die Telemetrie den erfolgreichen oder misslungenen Fix tatsächlich zeigt.

Als Prüfgrößen eignen sich Zeit bis zum brauchbaren Hinweis, Zahl falscher oder nicht belegter Hypothesen, Wiederanlaufzeit, Rate unnötiger Seitenalarmierungen und Vollständigkeit des Postmortems. Das sind vorgeschlagene Abnahmekriterien, keine von AgentenCode gemessenen PagerDuty-Kennzahlen. Marketingangaben zu Benchmarks, Zeitgewinn oder vermeidbaren Incidents dürfen damit nicht verwechselt werden.

Paige ist ein bemerkenswerter Schritt von der Incident-Zusammenfassung hin zu einer kontrollierten operativen Assistenz. Die allgemeine Verfügbarkeit ist belegt; selbständige Reparaturen ohne Freigabe und die tieferen PD-Labs-Funktionen sind hingegen unterschiedlich reif.

Für Unternehmen ist das richtige Ziel nicht maximal viele autonome Knöpfe. Es ist eine überprüfbare Grenze zwischen Diagnose, Freigabe, Ausführung und nachträglicher Kontrolle. Genau an dieser Grenze sollte sich Paige in echten Piloten beweisen – statt allein an einer versprochenen Reduzierung der nächtlichen Bereitschaftslast.