Olay Yaşam Döngüsü

Bir olayın açılışından kapanışına kadar geçtiği tüm durumlar, open, acknowledged, resolved, çok bölgeli doğrulama ve zincir bastırma dalları dahil.

Bir olay. UptimeWarden'ın gerçek dünyadaki bir aksaklığa dair tuttuğu kayıt, ilk hata sinyalinden olayı kapattığınız ana kadar belirli durumlar arasında ilerler. Her geçişi ya bir kullanıcı aksiyonu ya da sistemin bir olaya verdiği yanıt tetikler. Bu sayfa tüm durumları ve geçişin nedenini tek tek açıklar.

Tüm durumlar bir bakışta

Durum	Anlamı
`open`	Yeni açıldı, üstlenilmesi bekleniyor
`acknowledged`	Bir nöbetçi olayı üstlendi
`investigating`	Aktif triyaj sürüyor
`monitoring`	Düzeltme uygulandı, gözlemleniyor
`resolved`	Servis toparlandı veya manuel kapatıldı
`pending_verification`	Çok bölgeli doğrulama bekleniyor (bildirim ertelendi)
`rejected`	Çoklu konum mutabakatı sağlanamadı (yanlış alarm)
`suppressed_cascade`	Üst kaynak bağımlılık zaten arızalı, bildirim, eskalasyon ve durum sayfası girişi yok

Durum diyagramı

stateDiagram-v2
    [*] --> PendingVerification: Monitör DOWN<br/>(doğrulama uygun)
    [*] --> Open: Monitör DOWN<br/>(doğrulama yok)
    [*] --> SuppressedCascade: Üst olay<br/>zincir penceresi açık
    PendingVerification --> Open: Mutabakat<br/>sağlandı
    PendingVerification --> Rejected: Mutabakat<br/>sağlanamadı
    Open --> Acknowledged: Kullanıcı "Acknowledge"<br/>(e-posta linki / panel)
    Open --> Resolved: Monitör toparlandı<br/>(otomatik)
    Acknowledged --> Resolved: Monitör toparlandı<br/>VEYA kullanıcı "Resolve"
    SuppressedCascade --> Open: Yükseltme taraması<br/>(planlanıyor / yakında)
    SuppressedCascade --> Resolved: Toparlanma
    Resolved --> [*]: Postmortem<br/>otomatik taslak
    Rejected --> [*]
    Acknowledged --> Open: Toparlandı, sonra<br/>tekrar başarısız

Kim neyi tetikler?

Geçiş	Tetikleyici	Otomatik mi?	Etkisi
`→ pending_verification`	Hata sinyali, doğrulama uygun	evet	Bildirim ertelenir
`pending_verification → open`	Çok bölgeli mutabakat sağlandı	evet	Bildirimler başlar
`pending_verification → rejected`	Mutabakat sağlanamadı	evet	Hiçbir bildirim gitmez
`→ suppressed_cascade`	60 saniyelik pencere içinde üst olay	evet	Bildirim ve eskalasyon yok
`→ open`	Hata sinyali (doğrulama kapalı)	evet	Bildirimler başlar
`open → acknowledged`	Nöbetçi kullanıcı	manuel	Triyaj başlar, eskalasyon durur
`open → resolved`	Monitör toparlandı	evet	Toparlanma bildirimi + postmortem taslağı
`acknowledged → resolved`	Toparlanma veya kullanıcı	her ikisi	Postmortem taslağı
`suppressed_cascade → open`	Üst olay çözüldü, monitör hâlâ down (planlanıyor / yakında)	-	Bildirimler başlar
`acknowledged → open`	60 saniyelik tekilleştirme penceresinden sonra tekrar başarısız	evet	Triyaja dönülür

Zincir bastırma dalı

Üst kaynak bağımlılık (örneğin bir veritabanı) zaten açık bir olaya sahipse ve zincir penceresi (varsayılan 60 saniye) hâlâ açıksa:

Sistem yeni olayı açmadan önce bir zincir kontrolü yapar
Yeni olay suppressed_cascade durumuyla kaydedilir ve üst olaya bağlanır
Bildirim, eskalasyon ve durum sayfası girişi tamamen atlanır
Planlanıyor (yakında): üst olay çözüldüğünde bir yükseltme taraması çalışacak; hâlâ başarısız olan bastırılmış olaylar open durumuna geçecek ve normal bildirim akışı devreye girecek

Olay detay sayfası, üst olaya yönlendiren bir banner gösterir. Listede görmek için "Bastırılanları dahil et" anahtarını açın.

Zincir Bastırma opt-in'dir; ekip yöneticiniz yönetim panelinden açar. Detaylar: Olaylar.

Çok bölgeli doğrulama

Bir monitör birden fazla bölgeden çalışıyorsa (örneğin Sweden Central + East Asia + Phoenix), tek bölgeden gelen hata sinyali olayı hemen açmaz:

Olay pending_verification durumunda kaydedilir.
Diğer bölgelerden aynı kontrolü çalıştırmaları istenir.
Mutabakat sağlanırsa → open (bildirimler başlar).
Sağlanamazsa → rejected (bildirim gitmez).

Detaylar: Çoklu Konum Mutabakatı.

Üstlenme nasıl çalışır?

Üç giriş noktası vardır ve hepsi aynı durum geçişini üretir:

E-postadaki "Acknowledge" linki, tek tıkla; giriş gerekmez (link imzalı ve zaman sınırlıdır)
Paneldeki olay detay sayfası, "Acknowledge" düğmesi
Mobil push aksiyonu, bildirimi kaydırın ve "Ack"e dokunun

İlk üstlenme kazanır; sonraki tıklamalar etkisizdir, ancak kimin üstlendiği her zaman kayda geçer.

Kapatma nasıl çalışır?

İki yol vardır:

Otomatik, monitör toparlanma sinyali gönderdiğinde olay kendi kendine kapanır. Varsayılan ve önerilen yoldur.
Manuel, monitör yanlış alarm üretiyorsa olayı bilinçli olarak "kapandı" şeklinde işaretlemek.

Manuel kapatılan bir monitör hâlâ başarısız sinyal göndermeye devam ediyorsa, 60 saniyelik tekilleştirme penceresi geçtikten sonra yeni bir olay açılır.

Webhook bildirimleri

Bir monitör durum değiştirdiğinde webhook'lar bir alarm yükü gönderir. Yükteki incident.type alanı, tetiklenen alarm türünü taşır:

down, monitör arızalandı
recovery, monitör toparlandı
ssl_warning. SSL sertifikası süre sonuna yaklaşıyor
high_response, yanıt süresi art arda N kontrolde eşiğin üzerinde (varsayılan 3)

Her webhook, etkinleştirdiğiniz alarm türlerine abone olur (varsayılan: down, recovery, ssl_warning, high_response). Yükler HMAC-SHA256 ile imzalanır.

Bir olay resolved durumuna geçtiğinde, sistem postmortem taslağını otomatik oluşturur; bu dahili bir adımdır ve abone olabileceğiniz bir webhook değildir.

Webhook güvenliği için: Webhook Güvenliği.

Çözüm metrikleri

MTTR (ortalama çözüm süresi): çözülen olaylar üzerinden resolvedAt − createdAt ortalaması. Monitör başına ve olaylarınız genelinde ortalama çözüm süresi olarak sunulur.

Olay analitiği paneli. 1/7/30/90 günlük aralıklarda trend grafikleri, çözüm oranı ve MTTR analizi, Free dahil tüm planlarda kullanılabilir.

İlgili konular

Eskalasyon Politikaları: kimse üstlenmediğinde nöbet merdiveni nasıl çıkar
Akıllı Alarm Gruplama: alarm fırtınalarını tek olayda toplama
Çoklu Konum Mutabakatı, pending_verification akışının detayları
Bakım Pencereleri: planlı kesintinin olay defterine düşmemesi