When teams search for an open source status page or a self hosted status page, they are usually trying to solve the same problem: they want a public incident page they control.
For Laravel apps, that page usually needs to explain delayed cron jobs, queue backlogs, or webhook delivery issues without making customers guess what happened.
Why status pages matter
A status page is not just for outages. It is the easiest way to communicate when background work is delayed but the site is still technically up.
Examples:
- invoices were queued but not sent yet
- nightly exports are late
- webhook retries are backed up
- a deploy paused Horizon longer than expected
Without a status page, the support team has to answer the same question over and over. With one, you can publish a clear update once and point everyone to it.
What makes a good Laravel status page
A useful status page should stay short and specific:
- current incident summary
- when it started
- what is affected
- whether cron, queue, or webhook delivery is impacted
- when the issue was resolved
That is true whether the page is open source, self hosted, or both.
If you don’t need full self-hosting
Crontinel includes a built-in public status page (Free: 1 page, Pro: 1 per app, Team: unlimited) with a custom-domain option, so most teams don’t need to build one at all. The DIY approach below is for teams that specifically need to control where the page runs and where incident data lives - regulated environments, or engineering teams that want to own and extend the tooling directly.
How Crontinel feeds the page
Crontinel already knows the signals that matter:
- missed scheduler heartbeats
- failed scheduled commands
- queue depth spikes
- worker stalls
- Horizon pause state
- webhook delivery failures
Those signals are enough to drive a simple public page or to trigger an internal incident note before you update customers.
Open source vs self hosted
People often search for these phrases together, but they are not identical.
- Open source means the code is visible and auditable.
- Self hosted means you control where the page runs and where the data lives.
For regulated teams, the self hosted part matters because it keeps incident data close to the app. For engineering teams that want to inspect or extend the tooling, open source matters because it makes the workflow transparent.
A simple incident page shape
A practical Laravel status page can be very small:
- one headline for the current state
- one paragraph for the current incident
- a timeline of updates
- a link back to your support or docs page
You do not need a giant status platform to do that well. You need a reliable source of truth for incident state.
How to connect it to Crontinel
A common setup is:
- Crontinel detects a missed heartbeat or failed job
- Your alert routing sends a Slack or webhook notification
- Your incident workflow updates the status page
- Customers see the same message your team sees
That gives you a single operational source of truth instead of scattered messages across chat, email, and support tickets.