Crontinel
Laravel schedule & queue monitoring — catch silent cron/queu
Crontinel is Laravel schedule and queue monitoring built to catch silent cron, queue, and agent failures before users do.
Many teams rely on uptime checks alone. Uptime can stay green while schedule:run is hours late, a Horizon worker has stalled, or a backup job never fired. Crontinel watches the runs that should have happened and alerts when they do not.
Crontinel monitors the Laravel scheduler, Horizon queues, workers, backups, and agent runs. When a scheduled task is late, missed, or fails quietly, you get notified instead of discovering it from customer reports. That focus on expected runs—not just whether a host responds—is the core of the product.
Beyond Laravel, Crontinel also offers Node and Python SDKs so the same monitoring approach can cover adjacent jobs and agents in a mixed stack. The goal is one place to see whether critical background work actually ran.
Crontinel is open core, MIT licensed, with a free tier. You can start monitoring without a large commitment and expand as your schedules and queues grow. Tags that fit the product include Laravel, DevTools, Monitoring, Cron, Queue, DevOps, Open Source, SaaS, and APM.
In short: if silent schedule or queue failure would hurt your users, Crontinel is the watchdog for the jobs that are supposed to run—catching late, missed, and failed work before it becomes a production incident.
Features
Laravel scheduler monitoring
Horizon queue and worker monitoring
Backup and agent run monitoring
Alerts for late, missed, and failed runs
Node and Python SDKs
Open core, MIT licensed, with a free tier
Use Cases
Detect when schedule:run is hours late
Catch stalled Horizon workers
Alert when backup jobs never fired
Monitor mixed-stack Node and Python jobs and agents
Know whether critical background work actually ran
Comments
The framing that uptime can stay green while the work never happened is the right one, and I would push it one step further: the nastiest class is the job that DID run, on time, and had no effect. We shipped a reminder path that recorded "scheduled" every single time, and the log was honest, the job really had run. What it could not know was that the OS notification permission was off, so the alarm it scheduled was physically incapable of firing. Nine of ten users in that state got a clean green trail and nothing on their phone. So my question for the maker: can a monitored run assert an expected effect, not just completion? Something like reporting a count with the heartbeat and alerting when the job succeeds but the count is zero for N consecutive runs. That is the failure people actually discover from customer reports. Second question, from a bug that cost us a release: how do you treat a run that is late because the clock moved rather than because anything broke? A DST shift and a timezone change both silently moved our scheduled work by an hour, which looks identical to lateness. Distinguishing "the schedule moved" from "the worker stalled" would save a lot of false pages. Open core and MIT is a good reason to try it.
Really sharp distinction between server uptime and the work actually ran - that gap is what most monitoring tools miss. Curious how Crontinel handles a changed cron expression: does it auto-detect the new cadence, or does that need a manual update to avoid false missed-run alerts right after a deploy?
Premium Products
Sponsors
Buy
Makers
Makers
Comments
The framing that uptime can stay green while the work never happened is the right one, and I would push it one step further: the nastiest class is the job that DID run, on time, and had no effect. We shipped a reminder path that recorded "scheduled" every single time, and the log was honest, the job really had run. What it could not know was that the OS notification permission was off, so the alarm it scheduled was physically incapable of firing. Nine of ten users in that state got a clean green trail and nothing on their phone. So my question for the maker: can a monitored run assert an expected effect, not just completion? Something like reporting a count with the heartbeat and alerting when the job succeeds but the count is zero for N consecutive runs. That is the failure people actually discover from customer reports. Second question, from a bug that cost us a release: how do you treat a run that is late because the clock moved rather than because anything broke? A DST shift and a timezone change both silently moved our scheduled work by an hour, which looks identical to lateness. Distinguishing "the schedule moved" from "the worker stalled" would save a lot of false pages. Open core and MIT is a good reason to try it.
Really sharp distinction between server uptime and the work actually ran - that gap is what most monitoring tools miss. Curious how Crontinel handles a changed cron expression: does it auto-detect the new cadence, or does that need a manual update to avoid false missed-run alerts right after a deploy?
Premium Products
New to Fazier?
Find your next favorite product or submit your own. Made by @FalakDigital.
Copyright ©2026. All Rights Reserved