When a cron job misses its window or a queue worker stops processing, the internal team usually finds out first. But customers still need to know what is happening.
That is where a Laravel status page helps. It gives you a simple public place to show that a background job incident is in progress, what part of the system is affected, and when things are back to normal.
Why status pages matter for Laravel apps
Background job failures are often invisible from the outside.
- a billing job stops after a deploy
- a queue worker crashes and retries stall
- webhook delivery backs up for one tenant
- a nightly sync misses its window
To your users, these problems look like missing emails, delayed payments, or stale dashboards. A status page turns that uncertainty into a visible update.
What to show on the page
A useful Laravel status page should stay short and practical:
- what is affected
- when the issue started
- whether cron, queue, or webhook delivery is impacted
- whether the incident is ongoing or resolved
- a link to updates or a support channel
You do not need a giant incident platform to do this well. You need a page that stays up to date when something breaks.
How Crontinel fits
Crontinel includes a built-in public status page - create one from your dashboard, attach the endpoints you want to show (an API health check, a webhook receiver, a background worker), and publish it at a Crontinel-hosted URL or your own custom domain. No separate status-page product to wire up.
It’s driven by the same signals Crontinel already watches:
- missed scheduled runs
- failed cron commands
- queue depth spikes
- worker crashes
- Horizon pause and resume state
- webhook delivery failures
Free includes one status page, Pro adds one per monitored app, and Team is unlimited.
Good status page angles
If you are writing SEO or support copy around this topic, the strongest angles are usually:
- Laravel status page for background jobs
- status page for cron jobs
- status page for queue incidents
- public status page for webhook delivery failures
Those phrases match how teams actually search when they want to explain downtime or delayed work.
If you need a fully custom incident page instead
Crontinel’s built-in status page covers most teams, but if you want a custom incident workflow layered on top, use Crontinel to alert on the background signal and drive your own update process from there.
// Example: a scheduled health check that can drive a status page update
Schedule::call(function () {
// Check critical jobs, queue depth, and webhook delivery health
})->everyFiveMinutes();Pair that with Slack or PagerDuty so your team can update the status page quickly.