How to monitor cron jobs step by step
This guide walks through setting up cron-job monitoring in SitePuls — from choosing a schedule to verifying missed-run detection. It is an instructional setup playbook, not a commercial landing or an operational checklist. SitePuls does not run your crontab; your job must send a check-in after successful work.
Step 1: Choose the cron job to monitor
Pick a job whose silence hurts — backups, imports, reports, or cleanup. Note the owner, expected cadence, and maximum healthy runtime so interval and grace can be set realistically.
Step 2: Create a heartbeat check-in monitor
In SitePuls, create a heartbeat monitor for that job. You will get a unique check-in URL (token-based). Keep one monitor per cron pipeline so a miss points to the right script.
Step 3: Copy the unique check-in URL
Copy the URL from the monitor detail screen. Treat it like a credential: store it in your deployment secrets or environment, not in a public repository.
Step 4: Send the HTTP check-in after success
At the end of a successful run, call the URL with an HTTP GET (for example curl -fsS "https://example.sitepuls/heartbeat/YOUR_TOKEN"). Send the check-in only after success — a failure path must not report a false completion. Exact shell syntax varies by environment; use any HTTPS client your job can call.
Step 5: Set expected interval and grace
Set the expected interval to how often the job should check in. Add a grace period so longer-than-usual runs do not look like a miss. Tune both to worst-case healthy runtime.
Step 6: Connect alert contacts
Attach email, Telegram, or webhook contacts that own the job. Missed check-ins and recovery notices use the same channels as other SitePuls monitors.
Step 7: Test a miss and confirm recovery
In a maintenance window, skip one run or delay the check-in. Confirm the monitor goes DOWN and alerts fire, then send a successful check-in and confirm recovery. Review the incident timeline afterward.
Step 8: Maintain after schedule changes
When cron timing changes, update the expected interval and grace. Re-test contacts after ownership changes. For product context see cron job monitoring; for the check-in mechanism see heartbeat monitoring; finish with the operational checklist before go-live.
What you can verify with SitePuls here
- Cron-style reliability uses heartbeat monitors: your task calls a unique URL when it finishes successfully.
- If the call does not arrive inside the expected interval (including grace), SitePuls marks the heartbeat monitor as failed.
- No agent install is required—only an outbound HTTPS request from your existing environment.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
Frequently asked questions
Where should the check-in request be added?
At the end of a successful job path — after the backup, import or report finishes — not at the start of the script.
Should a check-in be sent before or after the job?
After successful completion. Sending early can mark a failed or partial run as healthy.
How should the expected interval be selected?
Match the cron cadence. If the job runs hourly, expect roughly hourly check-ins, then add grace for variance.
How can the setup be tested?
Skip or delay one check-in in a controlled window, confirm DOWN and alerts, then recover with a successful check-in.
What happens when a run is missed?
If no check-in arrives within expected interval plus grace, the monitor can go DOWN and notify your contacts.
How should schedule changes be handled?
Update the monitor’s expected interval and grace to match the new cron timing, then re-verify with a controlled test.
Which alert contacts can be used?
Email, Telegram, and webhook contacts attached to the monitor.
Can jobs on another server be monitored?
Yes, if that server can reach the HTTPS check-in URL after a successful run.