Cachet
Open-source status page system for communicating outages
Cachet is an open-source status page system written in PHP (Laravel) for communicating downtime and incidents. It supports components, incident timelines, scheduled maintenance windows, metrics, and subscriber notifications.
Key features
- Public status page
- Incident timeline updates
- Scheduled maintenance windows
- Subscriber notifications
Pros & cons
Strengths
- Polished public-facing page
- REST API
Trade-offs
- Development has been intermittent
- Needs a database
Cachet replaces
Last reviewed Aug 26, 2026 · 775 words
Cachet does not check whether anything is up. It is a status page: components with a colour, incidents with a timeline, scheduled maintenance windows, metrics graphs, and subscribers who get an email when you post an update. Something else has to decide a component is down and tell Cachet through the API. That single fact sorts most readers: if you want one tool that both monitors and publishes, Uptime Kuma ships a status page and will suit 9 homelabs in 10. Cachet is for the tenth case, where the page is public, an audience needs to subscribe to incidents, and you want to write the incident narrative yourself rather than show a red dot.
Reporting and checking are different jobs
A monitor answers "is it responding to my probe". A status page answers "what do we know, what are we doing, when did it start". The second is a communication tool, which is why Cachet's data model is built around incidents with statuses of Investigating, Identified, Watching and Fixed, each with a timestamped message, rather than around probes. For a shared service with users who are not you, a rented server for a club, a small SaaS, a community Minecraft server with 40 players, that narrative is the product. For your own Jellyfin, it is theatre.
Host it where your outage cannot reach it
A status page on the same box as the services it describes goes down with them, which is the one failure it exists to explain. Cachet is a PHP Laravel application with a MySQL or PostgreSQL database, and 256 MB of RAM is enough, so the cheapest VPS at a different provider in a different region is the correct home, with its own domain or a subdomain whose DNS does not depend on your main infrastructure. Run it in Docker behind Caddy, give it an outgoing SMTP account for subscriber mail, and resist adding anything else to that box.
Feed it from Uptime Kuma or Gatus through the API
Components carry a status from 1 to 4: Operational, Performance Issues, Partial Outage, Major Outage. Updating one is a single authenticated call:
curl -X PUT https://status.example.com/api/v1/components/3 \
-H "X-Cachet-Token: your-api-token" \
-d status=4
Neither Uptime Kuma nor Gatus has a native Cachet target at last check, so the glue is a webhook receiver or a script: point the monitor's webhook notification at a 20-line handler that maps down to 4 and up to 1, or run a cron job that polls the monitor's API and updates components every minute. Keep incident creation manual. Automated incidents produce "Investigating" posts at 3 a.m. that nobody investigates, and subscribers unsubscribe. The status pages post walks through the plumbing options in more detail.
Subscribers and maintenance windows are the reason to bother
Subscribers verify by email and receive a message on each incident update, which is the feature Uptime Kuma's page lacks and the reason a public service owner picks Cachet. Scheduled maintenance windows appear on the page in advance, notify subscribers, and flip the component for the duration, which turns "the server will be down Sunday" from a forum post into something people actually see. Metrics are the weakest part: they graph numbers you post via the API, and a Grafana public dashboard does that better if you already have one.
The long 2.x-to-3.x gap
Cachet has been around since 2014, and its 2.x series was for years the default self-hosted status page. Development then stalled for a long stretch, which is why the catalogue notes it as intermittent, before the maintainer restarted the project as a 3.x rewrite on a current Laravel. Before installing, read the releases page and decide which series you are deploying: 2.x has the most third-party integrations and tutorials, 3.x has a modern codebase and an active future. Do not install 2.x expecting to migrate painlessly later; treat them as different products with the same name.
What I'd do
For a homelab: Uptime Kuma, its built-in status page, and no Cachet at all. For anything with an audience that is not you: Cachet 3.x on a 5-dollar VPS at a second provider, subscribers enabled, components updated by a small webhook receiver fed from Gatus, incidents written by a human. Post a maintenance window every time you take something down, even for 10 minutes. The page's value is entirely in the habit of using it.
Compare Cachet
8 head-to-head comparisons.
Similar monitoring & status apps
Uptime Kuma
Monitoring & StatusEasy self-hosted uptime monitoring tool
Replaces Pingdom, UptimeRobot
Netdata
Monitoring & StatusReal-time per-second infrastructure monitoring
Replaces Datadog, New Relic
Grafana
Monitoring & StatusOpen observability dashboards and visualization
Replaces Datadog
Prometheus
Monitoring & StatusMetrics-based monitoring and alerting toolkit
Replaces Datadog
Glances
Monitoring & StatusCross-platform system monitoring at a glance
Replaces Datadog
InfluxDB
Monitoring & StatusPurpose-built time series database for metrics and events
Replaces Datadog, AWS Timestream