Show HN: ConfigClarity – Visualize cron overlaps before they crash your server | Hacker News Reader

Show HN: ConfigClarity – Visualize cron overlaps before they crash your server

configclarity.dev

11 pointsmetriclogic13 comments

Built this after dealing with overlapping cron jobs that quietly exhausted server resources. The cron daemon will happily spawn multiple copies of your script simultaneously until your server runs out of memory — with no warning. Paste your crontab (supports standard crontab -l format), and it shows a 24-hour timeline with overlap detection, Server Load Warnings, and human-readable job descriptions. No signup. No data leaves your browser. Everything runs client-side. Would love feedback from anyone who runs cron jobs in prod. https://configclarity.dev

Open articleView on HN

Happy to answer questions about how the parser handles edge cases, or why I chose client-side only. Also curious — do you manually check for cron overlaps today, or just find out when something breaks?

How does it handle jobs that run on different servers? Like if I have 5 machines all running their own crontabs, the overlap problem is actually across hosts not just within one crontab.

Single host for now. Multi-host is a real problem but wanted to nail the common case first — most people don't know they have single-host overlaps until something breaks.

We use a wrapper script with a lockfile check before every job. Works but it’s boilerplate we copy-paste everywhere and half the team forgets to add it.

Lockfiles are the right runtime fix. ConfigClarity is the planning layer before that — catch the collision on paper so you know which jobs actually need the lockfile in the first place. Most teams add it everywhere just in case because they don't know where the real risks are.

At what point does cron complexity justify moving to a proper job scheduler like Airflow or Temporal?

That's a good rule. The problem is most teams don't notice they've crossed that line until something breaks. By then migrating away from cron feels too risky.

That is why i moved to systemd timers. I can manage relationships and prevent duplicate runs.

Fair point — systemd timers solve this properly. This is for the massive installed base that isn't migrating anytime soon.

Should overlap prevention live at the scheduler level or inside the script with lockfiles?

Lockfiles work but they're opt-in — someone always forgets. Scheduler-level prevention would catch it before the job ever runs. That's the gap this tries to fill at the planning stage.

Honestly? Find out when something breaks. Had a backup job and a DB vacuum running at the same time last year, took down prod for 20 minutes before I figured out what happened. Wish I’d had something like this.

20 minutes of downtime is exactly the kind of thing this was built to prevent. Hope it helps next time.

Reply on news.ycombinator.com