Agentenprofil · SRE & Automatisierung
PagerDuty Paige SRE Agent
Anbieter: PagerDuty
Paige ist der allgemein verfügbare SRE-Agent von PagerDuty für Incident-Triage, Diagnose und kontrollierte Remediation. Die GA des Produkts bedeutet nicht, dass jede autonome Funktion schon verfügbar ist.
Eigene quellenbasierte Entscheidungsgrafik
PagerDuty Paige SRE Agent — Entscheidung und Freigaben
Produktstatus, Quellenlage, Berechtigungen und Prüfschritte auf einen Blick.
Überblick & Direktantwort
Kurzantwort: PagerDuty Paige SRE Agent
Paige ist ein spezialisierter KI-Agent für Site Reliability Engineering (SRE) innerhalb der PagerDuty-Plattform. Er soll operative Signale, bekannte Incidents, Diagnosedaten und Runbooks zusammenführen und Betriebsteams bei der Eingrenzung von Störungen unterstützen. PagerDuty meldete die allgemeine Verfügbarkeit am 3. November 2026. Wir bewerten hier öffentlich dokumentierte Funktionen; wir haben Paige nicht in einem Kundenkonto ausgeführt.
Die zentrale Kauf- und Einsatzfrage lautet nicht, ob Paige als KI-Agent bezeichnet wird, sondern welchen Handlungsspielraum das konkrete PagerDuty-Konto zulässt. Ein analysierter Fehler, eine empfohlene Änderung, eine nach Freigabe ausgeführte Aktion und eigenständige Remediation sind unterschiedliche Betriebszustände. Diese Unterscheidung ist für produktive Systeme wichtiger als Marketingbegriffe wie autonom.
Funktionen & Arbeitsweise
PagerDuty beschreibt die Verbindung mit Incident-Signalen, Logs, Runbooks, früheren Störungen und verbundenen Tools. Paige soll Ursachenhypothesen bilden, geeignete Untersuchungen anstoßen, relevante Beteiligte koordinieren und diagnostische Schritte begründen. Die Produktseite nennt Integrationen mit Slack und Microsoft Teams sowie erweiterbare Schnittstellen für Agent Connectors, Tools, Skills und MCP.
Ein konkreter Arbeitsablauf beginnt typischerweise mit einem Alert. Paige sammelt Kontext aus freigegebenen Quellen, zeigt mögliche Ursachen und schlägt ein Runbook vor. Wenn eine Produktionsänderung nötig ist, muss zwischen Empfehlung und Ausführung unterschieden werden. Die neue PD Reliability Console bündelt Incident-Übersichten und Agentenaktivitäten, ihre Nutzbarkeit ist jedoch an das passende Plattformprodukt gebunden.
PagerDuty wirbt mit einer geteilten Incident-Erinnerung, die frühere Lösungen in spätere Untersuchungen einbezieht. Das ist eine Produktangabe, keine unabhängige Messung von Diagnosegenauigkeit oder Zeitersparnis. Teams sollten vorab festlegen, welche Incident-Informationen für dieses Gedächtnis verarbeitet werden dürfen.
Praxis & Einsatzfälle
Ein sinnvoller Pilot konzentriert sich zunächst auf gut beschriebene, wiederkehrende Betriebsfälle: etwa einen Dienst mit etabliertem Alarm, aktuellem Runbook, verlässlicher Telemetrie und klarer Eskalationskette. In diesem Rahmen kann der Agent Vorschläge zur Priorisierung, Kontextsammlung und Fehlerdiagnose liefern, ohne sofort Schreibrechte auf produktive Systeme zu benötigen.
Bei kritischen SEV-1-Vorfällen sollte die Redaktion der Betriebsabläufe unterscheiden, welche Schritte automatisch Informationen lesen dürfen und welche einen menschlichen Incident Commander brauchen. Auch eine technisch plausible Ursache darf bei fehlenden Logs oder unvollständiger Topologie nicht als bewiesen gelten. Für Post-Incident-Arbeit lassen sich Zusammenfassungen und Follow-up-Aufgaben nutzen, sofern sie menschlich geprüft werden.
Die Einsatzentscheidung sollte nach einem begrenzten Test anhand konkreter Kriterien fallen: Nachvollziehbarkeit der Diagnosen, Abdeckung der verbundenen Quellen, Handhabung falscher Hypothesen, Rechte auf Runbooks und reale Anzahl verbrauchter AI Actions. Ohne solche Testdaten veröffentlichen wir keinen Leistungsrang.
Geeignete Aufgaben
- Incidents triagieren
- Runbook-Aktionen prüfen
- Eskalationskontext sammeln
- Post-Incident-Reviews vorbereiten
Verfügbarkeit, Kosten & Grenzen
Die GA bezieht sich auf Paige als Produkt und die neue PD Reliability Platform. Die dokumentierte Virtual-Responder-Einbindung über Incident Workflows wird separat als Early Access beschrieben. Ebenso sind Erweiterungen aus PD Labs und einzelne neu angekündigte autonome Funktionen nicht automatisch Bestandteil jedes allgemein verfügbaren Kontos.
Laut PagerDuty-Dokumentation können bestimmte Paige-Anfragen oder Aktionen jeweils vier AI Actions verbrauchen. Der Umfang der verfügbaren AI Actions, die erforderlichen Lizenzen und zusätzliche Kosten hängen vom gewählten Tarif beziehungsweise Vertrag ab. Wir nennen deshalb keinen pauschalen Monatspreis. Vor Vertragsabschluss sollte ein Team Preise, Nutzungsgrenzen, Oberflächenzugang und Add-ons schriftlich prüfen.
Eine weitere technische Grenze: Die Dokumentation nennt für bestimmte Incident-Felder und Notizen eine Verarbeitung nur der ersten 2.000 Zeichen. Dieser dokumentierte Ausschnitt kann entscheidende Angaben außerhalb des Limits ausblenden. Er darf bei einer Diagnose nicht mit einem vollständigen Incident-Record verwechselt werden.
Zugang am Prüfdatum: Paige GA seit 03.11.2026; Nutzung und Funktionen abhängig von PagerDuty AI, PD Reliability Platform, Plan und Oberfläche.
Datenschutz, Sicherheit & Trust
Produktive Handlungen berühren mehrere Rechteebenen: PagerDuty-Account, Incident-Workflow, angebundene Observability-Dienste, Deployment-Systeme und möglicherweise Runbook-Automation. Die öffentlich beschriebene menschliche Freigabe ist ein sinnvolles Kontrollmuster, ersetzt aber keine Prüfung der tatsächlich konfigurierten IAM-Rollen und Datenzugänge im Kundenkonto.
Als quellenbasierte Mindestkontrollen empfehlen wir getrennte Berechtigungen für Lesen, Diagnose, Ticket-/Pager-Aktionen und produktive Änderung. Für riskante Runbooks sollte eine ausdrückliche Genehmigung mit Zeitstempel, verantwortlicher Person und dokumentiertem Rollback vorliegen. Produktankündigungen belegen keine unabhängige SOC-Prüfung der konkreten Paige-Konfiguration.
Datenschutz, Datenstandort, Aufbewahrung der Incident-Erinnerung und genaue Ausführungskonten sind ohne produktspezifische Vertrags- und Adminbelege offen. AgentenCode trägt dafür keine erfundenen positiven Trust-Signale ein: Unbekannt bedeutet nicht fehlgeschlagen. Die genannten Sicherheitsvorkehrungen sind Prüfungsempfehlungen, keine Zertifizierung.
Vergleich & Entscheidung
Redaktionelle Auswahl: Warum AgentenCode diesen Agenten aufgenommen hat – unsere dokumentierten Kriterien, der Produktstatus und offene Prüfgrenzen.
Paige und AWS DevOps Agent adressieren beide operative Zuverlässigkeit, starten aber aus unterschiedlichen Plattformkontexten. PagerDuty steht stärker für Incident-Orchestrierung, Eskalation und die Verbindung bestehender On-Call-Prozesse; AWS DevOps Agent konzentriert sich in seinen dokumentierten Funktionen auf Cloud- und Infrastrukturuntersuchungen. Die Auswahl hängt von Monitoring-Landschaft, Schreibrechten und Teamprozessen ab.
Honeycomb AI SRE Agents stellen eine weitere Vergleichsachse dar: Dort beginnt die beworbene Analyse stärker bei hochauflösenden Traces und kontinuierlichen Release-Zielen; deren neue Personal und Team Agents sind am Prüfdatum nur Early Access. Ein funktionsübergreifender Qualitätsvergleich wäre erst nach denselben real ausgeführten Testfällen belastbar.
Die redaktionelle Entscheidungsfrage lautet: Ist die primäre Aufgabe Incident-Koordination und zugelassene Remediation, oder fortlaufende Trace-Analyse und Release-Kontrolle? Für Incident-Eskalation mit vorhandener PagerDuty-Nutzung ist Paige der naheliegende Prüfkandidat. Ein allgemeines Best-of-Ranking leiten wir daraus nicht ab.
Vergleichbare Profile: AWS DevOps Agent, Honeycomb AI SRE Agents. Aktuelle Fachanalyse: AgentenCode-News öffnen.
Vertiefende Fachanalyse
AgentenCode betrachtet Paige als Beispiel für einen entscheidenden Governance-Wechsel: KI-SRE geht von Zusammenfassungen zu vorgeschlagenen und potenziell ausgeführten Produktionsaktionen über. Die Trennlinie verläuft zwischen Evidenzbeschaffung, Entscheidungsvorlage, freigegebener Automation und eigenständiger Handlung. Jede Stufe braucht eigene Berechtigungen und nachvollziehbare Kontrollpunkte.
Eine realistische Einführung könnte in drei Phasen erfolgen. Erstens mit Nur-Lese-Zugriff auf abgeschlossene Incidents und Runbooks beginnen und Fehlerhypothesen nachvollziehen. Zweitens genehmigte Schreibaktionen in einer nichtkritischen Umgebung testen. Drittens erst nach dokumentierter Prüfung von Ausfällen, Nebenwirkungen, AI-Actions-Kosten und Rollback selektiv automatisieren.
Die Herstellerangaben zu künftigen autonomen Funktionen und einer angeblich stetig besser werdenden Incident-Erinnerung ersetzen keine belastbaren Betriebsdaten. Noch ungeprüft sind reale Datenzugriffsketten, wirksame Freigaben, regionale Vertragsbedingungen, Latenz und Fehlerraten. Diese Lücken gehören vor Beschaffung in einen Pilotplan, nicht unter eine Marketingüberschrift.
Prüfpunkte vor einer Einführung
- Vor Produktivaktionen Freigaben definieren
- AI-Actions-Verbrauch und Tarif prüfen
- Virtual-Responder-Early-Access abgrenzen
Häufige Fragen
Für eine seriöse Eignungsprüfung ist besonders wichtig, wie sich allgemeine Produktverfügbarkeit zu eingeschränkt verfügbaren Einzelfunktionen verhält. Eine GA-Pressemitteilung wird nicht automatisch zum Beleg für jede geplante Kontrolle, jeden Konnektor oder jedes Pilotfeature.
Die folgenden Antworten fassen den Stand öffentlich zugänglicher PagerDuty-Quellen vom 4. November 2026 zusammen. Sie ersetzen weder eine Kaufprüfung noch einen technischen Sicherheitstest des eigenen Kontos.
Ist PagerDuty Paige bereits verfügbar?
Ja, Paige und die PD Reliability Platform wurden am 3. November 2026 allgemein verfügbar angekündigt. Einzelne Integrationen und Virtual-Responder-Funktionen können dennoch Early Access oder von Kontovoraussetzungen abhängig sein.
Führt Paige Änderungen ohne Freigabe aus?
PagerDuty beschreibt Genehmigungen für Remediation als Standard und konfigurierbare Autonomie für bestimmte Szenarien. Für eigene Produktionssysteme müssen Rollen, Runbooks und Freigaben vorab überprüft werden.
Welche Kosten entstehen?
Ein allgemeiner Festpreis lässt sich aus den geprüften Quellen nicht ableiten. Der Zugang hängt von Plattform, Tarif und AI Actions ab. Die PagerDuty-Dokumentation nennt vier AI Actions für bestimmte Interaktionen.
Primärquellen & Änderungen
Grundlage sind die PagerDuty-Ankündigung vom 3. November 2026, die aktuelle Produktbeschreibung und die offizielle Administrationsdokumentation. Wir unterscheiden ausdrücklich Herstellerangabe, redaktionelle Ableitung und noch nicht unabhängig geprüfte Funktion.
Profil angelegt am 4. November 2026; Quellenbezogene Prüfung, kein eigener Zugriff auf Paige und keine reale Incident-Remediation. Änderungen an Produktstatus, Preisen, KI-Aktionen und Plattformberechtigungen sollten beim Anbieter nachvollzogen werden.
Offizielle Primärquellen
- PagerDuty launch release — https://www.pagerduty.com/newsroom/pagerduty-2026-fall-launch/
- Paige product page — https://www.pagerduty.com/platform/ai-agents/sre/
- PagerDuty SRE Agent documentation — https://docs.pagerduty.com/ai-automation/advance/sre-agent
- Paige Virtual Responder Early Access — https://docs.pagerduty.com/ai-automation/advance/add-paige-as-virtual-responder
- PagerDuty Paige introduction — https://www.pagerduty.com/blog/ai/meet-paige-sre-agent/
Redaktioneller Nachweis: 2026-11-04 · quellenbezogene Prüfung; ohne Praxis-, Sicherheits- oder Datenschutz-Audit.