Webhook Yapılandırma

Bildirimleri istediğiniz HTTP uç noktasına gönderin. Discord, OpsGenie, kendi servisiniz ya da Zapier, imzalı yük ve otomatik yeniden deneme ile.

E-posta insanlar için iyidir. Webhook'lar diğer her şey içindir: olay yönetim aracınız, kendi panoınız, Discord, OpsGenie, PagerDuty, Zapier, n8n veya geçen çeyrek yazdığınız o iç Slack botu. JSON kabul eden her HTTP uç noktası UptimeWarden için bir bildirim hedefi olabilir.

Bu sayfa kurulumu, yük yapısını, yeniden deneme davranışını ve güvenliği anlatır. İmza doğrulama ayrıntıları için önce Webhook Güvenliği sayfasını okuyun, bu rehberin alıcı tarafındaki karşılığıdır.

Kurulum

Settings → Notifications → Webhooks → New Webhook:

  1. İsim, iç etiket (OpsGenie alarmları, Discord #ops kanalı, İç olay botu).
  2. URL, hedef adres. HTTPS kesinlikle önerilir; özel ağ aralıklarına yönelen istekleri varsayılan olarak engelliyoruz.
  3. Method, GET, POST (varsayılan), PUT, PATCH veya DELETE.
  4. Auth method, none, bearer, basic veya custom (özel başlıklar). HMAC imzalama ayrı, bağımsız bir özelliktir (HMAC gizli anahtarı alanı) ve seçtiğiniz auth yönteminden bağımsız olarak çalışır.
  5. Headers. JSON biçiminde özel başlıklar: {"X-API-Key": "…", "X-Tenant-ID": "acme"}.
  6. Alert types, bu webhook'u hangi alarm türlerinin tetikleyeceği (down, recovery, ssl, high_response vb.).
  7. Monitor types, monitör türüne göre kısıtlama (yalnızca HTTP, tüm türler vb.).
  8. Sessiz saatler, yalnızca kritik alarmların gönderildiği isteğe bağlı zaman aralığı.
  9. HMAC gizli anahtarı, bkz. Webhook Güvenliği.

Yapılandırmayı kaydedin, ardından tetiklemesini istediğiniz monitörlere bağlayın. Tek bir webhook yapılandırması birçok monitöre hizmet edebilir, OpsGenie alarmları'nı bir kez tanımlayın ve filonun tamamında yeniden kullanın.

Yük şekli

UptimeWarden tipik kullanımı kapsayan varsayılan bir yük gönderir:

{
  "event": "down",
  "timestamp": "2026-04-27T03:12:00Z",
  "monitor": {
    "id": "01HABC...",
    "name": "Payment API",
    "type": "http",
    "url": "https://api.example.com/health"
  },
  "alert": {
    "type": "down",
    "message": "Connection refused",
    "severity": "critical"
  },
  "data": {
    "status": "down",
    "responseTime": 0,
    "statusCode": 0,
    "errorMessage": "Connection refused",
    "sslExpiry": null,
    "daysRemaining": 0
  },
  "metadata": {
    "source": "UptimeWarden",
    "version": "1.0",
    "sentAt": "2026-04-27T03:12:01Z"
  }
}

Üst düzey event alanı alarm türünü taşır (down, recovery, ssl, high_response vb.), timestamp bir RFC3339 dizesidir ve alert.severity alarm türünden türetilir.

Özel yükler (şablonlar)

Uç noktanız farklı bir biçim bekliyorsa. Discord {"content": "…"} ister, OpsGenie {"message": "…", "priority": "P1"} ister, bir bildirim şablonu tanımlayın:

Settings → Notifications → Templates → New Template:

  1. Type, webhook.
  2. Webhook configuration, yukarıdaki yapılandırmaya bağlayın.
  3. Alert type, birini seçin (veya hepsini kapsayan default).
  4. Template content, değişken ikamesi içeren JSON veya metin.

Discord şablonu örneği:

{
  "content": "**{{monitor_name}}** - **{{incident_type}}** - {{error_message}}"
}

Yeniden deneme politikası

UptimeWarden geçici hatalarda pes etmez. İlk gönderim başarısız olursa 3 yeniden deneme yapılır; üçü de başarısız olursa mesaj manuel inceleme için bir kenara alınır.

DenemeGecikmeTetikleyici
İlk gönderimhemendispatch
Yeniden deneme 1~5 saniyetimeout, 5xx, ağ hatası
Yeniden deneme 2~30 saniyeaynı
Yeniden deneme 3~5 dakikaaynı
Vazgeçildi-3 yeniden denemeden sonra

4xx yanıtları (imza hataları, sizin tarafınızdaki doğrulama reddi) yeniden denenmez, bunlar nihai kabul edilir. Yeniden denemeler dağıtık (jitter'lı) üstel geri çekilme kullanır; bu sayede sorunlu bir alıcı, çok sayıda başarısız monitör için eş zamanlı bir yeniden deneme fırtınasına yol açmaz.

Tekrar (replay) penceresi

Webhook imzası, HMAC ile kapsanan bir timestamp (Unix saniye) içerir. Alıcılar zaman damgası 5 dakikadan eski olan istekleri tekrar saldırılarına karşı reddetmelidir. UptimeWarden hiçbir zaman eski istek göndermez, dolayısıyla geç gelen bir yük şüphelidir.

İmza sözleşmesi:

signed_payload = "<timestamp>.<raw_body>"
signature      = HMAC-SHA256(secret, signed_payload)
header         = "X-Webhook-Signature-V2: sha256=<hex>"

Node.js, Python ve Go için doğrulama örnekleri için bkz. Webhook Güvenliği.

Devre kesici (circuit breaker)

Her webhook yapılandırmasının kendi devre kesicisi vardır. Tekrarlayan başarısızlıklardan (5xx, timeout) sonra devre kesici açılır ve yapılandırma bir soğuma süresi boyunca atlanır, tek bir bozuk uç noktanın gönderim hattının tamamını tıkamasını engeller. Alıcı taraf düzeldiğinde devre kesici otomatik olarak kapanır.

SSRF koruması

Webhook URL'leri gönderim öncesinde doğrulanır:

  • Özel ağ aralıkları varsayılan olarak engellenir.
  • Bulut metadata uç noktaları engellenir.
  • Loopback ve link-local adresleri engellenir.
  • DNS rebinding'in etkisi azaltılır: ana adı bir kez çözüp gerçek istek için aynı IP'yi kullanırız.

Bu kontroller üretimde aktiftir. Kendi ağınız içindeki bir uç noktaya ulaşmanız gerekiyorsa destek ekibiyle iletişime geçin, hesap bazında izin verebiliriz. Bulut metadata, loopback ve link-local adresleri her durumda engellenmeye devam eder.

Test etme

Yapılandırma sayfasındaki Test webhook düğmesini kullanın. UptimeWarden, doğru başlıkların tamamıyla (imza dahil) örnek bir down yükü gönderir; uç noktanızın doğrulama yolu üretimle birebir aynı şekilde çalışır.

İlgili konular