BugsRadar

Cron, backups and services on one VPS

Updated 1 October 2026 · BugsRadar team

One server. A few cron jobs, a backup script, two systemd services, maybe a SQL Server Agent job on the Windows box next to it. No monitoring agent, because installing and feeding one is more work than the server deserves. The failures are found weeks later, usually when the backup is needed.

One request from the job itself

Anything that can run curl can report its own failure: a POST to https://api.bugsradar.com/api/v3/notify with the project's key in a header and the text of the message. The server answers at once, delivery happens in the background, and the message arrives in your Telegram, Discord or Pushover with the host and the job's name. See the HTTP endpoint.

The copy-paste for each case

One project, one chat

Make one project, "Ops", and connect it to a chat of your own; set category to the job's name and host to the server, and every message says which job on which machine. The key lives in an environment variable or at the top of the crontab, never in a script that goes into a repository: see Keep the API key secret.

Nightly failures and failing-every-minute failures

A job that fails once a night brings a full message every night. A job that fails every minute brings one message and counts the repeats in it. Numbers, ids and timestamps in the text don't count when messages are compared, so "Backup failed at 03:00" and "Backup failed at 03:05" are the same error, not two.

What it doesn't do

BugsRadar hears from a job that ran and failed. A job that never started, because cron is misconfigured or the server is down, can't send anything; for that you need a heartbeat monitor, which is a different tool for a different question: see Logs, monitoring, alerts.

Where to go next

Start with the cron guide; it is one line. Internal tools nobody monitors covers the tools the jobs serve.

Next: Production, staging, dev: one chat or several →