Cron Heartbeat İzleme Çalışmayan Görevi Fark Edin

Cron görevinin en tehlikeli hali sessizce durmasıdır. Sunucu kapanır, crond durur, crontab satırı bozulur veya betik yarıda kalırsa çoğu ekip bunu saatler sonra fark eder. Heartbeat (nabız) izleme, görevin beklenen zamanda bir "yaşıyorum / bittim" sinyali göndermesini ister; sinyal gelmezse alarm üretir. Bu model dead man's switch olarak da anılır.

Bu rehber heartbeat'i uptime kontrolünden ayırır, başarı pingi ile başlangıç/hata sinyallerini gösterir, periyot ve tolerans seçimini somutlaştırır. Erişilebilirlik (HTTP 200 alınabiliyor mu?) konusu cron uptime monitoring sayfasında kalır; burada odak, beklenen tamamlanma sinyalinin gelmemesidir. Görev tetiklenmiyorsa önce cron job çalışmıyor teşhis adımlarını uygulayın.

Uygulamada ping genelde Healthchecks.io veya Cronitor gibi bir alıcıya gider. Resmi kurulum notları için Healthchecks cron izleme ve Cronitor heartbeat rehberi kaynak alınabilir. cronjob.com.tr HTTP işini tetikler; heartbeat alıcısı veya kaçırılan ping alarmı ürün tanımında yoktur.

Heartbeat Çalışma Modeli

Klasik akış üç adımdır: (1) zamanlayıcı görevi başlatır, (2) iş başarıyla biter, (3) betik veya crontab satırı izleme servisine kısa bir HTTP isteği (ping) atar. İzleyici, tanımladığınız takvime göre bir sonraki ping penceresini bilir. Pencere + tolerans dolana kadar sinyal gelmezse görev "down" sayılır ve e-posta, SMS veya sohbet kanalına bildirim gider.

Bu model şu arızaları yakalar:

• Makine kapalı, ağ yok veya disk dolu olduğu için cron hiç çalışmaz.
• crond servisi durmuş veya crontab sözdizimi geçersizdir.
• Görev başlar ama sıfırdan farklı çıkış koduyla biter (&& curl kullanıyorsanız ping gitmez).
• Görev beklenenden çok uzun sürer (başlangıç sinyali + süre eşiği ile).

MAILTO değişkeni yalnızca komut çıktısı üretildiğinde ve sunucuda MTA yapılandırılmışsa işe yarar; makine tamamen kapalıysa mail de gitmez. Heartbeat bu boşluğu kapatır çünkü yokluk da bir olaydır.

Uptime Kontrolünden Farkı

Uptime kontrolü dışarıdan bir URL'ye istek atıp "servis ayakta mı?" sorusunu sorar. Heartbeat ise içeriden gelir: "bu iş planlandığı gibi bitti mi?" Uptime yeşilken yedekleme cron'u bozulmuş olabilir; heartbeat kırmızıysa site hâlâ 200 dönebilir. İkisini karıştırmak yanlış önceliklendirmeye yol açar.

Ürün tarafında ardışık HTTP hatalarında e-posta uyarısı, tetiklenen işin erişilebilirlik sorununu gösterir; bu, uygulamanızın Healthchecks'e attığı tamamlanma pinginin yerine geçmez.

Başarı Pingi

En yaygın kalıp: iş exit 0 ile bittikten sonra tek GET/POST. Healthchecks örneğinde ping URL'si kontrol oluşturulunca üretilir; crontab şöyle güncellenir:

# Her gun 06:08 yedek; yalniz basariyla bitince ping
8 6 * * * /home/deploy/backup.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/YOUR-UUID-HERE

-f HTTP hatalarını başarısız sayar, -m 10 süresi dolunca takılmaz, --retry geçici ağ kesintisinde ping kaybını azaltır. Ping'i betiğin son satırına taşımak crontab'ı sade tutar:

#!/usr/bin/env bash
set -euo pipefail
/usr/bin/pg_dump mydb | gzip > /backups/mydb-$(date +%F).sql.gz
curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/YOUR-UUID-HERE

set -e sayesinde dump başarısız olursa curl çalışmaz; izleyici eksik ping görür. Zaman ifadesini doğrulamak için crontab sözdizimi ve crontab örnekleri sayfalarını kullanın.

Başlangıç ve Hata Sinyalleri

Yalnızca başarı pingi, "hiç çalışmadı" ile "çok uzun sürüyor" ayrımını her zaman netleştirmez. Birçok izleyici üç durumu ayırır:

• Start: iş başladı (ör. Healthchecks'te /start soneki).
• Success: iş bitti (temel ping URL'si).
• Fail: iş bilinçli olarak hata bildirdi (ör. /fail).

#!/usr/bin/env bash
PING=https://hc-ping.com/YOUR-UUID-HERE
curl -fsS -m 10 -o /dev/null "${PING}/start" || true
if /home/deploy/backup.sh; then
  curl -fsS -m 10 --retry 5 -o /dev/null "${PING}"
else
  curl -fsS -m 10 -o /dev/null "${PING}/fail" || true
  exit 1
fi

Fail sinyali, exit kodunu göremeyen ortamlarda (bazı paneller, sarmalayıcılar) aktif hata bildirimi sağlar. Start sinyali ise süre takibi için temel oluşturur. Cronitor tarafında iş yaşam döngüsü durumları (state=run, state=complete, state=fail sorgu parametreleri) aynı fikri taşır; heartbeat tick ise düzenli nabız için kullanılır.

Periyot ve Tolerans

İzleyiciye görevin beklenen takvimini ve grace (tolerans) süresini doğru vermezseniz ya geç haber alırsınız ya da yanlış alarm yağmuruna tutulursunuz. Grace, işin normal süresinin biraz üstünde olmalıdır.

1. Cron ifadesini izleyiciye sunucudakiyle aynı yazın (ör. 8 6 * * *).
2. Saat dilimini sunucu ile hizalayın; sapma için cron timezone kontrolü yapın.
3. Grace'i ölçülen süreye göre seçin: 20 dk süren işe 5 dk grace yetmez, 3 saat de gereksiz geciktirir.

Saatlik veya daha sık işlerde grace'i periyodun küçük bir oranı tutun; aksi halde bir kaçırma bir sonraki pencereye taşar ve teşhis zorlaşır.

Uzun Görevleri İzleme

Saatler süren yedekleme, büyük ETL veya arşiv işlerinde tek başarı pingi yetersiz kalabilir. Start + üst süre eşiği (veya izleyicinin "too long" kuralı) kullanın. İş kuyruğa alınıp hemen HTTP 200 dönüyorsa ping'i kuyruk işçisinin gerçek bitişine koyun; aksi halde "tetikleyici yaşadı, iş ölmedi" kör noktası oluşur.

İki somut senaryo:

1. Gece yedeği (02:00, ~40 dk): Start 02:00'te, success bitişte, grace 60 dk. Fail yolu dump hata kodunda.
2. Saatlik senkron (her saat, ~2 dk): Yalnızca success ping + 10 dk grace. Start opsiyonel; gürültüyü azaltır.

Çıktıyı ping gövdesinde göndermek (bazı servislerde POST body) son hata satırını alarma ekler; hassas veri sızdırmamaya dikkat edin. Logların yerelde kalması için cron job log pratikleriyle birleştirin.

Yanlış Alarm Nedenleri

Heartbeat yanlış alarmları çoğu zaman kurulum kaynaklıdır:

Saat dilimi uyuşmazlığı

Ping bir saat erken/geç geliyorsa sunucu TZ ile izleyici TZ farklıdır. timedatectl status çıktısındaki Time zone satırını izleyici ayarıyla karşılaştırın.

Grace çok kısa

İş bazen 12, bazen 35 dakika sürüyorsa 15 dk grace sürekli alarm üretir. P95 süreye göre yükseltin.

Ping ağ hatası

İş başarılıdır ama curl DNS/timeout yüzünden ping atamaz. -m ve --retry kullanın; çıkış kodunu loglayın. Ping başarısızlığını iş başarısızlığından ayırmak için ayrı log satırı yazın.

Çift zamanlayıcı / mükerrer crontab

Aynı iş iki sunucuda veya hem panel hem crontab'da tanımlıysa fazla ping veya karışık pencereler görülür. Tek sahip belirleyin. Sözdizimi hatalarında çalışmama teşhisi ve /var/log/cron incelemesi şarttır.

Zamanlayıcı ve İzleyiciyi Birlikte Kullanma

Sağlam kurulumda zamanlayıcı ile izleyici ayrı sorumluluk taşır. Zamanlayıcı (crontab, panel veya HTTP cron) işi başlatır. İzleyici yalnızca tamamlanma/kaçırma sinyalini dinler. İkisini aynı araca sıkıştırmak mümkün olsa da "tetikledim" ile "iş bitti" olaylarını logda ayırmak teşhisi hızlandırır.

Önerilen birleşim:

1. Görevi sunucuda veya HTTP ile güvenilir şekilde tetikleyin.
2. Betik sonunda (veya fail yolunda) heartbeat alıcısına ping atın.
3. Alarm kanalını e-posta + sohbet gibi yedekli tutun; tek kanala güvenmeyin.
4. Kritik işlerde haftalık test: bilerek ping'i bir kez atlayıp bildirimin geldiğini doğrulayın.

Telegram veya e-posta ile insanlara özet göndermek ayrı bir bildirim katmanıdır; kaçırılan çalışmayı garanti etmez. Mesaj kanalı için cron Telegram bildirimi ve cron e-posta gönderme rehberlerine bakın.

cronjob.com.tr ile HTTP Tetikleme ve Heartbeat Ayrımı

Uygulamanızda korumalı bir cron endpoint'i varsa cronjob.com.tr bu URL'yi zamanında çağırır. Gerçek iş o endpoint'te (veya kuyruk işçisinde) bittikten sonra ping'i Healthchecks/Cronitor'a siz gönderirsiniz. Ürüne heartbeat alıcısı veya "ping gelmedi" alarmı atfedilmemelidir.

• Hedef URL: https://api.siteniz.com/internal/cron/nightly-backup
• Metot / header: POST ve Authorization: Bearer <gizli-token>
• Zamanlama: hazır aralık veya 5 alanlı ifade; saat dilimi iş bazında
• Ürün izlemesi: ardışık erişim hatalarında e-posta (varsayılan eşik 3); bu, başarısız HTTP yanıtları ve bağlantı hataları içindir
• Heartbeat: endpoint veya worker, iş bitince kendi ping URL'sine istek atar

<?php
// Endpoint gizli token ile korunur
$secret = getenv('CRON_SECRET') ?: '';
$token = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
if ($secret === '' || !hash_equals('Bearer ' . $secret, $token)) {
    http_response_code(401);
    exit('unauthorized');
}
// Endpoint isi bitirince heartbeat ping atar
function heartbeat_success(string $url): void {
    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT => 10,
        CURLOPT_FAILONERROR => true,
    ]);
    curl_exec($ch);
    curl_close($ch);
}

// ... yedekleme is mantigi ...
heartbeat_success(getenv('HC_PING_URL') ?: '');
http_response_code(200);
echo json_encode(['ok' => true]);

HTTP tetikleme seçenekleri için ücretsiz cron job servisi ve cron webhook tetikleme sayfalarına bakabilirsiniz. Yerel ağ / localhost hedeflerine istek gönderilmez; ping URL'si herkese açık HTTPS uç nokta olmalıdır.

Sıkça Sorulan Sorular (SSS)

Heartbeat izleme uptime kontrolünden nasıl ayrılır?

Uptime kontrolü bir URL'nin dışarıdan erişilebilir olup olmadığını sorar. Heartbeat ise görevin beklenen zamanda tamamlanma sinyali göndermesini bekler; sinyal gelmezse görev çalışmamış veya bitmemiş sayılır.

Başarı pingi cron satırına mı yoksa betiğin içine mi yazılmalı?

Mümkünse betiğin en sonuna yazın ve yalnızca iş başarıyla bittikten sonra çağırın. Crontab'da komut && curl kullanıyorsanız ping yalnızca sol taraf exit 0 döndüğünde gider.

Tolerans (grace) süresi neye göre seçilir?

Toleransı görevin normal bitiş süresinin biraz üstüne koyun. Örneğin iş 15–25 dakika sürüyorsa 30 dakikalık grace, geçici gecikmede yanlış alarmı azaltır.

cronjob.com.tr kaçırılan heartbeat alarmı gönderir mi?

Hayır. cronjob.com.tr HTTP işini tetikler; tamamlanma pingi uygulamanızdan Healthchecks veya Cronitor gibi bir heartbeat alıcısına gider. Ürün yerleşik heartbeat alıcısı veya kaçırılan ping alarmı sunmaz.

İlgili Rehberler