4 ms·
Show HN: ConfigClarity – Visualize cron overlaps before they crash your server
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 https://configclarity.dev
- metriclogic 7mo agoHappy 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?
- keerti_ece 7mo agoHonestly? 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.
- metriclogic 7mo ago20 minutes of downtime is exactly the kind of thing this was built to prevent. Hope it helps next time.
- karthik291193 7mo agoHow 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.
- metriclogic 7mo agoSingle 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.
- stop50 7mo agoThat is why i moved to systemd timers. I can manage relationships and prevent duplicate runs.
- metriclogic 7mo agoFair point — systemd timers solve this properly. This is for the massive installed base that isn't migrating anytime soon.
- ramesh9900 7mo agoAt what point does cron complexity justify moving to a proper job scheduler like Airflow or Temporal?
- metriclogic 7mo agoThat'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.
- akhila0000 7mo agoShould overlap prevention live at the scheduler level or inside the script with lockfiles?
- metriclogic 7mo agoLockfiles 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.
- shrinath1 7mo agoWe 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.
- metriclogic 7mo agoLockfiles 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.