When setting up uptime monitoring for your SaaS, you will generally run into two distinct architectural approaches: Ping (pull-based) monitoring and Heartbeat (push-based) monitoring.
While both are designed to keep you informed of outages, they operate in completely opposite directions and solve entirely different problems. Let's break down the trade-offs.
1. Ping Uptime Monitoring (Pull-Based)
In a ping setup, an external monitoring service periodically sends an HTTP request to your web server (e.g., once a minute) and waits for a response.
- How it works: Monitor $\rightarrow$ HTTP GET
/health$\rightarrow$ Server. - Best for: Public web servers, landing pages, and APIs.
- Pros:
- Requires zero modification to your codebase.
- Simulates actual user requests.
- Measures network latency from various geographical regions.
- Cons: Cannot monitor background daemons, localized cron scripts, or servers located behind secure firewalls/NATs with no public port exposure.
2. Heartbeat Monitoring (Push-Based)
In a heartbeat setup (often called a "Dead Man's Switch"), your internal code or script actively pings an external monitor whenever a task succeeds.
- How it works: Server (Cron Job) $\rightarrow$ HTTP POST
/ping$\rightarrow$ Monitor. - Best for: Cron jobs, backups, data syncing, queue workers, and private network servers.
- Pros:
- Confirms the code actually completed successfully, not just that the server is powered on.
- Works perfectly for isolated, private, or firewall-restricted servers.
- Handles highly variable schedules (e.g., monthly cron tasks).
- Cons: Requires a minor integration step in your code or crontab script to send the ping signal.
Summary: Which one to use?
For total peace of mind, you need both.
Use Ping monitoring to ensure your main web app is responsive to public users, and use Heartbeat monitoring (like CronRabbit) to make sure your background tasks are ticking along safely behind the scenes.