A status page on your own servers is offline for exactly the event it exists to explain. Hosting it elsewhere is not a nice-to-have — it is the entire point of having one.
From $5 a month · No check quotas · Set up in under a minute
What is a hosted status page?
A hosted status page is a public page showing the current state of your services, run on infrastructure separate from the systems it reports on. That separation is what makes it useful: when your servers go down, the page explaining the outage is unaffected, because it was never running on them. MonitoringDaddy includes hosted status pages on every plan, with custom domains, branding and password protection available.
When a service goes down, your support load spikes before your monitoring alert has finished sending. Every customer independently discovers the problem, and every one of them contacts you to report the thing you already know. A status page absorbs that: one page, updated once, answering the question everyone is about to ask.
The catch is where it runs. A status page self-hosted on the same infrastructure as the product is a page that returns a connection error during the incident, which is the single moment its entire value is realised. Hosted status pages exist because independence from your stack is the requirement, not a convenience.
Three jobs, all of which get harder the longer an incident runs without one.
Without a status page, every affected customer files a ticket. With one, most check the page and wait. Your team spends the outage fixing the problem instead of answering the same question fifty times.
If you are not saying anything, customers fill the silence — on social media, in your competitors' mentions, in their own internal Slack. A page you update is a version of events you own.
Customers largely forgive downtime. They do not forgive being kept in the dark about it. A visibly maintained status page with honest incident history reads as competence; silence reads as either incompetence or concealment.
Publish the page before you need it. A status page created during an incident is one more task during the worst possible hour, and customers cannot find a URL they have never seen.
Serve the page from a subdomain you control, such as status.yourcompany.com, so it reads as part of your brand rather than a third-party URL.
Add your logo and favicon, and apply custom CSS and JavaScript to match your design system.
Pull status directly from your monitors, so the page reflects what checks actually observed rather than what someone remembered to update.
Post incidents and updates so visitors see what is happening and what has been done, with a history that persists afterwards.
Restrict a page to a specific audience with a password — useful for internal services or per-client pages that should not be public.
Set meta title and description, or mark a page noindex to keep it out of search results entirely.
This is the decision that determines whether the page works when it matters.
If full control matters more than availability during an incident, self-hosting is legitimate — see the self-hosted status page guide. For everyone else, the page needs to outlive the thing it reports on.
| Self-hosted | Hosted | |
|---|---|---|
| Available during your outage | No — shares fate with your infrastructure | Yes — runs independently |
| Available during a datacentre failure | No, if it is in the same facility | Yes |
| Setup effort | Server, TLS, deployment, monitoring of the status page itself | Minutes, nothing to run |
| Ongoing maintenance | Yours — patching, upgrades, certificate renewal | None |
| Custom domain | Yes | Yes |
| Cost | Server plus your time | Included on all plans |
| Full control of the stack | Yes | No — you configure, we run it |
Give it a name and a slug, and choose which monitors it reports on.
Add a subdomain such as status.yourcompany.com and point it at the page so it lives under your brand.
Upload a logo and favicon, set the meta title and description, and add custom CSS if you have a design system to match.
Put the URL in your footer, help centre and support auto-replies — before an incident, while people are calm enough to notice it.
Status pages here are for communicating status. They are not an incident-management platform, and teams needing on-call workflow should pair them with a dedicated tool.
Customers cannot check a page they have never been shown. Put the link in the footer, the help centre and support auto-replies while nothing is wrong.
"We are aware of an issue affecting logins and are investigating" is worth more than an accurate explanation forty minutes later. Silence is what customers interpret badly.
Post every twenty or thirty minutes even when the update is "still investigating". Predictable updates stop people refreshing and start them waiting.
Incident history that only shows good months is obviously curated and destroys the credibility of everything else on the page. The archive is the trust signal.
Custom domain aside, the page must not depend on your application, database or datacentre. That independence is the product — see uptime monitoring for what feeds it.
Publish a branded status page on your own domain, hosted independently of your infrastructure.
Name the page, choose a slug, and select which monitors it should report on.
Add a subdomain such as status.yourcompany.com so the page is served under your own brand.
Upload a logo and favicon, set the meta title and description, and add custom CSS to match your design system.
Add the URL to your site footer, help centre and support auto-replies before an incident happens.
Typically about 10 minutes from start to finish.
Uptime monitors, watched pages and heartbeats each get their own allowance, so adding a page watch never costs you a monitor. SSL and domain checks ride along with the monitor they belong to and use nothing extra.
| Plan | Monitors | Watched pages | Heartbeats | Fastest interval | Alert channels | Price |
|---|---|---|---|---|---|---|
| Free | 1 | 1 | 1 | Every 30 minutes | 1 email address | $0 |
| Founding Member first 20 only | 25 | 25 | 25 | Every 5 minutes | Email + webhook & chat | $5/mo |
| Basic | 10 | 10 | 10 | Every 10 minutes | Email + webhook & chat | $8/mo |
| Growth | 50 | 50 | 50 | Every 5 minutes | Email + webhook & chat | $19/mo |
| Pro | 100 | 100 | 100 | Every 60 seconds | Email + webhook & chat | $34/mo |
Annual billing is cheaper on every paid tier. The pricing page is the authoritative list.
Every recorded change is compared word by word and kept with a before-and-after image. This is the real output, shown with worked example data.
Price fell from $49 to $39, and an annual discount was added.
The item is available again and the basket button returned.
A new subprocessor was added in another jurisdiction.
The free plan sends to one email address. Every paid plan adds the chat and webhook channels below, with 2 to 10 destinations depending on the plan. However many alerts you receive, the price does not change — nothing here is metered or charged per alert.
There are no voice calls and no SMS. If a phone call at 3am is a hard requirement, say so before you subscribe — we would rather tell you now than refund you later.
A public page showing the current state of your services, run on infrastructure separate from the systems it reports on. That separation is the point: when your servers fail, the page explaining the outage is unaffected because it never ran on them.
Because it shares fate with your infrastructure. A status page on the same servers, or in the same datacentre, is offline during exactly the incident it exists to explain. If control matters more than availability, self-hosting is a legitimate choice — see the self-hosted guide.
Yes. Point a subdomain such as status.yourcompany.com at the page so it appears as part of your brand rather than a third-party URL.
Yes, a status page is included on every plan including free. Customisation — logo, favicon, custom CSS and JavaScript — requires a paid plan.
Yes, on paid plans: logo, favicon, custom CSS and custom JavaScript, plus meta title and description control.
Yes. Pages can be password protected, which is useful for internal services or per-client pages that should not be publicly visible. You can also mark a page noindex to keep it out of search results.
It reflects the status of the monitors you attach to it, so it shows what checks actually observed. Incidents and written updates are posted by you, which is the part customers value most during an outage.
Not currently — there is no subscriber email or SMS notification feature. Visitors check the page, so linking it prominently before an incident matters more than it would otherwise.
One on the free plan, 5 on Basic, 20 on Growth and 50 on Pro. Agencies typically run one per client, which is what the higher counts are for.
No. There is no on-call scheduling, escalation policy or acknowledgement workflow here. This is the communication layer; pair it with a dedicated on-call tool if your team needs rotations.
Last updated August 4, 2026 · Written by Amit Gupta, founder of MonitoringDaddy
A status page created during an incident is one more task in the worst possible hour. Set one up now, free, in under ten minutes.