Beacon: monitoring for unattended scripts

Most production software has a layer of unattended scripts behind it. Cron jobs. Scheduled tasks. Background workers. Backup runners. Things that are supposed to “just run.”

The problem is that when one of them stops running, nobody notices until something downstream breaks — and by then the data is stale, the backup is days old, or the integration has silently fallen behind.

Beacon started as an internal tool to fix that for one project. It’s grown into a product suite.

The original problem

A client’s WordPress site had a nightly script that pulled product data from a supplier API. One week the script stopped firing. Nobody knew. Stock numbers diverged from reality. By the time it was caught manually, the site had been showing wrong availability for nine days.

The standard answer to this — uptime monitoring — doesn’t quite work. Uptime monitoring tells you whether a server is responding. It doesn’t tell you whether a specific scheduled job ran when it was supposed to.

What was needed was the inverse: a system that expects a check-in from each script on a schedule, and alerts when the check-in doesn’t arrive.

What Beacon does

Each script gets a unique endpoint and a schedule (e.g. “every 6 hours, with a 30-minute grace window”). The script pings the endpoint at the end of every successful run. If the ping doesn’t arrive within the grace window, Beacon raises an alert.

The interesting design decisions were:

• Inverted check. Failure = silence, not an error response. This catches scripts that died completely, not just ones that errored cleanly.
• Grace windows per job. Some scripts run every five minutes, some run weekly. A single global tolerance doesn’t work. Each job gets its own.
• Alert routing per job. Critical scripts page someone immediately. Lower-priority ones batch into a daily digest. Same monitor, different routing.
• A history view. Not just “is it running” but “has it consistently run on time over the last month?” Drift in run-time often predicts a future failure.

What it grew into

The monitoring system became one piece of a bigger product called Beacon. The same Laravel + React platform now also runs:

• A WordPress plugin that adds Beacon hooks to WP cron jobs without code changes.
• A browser extension for triggering manual check-ins and viewing recent run history without leaving the tab.
• Mobile and desktop apps for receiving alerts when something goes silent — with desktop integration for engineers who don’t want yet another phone notification.

All of it sits on the same platform that powers the Digital Royalty client dashboard. That meant authentication, billing, permissions, and real-time updates were already there. The Beacon work was building the product on top, not rebuilding the scaffolding underneath.

What this case shows

Two things worth pulling out of this engagement:

1. The right scaffolding makes new products cheap. Beacon went from “internal tool” to “multi-platform product suite” in months, not years, because it was built on a platform designed for multiple products from day one. The first product is expensive; everything after is incremental.
2. Real monitoring is opinionated. Off-the-shelf uptime tools didn’t fit the problem. The fix wasn’t a bigger off-the-shelf tool — it was a smaller, more opinionated one built for this exact failure mode.

If your business has unattended scripts running production-critical work and no way to know when one of them stops, the fix is cheap. If it’s running on a platform that can’t grow with the rest of the business, the fix is structural.