Monitor systemd timers the same way you monitor cron
Works with curl on the box.
If the box uses systemd timers, crontab -l will lie to you. The schedule lives in a .timer unit. The work lives in a .service unit. Monitoring has to attach to that service, not to a crontab that does not exist.
Where to put the ping
A oneshot service can end with:
ExecStart=/usr/local/bin/job.sh ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 5 https://www.pingclock.com/ping/YOUR_ID
Only use ExecStartPost if job.sh's success is what you mean. If job.sh can return 0 after a partial run, wrap it.
OnCalendar vs Period
Copy OnCalendar into the Ping Clock check as a cron expression, or convert to an every-N-hours period if that is how the timer is written. Keep the time zone equal to the host.
The timer was disabled
systemctl disable --now is a common "temporary" fix that becomes permanent. The heartbeat is how you notice the timer never came back.
FAQ
Does journalctl already cover this?
Journals tell you what happened if you look. They do not page you when nothing happened.
What about user timers?
Same pattern. Ping from the user service. Use a check name that includes the username.