Automatisch aus Monitor-Alerts
Stellen Sie einen Service so ein, dass er automatisch einen Incident eröffnet, wenn ein verknüpfter HTTP-, Cron- oder Browser-Monitor ausfällt. Niemand muss mitten in der Nacht auf „Incident ausrufen" klicken.
Incident-Management
Eine Timeline vom
Eine Timeline vom
Alert bis gelöst.
Incidents ausrufen, verfolgen und schließen, ohne die Plattform zu verlassen. Schweregrade, strukturierte Updates und Verknüpfung mit betroffenen Services. HTTP-, Cron- und Browser-Monitore, die mit einem Service verknüpft sind, können Incidents automatisch eröffnen und bei Wiederherstellung lösen.
Free tier included
No credit card
2-minute setup
Eine strukturierte Reaktion, kein Chat-Thread.
Jeder Incident hat einen Schweregrad, einen Status, eine Timeline mit Updates und den Service und die Monitore, die er betrifft. Die Eskalationsrichtlinie alarmiert beim Eröffnen Ihren Ingenieur in Bereitschaft; wenn Sie ihn veröffentlichen, sehen Ihre Nutzer ihn auf der Statusseite; Ihr Team postet das nächste Update, alles an einem Ort.
Schweregrade mit Bedeutung
Incidents sind minor, major oder critical. Critical- und Major-Incidents alarmieren mit hoher Dringlichkeit, Minor-Incidents mit niedriger. P1 bis P4 werden nicht verwendet.
Timeline mit Zeitstempeln
Posten Sie Updates durch Investigating, Identified, Monitoring und Resolved. Jedes Update erhält einen Zeitstempel und bleibt am Incident.
Veröffentlichung auf der Statusseite inklusive
Veröffentlichen Sie einen Incident auf Ihrer öffentlichen Statusseite, oder lassen Sie einen Service seine automatischen Incidents auf einer Seite veröffentlichen, die Sie über die API festlegen. Komponenten der Statusseite folgen ihren Monitoren, nicht dem Incident.
Bestätigungen nachverfolgen
Der Incident hält fest, ob er bestätigt oder gelöst wurde, wer ihn bestätigt hat und wann. Eine Bestätigung stoppt die Eskalationsrichtlinie.
Eine Timeline an jedem Incident
Posten Sie Updates mit Zeitstempel durch Investigating, Identified, Monitoring und Resolved. Strukturierte Postmortem-Dokumente gibt es noch nicht.
Vom Monitor zum Incident, automatisch
Kein manueller Schritt
Kein manueller Schritt
zum Ausrufen.
Fällt ein mit einem Service verknüpfter Monitor aus, kann Site Qwality einen Incident mit dem Standard-Schweregrad des Service eröffnen, den Monitor verknüpfen, die Person in Bereitschaft über die Eskalationsrichtlinie des Service alarmieren und ihn auf der gewählten Statusseite veröffentlichen, bevor jemand ein Wort getippt hat. Sie ergänzen Kontext, statt den Ablauf anzustoßen.
- Der Ausfall eines verknüpften Monitors eröffnet den Incident automatisch
- Schweregrad und Eskalationsrichtlinie kommen vom Service
- Automatisch gelöst, wenn alle verknüpften Monitore wieder gesund sind
Checkout API errors IdentifiedLIVE
SEVERITYCritical
UPDATES POSTED3
TIME TO IDENTIFY11m
checkout-api98ms
payments-api88ms
web-app42ms
auth12ms
status-page8ms
Für den ganzen Lebenszyklus
Den Kreis schließen
Den Kreis schließen
mit einer Timeline.
Nach der Lösung bleibt die Timeline des Incidents erhalten: was Sie gepostet haben und wann. Strukturierte Postmortem-Dokumente gibt es noch nicht.
- Updates mit Zeitstempel von Investigating bis Resolved
- Schweregrad minor, major oder critical
- Updates, die über die Statusseite gepostet werden, gehen per E-Mail an deren bestätigte Abonnenten
post an incident update via API$ curl -X POST https://api.siteqwality.com/incident/$INCIDENT_ID/update \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"status":"monitoring","message":"Rolled back CDN config. Watching error rates."}'
# Update added to the incident timeline
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"status":"monitoring","message":"Rolled back CDN config. Watching error rates."}'
# Update added to the incident timeline
30s
kürzestes Prüfintervall, das die Zeit bis zum Incident begrenzt
3
Schweregrade: minor, major und critical
4
Status: investigating, identified, monitoring und resolved
$0
Incidents in jedem Plan; der kostenlose Tarif enthält 1 Person in Rufbereitschaft
FAQ
Ja, für HTTP-, Cron- und Browser-Monitore, die mit einem Service verknüpft sind. Stellen Sie den Service auf automatische Incident-Erstellung, dann eröffnet Site Qwality einen Incident, wenn ein verknüpfter Monitor ausfällt, und löst ihn, wenn alle verknüpften Monitore wieder gesund sind. Im manuellen Modus rufen Sie Incidents selbst aus.
Incidents sind minor, major oder critical. Der Schweregrad bestimmt die Dringlichkeit, mit der die Eskalationsrichtlinie arbeitet: critical und major bedeuten hohe Dringlichkeit, minor niedrige, und die Benachrichtigungsregeln jeder Person entscheiden, wie sie kontaktiert wird. P1 bis P4 werden nicht verwendet.
Ein automatisch gelöster Incident postet ein Resolved-Update auf den Statusseiten, auf denen er veröffentlicht wurde. Komponenten der Statusseite folgen ihren Monitoren und kehren zu „Operational" zurück, wenn sich die Monitore erholen. Abonnenten erhalten eine E-Mail, wenn Sie ein Update über die Statusseite posten, nicht wenn sich ein Incident von selbst löst.
Jedes Update, das Sie posten (Investigating, Identified, Monitoring, Resolved), wird mit Zeitstempel und Ihrer Nachricht festgehalten. Die Timeline ist für Ihr Team sichtbar und, wenn veröffentlicht, für die Besucher Ihrer Statusseite.
Einen Dokumenttyp für Postmortems gibt es heute nicht. Halten Sie den Verlauf in der Incident-Timeline fest.
Related features
Kostenlos starten. Keine Kreditkarte.
Uptime, Cron, Synthetic, Logs, RUM, Incidents und Statusseiten. Kostenlose Stufe bei jedem Produkt.