वह विफलता मोड जिसके बारे में कोई नहीं बोलता: एक निर्धारित कार्य चलना बंद कर देता है और कुछ नहीं बताता। Windows Task Scheduler हरी “तैयार” स्थिति दिखाता है जबकि अंतर्निहित स्क्रिप्ट तीन हफ्ते से एक लापता निर्भरता पर शांति से बाहर निकल रही है। होम सर्वर पर एक cron job शेड्यूल में एक OS अपग्रेड से बचता है लेकिन वातावरण में नहीं, और बैकअप जो हर रात चलना चाहिए फ़ाइलें लिखना बंद कर देता है। सिस्टम नहीं सोचता कि कुछ गलत है क्योंकि कुछ नहीं फेंका गया। बैकअप बस गायब हो गया।
हमने 2026 में Linux, Windows, और macOS भर में शांत निर्धारित कार्य विफलताओं को पकड़ने के लिए 7 सर्वश्रेष्ठ ऐप्स का परीक्षण किया। सूची में dead-man-switch सेवाएं शामिल हैं जो आपके काम से एक ping की उम्मीद करती हैं और जब वह शांत हो जाता है तो सतर्क करते हैं, सामान्य uptime मॉनिटर जो push mode heartbeats को भी संभालते हैं, मीट्रिक exporters जो आपको पैटर्न को ग्राफ़ करने देते हैं, और स्थानीय उपकरण जो कच्चे संकेत को एक सतर्कता में बदलते हैं जहां आप वास्तव में पढ़ते हैं।
निर्धारित कार्य मॉनिटर में क्या देखें
एक उपकरण चुनें जो:
- Dead-man switch का उपयोग करता है, केवल “जांचें कि क्या exit code शून्य था।” पूरा बिंदु यह है कि काम बिल्कुल नहीं चल रहा है।
- शेड्यूल tolerance को समझदारी से संभालता है। एक काम जो 03:00 पर चलता है, सतर्क करने से पहले कुछ मिनट की drift को सहन करना चाहिए; एक काम जो हर मिनट चलता है, घंटों को सहन नहीं करना चाहिए।
- एक चैनल को सतर्क भेजता है जो आप जांचते हैं। ईमेल तब तक ठीक है जब तक आपके मेल सर्वर पर outage न हो; कम से कम एक non-email चैनल (एक push सेवा, एक Discord webhook, एक SMS) को superimpose करें।
- इसे monitor करता है इससे स्वतंत्र रूप से चलता है। एक monitor जो उस box के साथ मर जाता है जिसे वह देख रहा है, वह एक monitor नहीं है।
- प्रति काम भुगतान की आवश्यकता नहीं है। घरों में अक्सर बीस या तीस निर्धारित कार्य होते हैं; एक per-job billing मॉडल घरेलू बुनियादी ढांचे को कॉर्पोरेट cost center में बदल देता है।
त्वरित तुलना
| ऐप | सर्वश्रेष्ठ के लिए | दृष्टिकोण | Self-hosted | मुक्त tier |
|---|---|---|---|---|
| Healthchecks.io | Self-hosted विकल्प के साथ Dead-man switch | Push heartbeat | हाँ | हाँ, 20 checks |
| Cronitor | Per-job statistics के साथ पूर्ण cron telemetry | Push + wrapper | नहीं | हाँ, 5 monitors |
| Dead Man’s Snitch | मूल निर्धारित-कार्य heartbeat | Push heartbeat | नहीं | हाँ, 1 snitch |
| Uptime Kuma | Push mode के साथ Self-hosted uptime monitor | Pull + push | हाँ | मुक्त, self-hosted |
| Prometheus Node Exporter | Systemd timer status के लिए मेट्रिक्स | Pull metrics | हाँ | मुक्त |
| systemd | Linux पर मूल विफलता detection | मूल | हाँ | मुक्त |
| Gotify | Self-hosted push notification server | Push server | हाँ | मुक्त |
“कार्य चलाया गया” “कार्य कार्य किया गया” के समान क्यों नहीं है
अधिकांश schedulers जो mental model उपयोग करते हैं वह “क्या प्रक्रिया समाप्त हुई?” है और जो mental model की आवश्यकता है वह “क्या परिणाम हुआ?” है। एक backup script जो सफलतापूर्वक समाप्त हुई क्योंकि source directory खाली था, वह एक काम करने वाला backup नहीं है। एक sync जो सफलतापूर्वक समाप्त हुआ क्योंकि नेटवर्क offline था और retry loop quietly दे दिया गया, वह एक काम करने वाला sync नहीं है। एक rebuild-search-index कार्य जो सफलतापूर्वक समाप्त हुआ क्योंकि daemon down था और client ने खाली response लौटाया, वह एक काम करने वाला rebuild नहीं है।
फिक्स दो-layered है: काम एक heartbeat भेजता है केवल इसके बाद कि यह अपना वास्तविक काम पूरा कर ले (केवल शुरू होने के बाद नहीं), और monitor सतर्क करता है जब heartbeat गायब हो जाता है। Schedule stack में कुछ और नहीं “quietly कुछ नहीं कर रहे” मोड को पकड़ता है। Task Scheduler नहीं। Cron नहीं। Windows Event Log नहीं।
ऐप्स
1. Healthchecks.io — self-hosted विकल्प के साथ सर्वश्रेष्ठ dead-man switch
Healthchecks.io dead-man-switch पैटर्न का reference implementation है। प्रत्येक निर्धारित कार्य को एक unique URL मिलता है, कार्य सफल चलाने के अंत में उस URL को curl करता है, और Healthchecks सतर्क करता है यदि ping expected window में नहीं आता है। Per-check grace periods, ping-with-exit-code (तो curl $URL/fail check को explicitly failed के रूप में चिह्नित करता है), और per-check schedules जो एक simple interval या पूर्ण cron expression के रूप में व्यक्त किए जाते हैं। Slack, Discord, PagerDuty, Gotify, ntfy, email, SMS, webhook, और लगभग बीस अन्य alert channels।
कहाँ यह कम है: Hosted free tier 20 checks तक सीमित है; बड़े automation surfaces वाले घर इसे outgrow करेंगे। Self-hosting यह ठीक करता है लेकिन एक service को maintain करने के लिए जोड़ता है।
Platforms: Self-hosted के लिए कोई भी Linux/Docker host। Hosted tier कुछ भी जो एक HTTP request कर सकता है से काम करता है।
डाउनलोड: Healthchecks.io install
मूल लाइन: Home server पर निर्धारित-कार्य heartbeats के लिए सही default।
2. Cronitor — per-job stats के साथ सर्वश्रेष्ठ पूर्ण cron telemetry
Cronitor heartbeat से परे जाता है और पूर्ण runtime चित्र को capture करता है — कितने समय का काम, exit code, stdout और stderr, runs भर में comparative graphs, और इनमें से किसी को बदलने पर सतर्कता। Cronitor CLI में काम को wrap करें या direct में URL को start, end, और fail पर ping करें। Dashboard teams के लिए aimed है; आधे features का use करने वाला घर अभी भी runtime graphs से value प्राप्त करेगा।
कहाँ यह कम है: केवल hosted — कोई self-hosted path नहीं। Free tier 5 monitors है, जो busy server पर जल्दी भर जाता है।
Platforms: कोई भी host जो outbound HTTPS कर सकता है। Linux, macOS, Windows के लिए CLI wrapper।
डाउनलोड: Cronitor download
मूल लाइन: सही pick जब आप per-job runtime graphs चाहते हैं और hosted service के साथ comfortable हैं।
3. Dead Man’s Snitch — सर्वश्रेष्ठ मूल heartbeat service
Dead Man’s Snitch ने पैटर्न को popularize किया और एक शांत विफलता को catch करने का एक सबसे आसान तरीका बना हुआ है। एक snitch बनाएं, एक URL प्राप्त करें, काम को वह URL hit करें, एक email प्राप्त करें यदि URL को interval में ping नहीं किया गया। वह पूरा product है। जब “क्या कुछ को इससे अधिक जटिल होने की आवश्यकता है?” सही सवाल है, Dead Man’s Snitch honest उत्तर है।
कहाँ यह कम है: Free tier एक snitch है — एक critical काम को protect करने और कुछ नहीं के लिए पर्याप्त। Feature depth Healthchecks और Cronitor से पीछे रहता है।
Platforms: कोई भी host जो outbound HTTPS कर सकता है।
डाउनलोड: Dead Man’s Snitch signup
मूल लाइन: सही pick जब “backup चलाया गया नहीं” alert एकमात्र परिणाम है जो आपको protect करने की आवश्यकता है।
4. Uptime Kuma — push mode के साथ सर्वश्रेष्ठ self-hosted uptime monitor
Uptime Kuma self-hosted uptime monitor है जो अपने HTTP और TCP probes के साथ एक proper push-mode में grow किया। Point-and-click UI, अधिकांश alert channels जो लोग care करते हैं, per-check status pages, और वही “check को X seconds में push किया गया” मॉडल Healthchecks के रूप में। यदि home server already media stack के लिए Uptime Kuma चलाता है, तो एक ही dashboard में cron job heartbeats जोड़ना कुछ clicks खर्च करता है।
कहाँ यह कम है: Push-mode support pull-mode probes से newer है और जहां rougher edges हैं। Cron-heartbeat use case में Healthchecks की तुलना में कम specialized।
Platforms: Linux (Docker), Windows, macOS।
डाउनलोड: Uptime Kuma install
मूल लाइन: सही pick जब घर already Uptime Kuma चलाता है और एक और dashboard नहीं चाहता।
5. Prometheus Node Exporter — systemd timer status के लिए सर्वश्रेष्ठ metrics
Prometheus Node Exporter systemd unit और timer state के लिए एक collector ship करता है। Prometheus और Alertmanager के साथ combined, आप “जब यह timer last successfully चलाया गया था,” “यह timer last में N मिनट में नहीं चलाया गया था,” को alert कर सकते हैं, और system-wide metrics (CPU, disk, network) के साथ correlate कर सकते हैं। यह industrial-strength approach है; घर के लिए overkill, home lab में पहले से Prometheus run करने के लिए बिल्कुल सही।
कहाँ यह कम है: Useful होने के लिए पूरी Prometheus stack की आवश्यकता है — वह real infrastructure है, पांच मिनट की install नहीं। Timer collector के लिए Systemd-specific; cron jobs को एक अलग दृष्टिकोण की आवश्यकता है।
Platforms: Linux, Windows, macOS, FreeBSD।
डाउनलोड: Prometheus Node Exporter releases
मूल लाइन: सही pick जब Prometheus already home lab पर metrics store है।
6. systemd — Linux पर सर्वश्रेष्ठ मूल विफलता detection
systemd आधुनिक Linux पर अधिकांश cron migrants को एहसास से अधिक built-in failure handling है। OnFailure= के साथ एक unit fail होने पर एक अन्य unit को trigger करता है, जो एक mail script, एक webhook, या एक Healthchecks को ping करने वाली script हो सकता है। systemctl list-timers schedule और last run दिखाता है, और systemctl status <unit> exit code और log tail दिखाता है। किसी के लिए जो already systemd timers पर है, आधी monitoring पहले से box में है।
कहाँ यह कम है: आपको केवल बताता है जब process fail हुई, जब result fail हुई नहीं। एक backup script जो finish हुई लेकिन कुछ उपयोगी नहीं किया systemd के लिए green दिखता है।
Platforms: Linux (systemd-based distributions)।
डाउनलोड: systemd resources
मूल लाइन: Systemd timers चलाने वाले किसी भी Linux server पर सही minimum।
7. Gotify — सर्वश्रेष्ठ self-hosted push notification server
Gotify छोटा Go server है जो किसी भी HTTP request को Android push notification में बदल देता है। अपने आप से failures को detect नहीं करता; ऊपर दिए गए किसी भी tool के साथ combined, यह तरीका बन जाता है कि alerts Firebase Cloud Messaging या third-party notification service पर निर्भर किए बिना एक फ़ोन तक पहुंचता है। उन घरों के लिए आदर्श जहां alert channel को monitor किए जा रहे servers जितना private होना चाहिए।
कहाँ यह कम है: अपने आप में एक monitor नहीं। Android app को receiving phones पर installed होने की आवश्यकता है; iOS support Gotify के अपने app की जगह ntfy या similar पर निर्भर करता है।
Platforms: Linux (Docker), Windows, macOS, FreeBSD।
डाउनलोड: Gotify install
मूल लाइन: Self-hosted alerting stack के लिए सही last-mile push notification server।
सही कैसे चुनें
- यदि आप चाहते हैं कि dead-man switch आज काम करे: Healthchecks.io (self-host एक बार 20 checks के परे grow)।
- यदि आप चाहते हैं per-job runtime telemetry और hosted service के साथ comfortable हैं: Cronitor।
- यदि आपको केवल एक critical काम को protect करने की आवश्यकता है: Dead Man’s Snitch।
- यदि home server already Uptime Kuma चलाता है: Uptime Kuma।
- यदि Prometheus already metrics store है: Prometheus Node Exporter।
- यदि Linux server systemd timers चलाता है और आप built-in monitoring चाहते हैं: systemd।
- यदि आप चाहते हैं कि alerts third-party push service के through जाए बिना household के फ़ोन तक पहुंचें: Gotify।
अधिकांश home labs के लिए, काम करने वाला combination Healthchecks (self-hosted) है dead-man switch के रूप में, Gotify को phone push के लिए wired और email को fallback के रूप में। कुछ भी जो systemd timer के रूप में runs को एक OnFailure= unit मिलता है जो failure पर same Healthchecks endpoint को ping करता है तो दोनों signals correlate।
FAQ
Heartbeat और health check के बीच अंतर क्या है?
एक heartbeat काम है “मैंने run किया और सफल हुआ।” एक health check एक monitor है जो service को probe करता है देखने के लिए कि क्या यह respond करता है। Heartbeats silent scheduled-task failures को catch करते हैं; health checks runtime service failures को catch करते हैं। आप दोनों चाहते हैं।
मुझे alerts कहां भेजने चाहिए?
Monitor किए जा रहे machine के बाहर कहीं। Email fallback के रूप में अच्छा है लेकिन एकमात्र channel नहीं होना चाहिए — यदि mail चलाने वाला machine वह machine है जो failed, alert कभी नहीं जाता। Email plus phone push (ntfy, Gotify, Pushover) plus chat channel (Discord webhook, Slack) को high-priority काम के लिए superimpose करें।
मैं Windows Task Scheduler काम में heartbeat कैसे जोड़ूं?
एक छोटी PowerShell script में action को wrap करें जो real task चलाता है, exit code को check करता है, और Invoke-WebRequest को Healthchecks या Cronitor URL के against तब तक call करता है जब तक सब कुछ successful न हो। Task Scheduler की “run this on completion” hook success और failure को cleanly distinguish नहीं करता, तो script में करें।
क्या systemd Linux monitoring के लिए सच में पर्याप्त है?
“प्रक्रिया crash हुई?” के लिए — हाँ। “परिणाम हुआ?” के लिए — नहीं। Systemd के OnFailure= को एक heartbeat के साथ combine करें जो काम केवल उसके बाद अपना real काम finish होने के लिए पूरी चित्र के लिए।
क्या मुझे अभी भी cron को monitor करना चाहिए?
हाँ। Cron चल सकता है और healthy हो सकता है जबकि individual काम quietly fire करना बंद कर देते हैं (bad crontab syntax, permission change, missing user)। Uptime Kuma या Healthchecks भी cron के last-run time को home server पर monitor कर सकते हैं; यदि वह stale हो जाता है, cron वह है जिसे attention की आवश्यकता है।
