scheduled.task
Scheduler stops. Site stays up.
A deploy clobbers your cron entry. The app responds 200. No one fires the scheduler. Your nightly emails stop.
GET /health 200 ok schedule:run · 17h ago
Laravel monitoring · Product preview
Your cron
Your cron
is lying
to you.
Crontinel watches your Laravel scheduler, Horizon queues, workers, backups, and agent runs, so you hear about the failure before your users do. Also works with Node.js and Python.
Laravel-first, SDKs for other languages · open core · MIT licensed · free tier, no card
live.monitor · app.crontinel.com
jobs1,847 latency42ms
heartbeat · every 60s failure · detected in < 60s drift · scheduler out of sync
0s
avg time to detect
a silent cron failure
a silent cron failure
0%
of production apps
run a silently broken job
run a silently broken job
2 cmds
to monitor jobs,
queues, workers & agents
queues, workers & agents
$0/mo
starts at, or
self-host for free
self-host for free
Your Laravel scheduler isn't running. Your dashboard shows green. Crontinel knows.
Uptime checks and status pages only confirm that a URL responds. They never look inside artisan schedule:run or Horizon, so a cron entry a deploy silently removed, a stuck overlap lock, or a queue worker that's technically "running" but not draining anything all still read as a clean, all-green dashboard. Crontinel hooks into the scheduler and queue directly and alerts on the one signal that actually matters: the run that should have happened and didn't.
The gap Your uptime monitor says green.
Your uptime monitor says green.
Your queue disagrees.
A URL responding 200 doesn't mean your cron ran. It doesn't mean your workers are draining. It doesn't mean your invoices queue isn't 6,000 deep, or that your agent isn't looping on a broken tool call. Generic monitors can't tell you any of that.
agent.loop
The agent loops. The bill climbs.
A model retry storm or a tool-call loop runs for 40 minutes. The endpoint returns 200 for every request. You find out from billing.
api.status 200 ok agent.run.874 42m · 318 tool calls
worker.crash
Worker crashes. Queue is dead.
A worker process died. Your queue manager shows "running" because one worker is still up. Your billing queue is dead. No errors. No alerts. Just silence.
queue.manager running worker.emails · crashed
Everything uptime tools miss Paranoid monitoring,
Paranoid monitoring,
without the instrumentation.
One SDK hooks into your scheduler, queue driver and agent runner. It watches job runs, queue depth, worker state, model latency and agent tool calls, end to end. No endpoint pings. No per-task wrapping. No missed instrumentation.
Workers & supervisors
See the worker, not just the URL.
Per-worker status, paused detection, queue depth trend, failed job rate. Monitor every worker type - the moment one blinks, you know.
Heartbeat
60-second detection.
Every scheduled task registers a run attempt, exit code, and duration. Missed runs trip an alert before the next cron tick.
pulse 60s
No per-task instrumentation.
Hooks into your framework's events, not your code.
Works offline. MIT.
OSS first. Local dashboard, CLI, no SaaS needed.
Alerts
Route once, quiet forever.
One alert fans out to the channels your team actually watches - per-service routing, quiet hours, auto-resolve.
Slack PagerDuty Webhook Email
CI/CD
crontinel:check in your deploy hook.
One command verifies scheduler, supervisors and queues after each deploy. Zero-downtime monitoring that fails loud.
$ crontinel check ✓ scheduler last run 00:00:12 ago ✓ workers.default 2 supervisors · running ✓ queue.invoices 127 pending · 2m oldest ✓ agents.support 12 runs · p95 8.2s ✗ queue.emails backpressure · 6,413 pending
Agents & models
Monitor the agent like any other worker.
Track runs, tool calls, token spend, model latency and loop detection. Ask via MCP, so your own agent can answer "are any queues or agents backing up?" with real data.
› are any queues backing up?
Yes · emails is at 6,413 and rising. Oldest job 12m 04s. invoices is healthy.
How it works Two commands.
Two commands.
One source of truth.
01 · INSTALL
One SDK, your stack
Drop the SDK in. No scheduler wrapping. No per-job decorators. No changes to existing jobs.
# pick your runtime $ npm i @crontinel/node $ pip install git+https://github.com/crontinel/python.git $ go get github.com/crontinel/go $ gem install crontinel $ composer require crontinel/laravel $ dotnet add package Crontinel
02 · ROUTE ALERTS
Pick a channel
Slack, PagerDuty, email, webhook. HMAC-signed payloads. Quiet hours. Route once, in .env.
# .env CRONTINEL_ALERT_CHANNEL=slack CRONTINEL_SLACK_WEBHOOK=...
03 · SLEEP
Listen instead of watch
We read scheduler events, worker state, queue internals and agent traces. When something drifts, you hear from us, not a user.
# ci/cd deploy hook $ crontinel check ✓ 47 jobs · 3 workers · 2 queues · 4 agents
The dashboard Not a heartbeat ping chart.
Not a heartbeat ping chart.
The inside of your queue.
Every scheduled task with its last run, duration and exit code. Every worker with its state. Every queue with depth, oldest job, and failure rate. Every agent run with its tool calls and token spend.
app.crontinel.com/apps/invoice-processor
invoice-processor
production · eu-west-1 1 alert Setup Monitors History Settings
schedule runs / 24h
1,447
+2.1% vs yesterday
avg run time
842ms
−120ms vs p50
queue depth · total
241
healthy
failed last 1h
12
+12 vs 0
Scheduled tasks14 tasks
| Task | Last run | Duration | Status |
|---|---|---|---|
| generate:daily-invoices | 2m ago | 1.82s | ok |
| dunning:send-reminders | 14m ago | 940ms | ok |
| sync:stripe-webhooks | 17m ago | ... | exit 1 |
| export:accounting-feed | 29m ago | 4.1s | ok |
| telemetry:roll-up | 1h 02m ago | 12.4s | slow |
| cleanup:stale-sessions | 3h ago | 220ms | ok |
Workers · 3 supervisorsrunning
| Queue | Depth | Oldest | Trend |
|---|---|---|---|
| default | 12 | 200ms | |
| invoices | 127 | 2m 04s | |
| emails | 6,413 | 12m 04s | |
| analytics | 88 | 400ms | |
| notifications | 3 | 80ms | |
Routed, not noisy
Alerts go where you listen.
Native · shipping
Slack PagerDuty Email / SES Webhook · HMAC MCP · any agent
Coming soon
Opsgenie Linear Zapier
Trusted by developers worldwide
- developers
MIT open-source license
Free plan available
Pricing Start free.
Start free.
Paid plans are being prepared.
We are checking paid billing and usage limits before opening paid signups.
Free
For one app.
$0/mo
- 1 connected app
- 5 monitors per app
- 7 days of cron run and monitor event history
Paid plans
Starter, Pro, and Max are planned.
Their checkout flow and final usage terms are still under review.
See current availability Open by default
A family of open-source packages.
Crontinel is SDKs and a CLI, not a vendor lock-in. Every runtime has its own MIT-licensed package that works against your own database. The cloud dashboard is an option layered on top, not a dependency.
TS
crontinel/node
Queue & scheduler auto-detection for Node runtimes.
PY
crontinel/python
Queue & scheduler auto-detection for Python runtimes.
GO
crontinel/go
Queue & scheduler auto-detection for Go runtimes.
RS
crontinel/rust
Queue & scheduler auto-detection for Rust runtimes.
PHP
crontinel/php
Queue & scheduler auto-detection for PHP runtimes.
LA
crontinel/laravel
Queue & scheduler auto-detection, zero wrap.
RB
crontinel/ruby
Queue & scheduler auto-detection for Ruby runtimes.
RA
crontinel/ruby-on-rails
Queue & scheduler auto-detection for Rails runtimes.
RS
crontinel/crontinel
Rust core. The recorder, agent and shared wire format.
SH
crontinel/cli
Language-agnostic. Wrap any cron, Docker, or K8s job.
C#
crontinel/dotnet-sdk
Queue & scheduler auto-detection for .NET runtimes.
AI
@crontinel/mcp-server
MCP server. Let your agent query jobs, queues and runs.
Self-hosted or fully managed?
The open-source package is free forever. The SaaS adds the things you would have to build yourself.
Self-hosted free, MIT
- Full queue and cron visibility
- Blade dashboard on your own server
- Slack alerts built in
- Your data, your infra
- No hosted dashboard
- No team access or roles
- 7-day history max
- You manage the server
Crontinel SaaS
- Everything in the open-source package
- Hosted dashboard at app.crontinel.com
- Team access with roles
- Up to 1-year run history
- Multi-app overview in one place
- PagerDuty, webhooks, status pages
- REST API and MCP server access
- Zero server management
Hosted · app.crontinel.com
Crontinel Cloud
Everything the OSS packages do, plus multi-app dashboards, team access, long-horizon history, an MCP server, and routing rules. You keep the self-hosted SDKs; we handle the rest.
- ✓ Multi-app view & search
- ✓ History retention (90d → 1y)
- ✓ Team access, audit log, SSO (soon)
- ✓ MCP server for agents
Prefer to self-host? Every package is free forever.
MIT licensed. Every SDK works standalone - Blade dashboard, CLI health check, Slack alerts, queue and cron monitoring. No SaaS required. Own your data.
npm i @crontinel/node pip install git+https://github.com/crontinel/python.git go get github.com/crontinel/go composer require crontinel/laravel gem install crontinel Install
Two commands. No pings.
$ npm i @crontinel/node
$ npx crontinel init
$ npx crontinel check # add to your CI
$ pip install git+https://github.com/crontinel/python.git
$ crontinel init
$ crontinel check # add to your CI
$ go get github.com/crontinel/go
$ go run github.com/crontinel/go/cmd/crontinel init
$ crontinel check # add to your CI
$ cargo add crontinel-rust
$ cargo install crontinel-cli
$ crontinel check # add to your CI
$ composer require crontinel/php
$ composer require crontinel/laravel # or for PHP
$ vendor/bin/crontinel check
$ brew install crontinel/homebrew-tap/crontinel
$ curl -sSL https://raw.githubusercontent.com/crontinel/cli/main/install.sh | sh
$ crontinel check # add to your CI
$ gem install crontinel
$ crontinel init
$ crontinel check # add to your CI
$ gem install crontinel-rails
$ rails generate crontinel:install
$ bundle exec crontinel check # add to your CI
Learn more
Start with the pages people actually search for.
If you're comparing tools or looking for a specific failure mode, these are the strongest pages on the site.
Cron vs queue monitoring
See what cron monitoring covers, what queue monitoring covers, and why you need both in production.
Cron Monitoring Guide Complete guide to detecting missed runs, silent failures, worker stalls, and queue backpressure.Worker & supervisor monitoring
Track paused supervisors, queue depth, and failing workers before the backlog becomes customer visible.
Webhook monitoring for API teams
Catch delivery failures, retry storms, and stalled callback queues before customers notice.
Cron heartbeat monitoring
Catch the moment schedule:run stops arriving, runs late, or silently skips a job.
Incident alert system
Route the right failures to Slack, PagerDuty, or webhooks without drowning the team in noise.
Open source and self hosted status pages
Publish a simple public incident page for cron, queue, and webhook problems you control.
Ready? Stop finding out
Stop finding out
from your users.
Free plan, no credit card. Two commands to install. Slack alert in under five minutes.