Service status and incident communication tools for keeping users informed about uptime, outages, and maintenance. All available with one-click installation on 365i web hosting.
A status page is the page your customers load when your service won't load. It lists your components, shows whether each one is up, and carries the incident updates people would otherwise be phoning about. Atlassian's Statuspage is the reference product, running from a free tier through US$29, $99 and $399 a month up to $1,499 at Enterprise. Better Stack, Instatus and Status.io sell variations on the same idea.
Here's the part most pages about self-hosted status software leave out. Install a status page on the same hosting as the service it reports on, and the outage that takes the service down takes the status page with it. That isn't a theoretical failure mode, it's the normal one. A status page has exactly one job, which is to work at the moment nothing else does, and hosting it next to the thing it monitors is the single arrangement guaranteed to defeat that job.
Self-hosting can still be the right call. It's right when the page lives somewhere else: a separate hosting package, a different provider, a different region, with DNS for the status subdomain held apart from your production zone. Cachet, the application in this category, is a perfectly reasonable thing to put in that separate place. It just must not live next door.
Situations we see often. If one of these sounds like you, this category is worth a look.
A studio supports a dozen client applications on infrastructure it does not control end to end, and wants one page for planned maintenance windows. Put that page on a small hosting package with a different provider from the systems it reports on, and it survives their bad days.
A finance or logistics team needs to tell 200 internal users when a nightly batch run is delayed. Subscriber notifications are the expensive feature on commercial plans and cost nothing on a self-hosted install.
Statuspage steps from US$29 to $99 a month at the 1,000 subscriber mark, which is a real line item for an early product. A self-hosted page on an entry hosting plan does the same job for the price of the hosting.
Some contracts require a durable, timestamped record of outages and exactly what was communicated to whom. Holding that in your own database, backed up daily, is easier to evidence than exporting it from a vendor when someone asks.
It's easier to rebuild than it is to upgrade at this point.
That is the maintainer being straight about his own project, and it explains where things stand now. Cachet 2.4.1 shipped in November 2023 and nothing has followed it while version 3 is rebuilt on Laravel. Deploy 2.x knowing it is frozen rather than improving, and put a date in the calendar to review the situation.
Your page should be hosted on separate infrastructure and a distinct domain, like status.yourcompany.com, to ensure it remains available even if your primary application is down.
A simple rule that gets broken constantly. If you self-host with us, the working version is a separate hosting package in a different data centre from the service being reported on, with the status subdomain's DNS somewhere else again. Sharing a package with the production site quietly cancels the whole exercise.
A status page has one job: be up when the rest of your stack is not. We host status pages on completely separate infrastructure from any application they monitor, with a different DNS provider where the customer wants belt and braces, and we make sure the page is light enough to serve from CDN edge cache without hitting the origin during an incident. Outbound SMTP for incident notifications gets configured at install with proper authentication.
Where Cachet actually stands. The last tagged release is 2.4.1, dated 7 November 2023. Version 3 is a rebuild on Laravel, and its own installation guide states that it "is currently in development and not yet released". So today's choice is a frozen 2.x that works, or a development branch carrying no stability promise. Neither is a disaster, and both are worth knowing before you hang a customer-facing page on it.
From a hosting point of view it's an ordinary Laravel application. It wants Composer, a database, a cron entry running the scheduler every minute, and a queue worker for outbound subscriber notifications. Cron is available on our plans. A long-running queue worker under supervisor is the part that suits a managed cloud server better than shared hosting, and without one, notification email queues up rather than going out.
Skip self-hosting entirely if your status page is a contractual obligation with an uptime target attached, or if nobody will remember to update it at two in the morning. A page left stale during an incident is worse than no page at all, because it tells customers everything is fine while they're watching it not be.
Common questions we hear from people running status page system applications on 365i hosting.
Anywhere other than the infrastructure it reports on. A separate hosting package is the minimum, a different data centre is better, and a different provider better still. Point the status subdomain at it using DNS held outside your production zone, so a DNS problem on the main domain does not take the status page down as well. We have data centres in the UK, US and Asia, so putting the status page in a different region from the service is a choice you make at signup.
Yes, though not in the way you might assume. The 2.x branch has had no release since 2.4.1 in November 2023, and effort is going into a version 3 rewrite that the project's own documentation describes as in development and not yet released. If you want a status page you can install today and largely forget, 2.4.1 works and is what most self-hosted Cachet installs are running. Just do not plan around new features arriving on a schedule.
For a lot of teams, yes. Statuspage has a free tier covering 100 subscribers, 25 components and 2 team members, which is more than plenty of small services need, and it runs on infrastructure entirely separate from yours by default. Paid tiers open at US$29 a month. Self-host when the subscriber limits start to bite, when you want the incident history in a database you own, or when you need branding and layout the hosted product will not do.
No, and neither does Statuspage out of the box. Cachet displays the status you or your monitoring tools tell it, through the dashboard or the API. That is the right design, because a status page guessing from its own checks will sooner or later contradict what your engineers know. Wire a monitoring service into Cachet's API so component states update without anyone logging in, and keep the written incident updates manual, since those are the ones customers actually read.
PHP with Composer, a database (MySQL, MariaDB, PostgreSQL and SQLite all work), a cron entry running the Laravel scheduler once a minute, and ideally a queue worker for outbound notifications. The 3.x branch asks for PHP 8.3 or newer. Cron is included on our plans and PHP version is selectable per package in the My365i control panel. If you want a persistent queue worker managed by supervisor, that belongs on a managed cloud server rather than a shared plan.
Separate it at every layer you can afford to separate. Different hosting package, different region, DNS for the subdomain hosted apart from your main zone, no shared database. Keep the page itself dull: static assets, no calls out to your production API, no dependency on the login system that might be the very thing that broke. Then test it properly by pretending your main site has gone and confirming the status page still renders and still updates.
Get Status Page System apps up and running in minutes with our fast, reliable web hosting. Every plan includes one-click installation, free SSL, UK, US & Asia data centres, and dedicated expert support.
All prices exclude VAT. No contract, cancel any time.
All 1 status page system applications available with one-click installation on our fast UK web hosting.
