Monitoring & Status
A status page your customers trust — and one your team can work from.
A branded public page built from the checks you already run, so there is no status to update by hand. Your own domain with automatic HTTPS, badges and a live widget for anywhere else, email subscribers handled properly, and every incident at a permanent address you can paste into a ticket. Then the part nobody else ships: the same page again, behind your sign-in, with the on-call contact, the runbook links and the per-service matrix the responder actually needs.
Free plan · No credit card · Publish a page in 5 minutes
- Built from your monitoring — no status to update by hand
- A private team view with on-call and runbooks, one click away
- Every incident at a permanent link you can paste into a ticket
- Your own domain, with the CNAME created for you
- Badges and a live widget for your README, docs or footer
Northwind Cloud Status
status.northwind.example
Major outage
Checkout & payments is down
Scheduled maintenance this weekend
We'll be upgrading our database cluster on Saturday 02:00–03:00 UTC. Brief API slowdowns are possible; no downtime is expected.
Public
Developer
Get notified
6 of 8 services up · 100% 90-day uptime · 3 subscribers·Powered by InfraNest
The same status page, written for the people fixing it
Your status page is written for your customers. It answers one question — is something broken — and deliberately answers nothing else, which is right, and which makes it useless to the person who has just been paged. So there is a second view of the same page, inside InfraNest behind your normal sign-in, one click away. It opens with overall status, how many services are up, thirty-day uptime and when the next maintenance window starts. Under that: who is on call, in free text, because a rota is its own product and what teams actually keep there is a name, a number and a channel. Then every incident running right now, each linking to the public write-up — because that is the URL the responder pastes into the ticket. Then the services, grouped exactly as your customers see them, with uptime bars, when each was last checked, and a Runbook button for the ones you have written a runbook for. It refreshes itself every thirty seconds, so it can be left open through an incident.
- On call, runbook links and the per-service matrix — none of it on the public page
- Runbooks are per service, not per page: the responder wants the document for the thing that is down
- Open incidents link to the public write-up, which is the link that ends up in the ticket
- None of it reaches any public payload — enforced by a whitelist and two tests, not a filter someone has to remember
- Someone who knows your page’s password sees the public page and nothing more
What your team needs during an incident. Only people signed in to your organisation can see this page.
Overall
Major outage
Services up
6/8
Uptime · 30d
100%
Next maintenance
—
On call
Primary: Sam Okoye · +31 6 12 34 56 78 · #northwind-oncall on Slack. Escalation after 15m: Alex Rivera.
Open right now
Services · last 30 days
Public
Developer
Refreshes itself every 30 seconds, so it can be left open through an incident. The on-call note and the runbook links never reach any public payload — enforced by a whitelist and two tests, not by a filter someone has to remember.
Every incident gets its own permanent address
An incident on most status pages exists for as long as the incident does. Then it scrolls off, and the link you pasted into a ticket three days ago now lands on a page saying everything is fine. Here each one has a permanent URL of its own — status.yourcompany.com/incidents/482 — and the reader lands on that one incident: what it affects, when it started, how long it ran, and every update in order. It keeps working after the incident is resolved, which is the whole point, because your status page stops talking about an outage the moment it is over and the ticket you sent it in stays open a good deal longer. It outlives the history window too: that window governs how long a list should be, not how long a link should work. At the foot it says how the problem was found — usually that monitoring caught it, and from how many regions — read back from the probes that actually saw it, so an old incident whose probe data has been pruned says less rather than inventing a number.
- A permanent link per incident, still working long after it is resolved and after it leaves the history window
- The full update timeline in order — investigating, identified, monitoring, resolved
- How it was detected, and from how many regions, read back from the probes that saw it
- On your own domain the incident URL carries no slug, and that is the address used in subscriber emails
- A password-protected page asks for the password before naming the incident — the title does not leak
← Back to status
Affected service
Checkout & payments — HTTP 503 — Service Unavailable
Updates
- InvestigatingWe are seeing elevated 503 responses on the checkout endpoint and are investigating.
Detected automatically by our monitoring.
Permanent link. Paste it into a ticket and the reader lands on this one incident. It keeps working after the incident is resolved, and after it has dropped off the history window.
Built from the monitoring you already run
There is no second copy of the truth here and nothing to remember to update. Each service on the page is backed by one of your monitoring checks, so its status is whatever that check last said — and when a check goes down the page changes on its own, along with the banner at the top. Services are arranged into the groups you choose, so the page reads as a service list rather than a check list, and the public name is yours to pick: the monitor can be called “App — northwind-app.dev” while the page says “Web app”. Which checks appear is an editorial decision and stays one. A status page is a choice about what an audience is told, not a dump of everything you watch, so the certificate, redirect and database-port checks can stay internal. You can add third-party services you depend on alongside your own, which is how “is it you or is it Stripe?” gets answered on the same page instead of in your inbox.
- One monitoring check behind each service, so the status is never typed in
- Groups you choose — “Website”, “API”, “Email” — so it reads as a service list
- Publish some checks and keep others internal; the page is an editorial choice
- Third-party dependencies listed alongside your own services
- Planned maintenance shows as planned, not as downtime, so a scheduled window does not dent your uptime story
Drag to reorder. Each component reflects the status of a linked monitor.
| Shown as | Link to monitor | Status |
|---|---|---|
| WebsitePublic | Marketing site | Operational |
| Web appPublic | App — northwind-app.dev | Operational |
| Checkout & paymentsPublic | Checkout flow | Major outage |
| Sign-upPublic | Signup page copy | Operational |
| DocumentationPublic | Docs | Operational |
| APIDeveloper | API health | Operational |
| Search APIDeveloper | Search API | Degraded performance |
| Outbound emailDeveloper | Mail — SMTP | Operational |
8 services published, 4 checks kept internal. A status page is a decision about what an audience is told, not a list of everything you watch — so the certificate, redirect and database-port checks stay off it.
Make the page yours, without forking a template
Logo, header image, footer text and link, and your organisation’s accent colour — taken from your org-wide brand so it stays consistent everywhere rather than being set again per page. Two layouts: one column, which is right for most pages, or two, with services on the left and maintenance and the subscribe form beside them — worth switching to when a long service list has pushed the subscribe form thousands of pixels down where nobody finds it. Both show exactly the same information; nothing is added, hidden or reworded, only moved. Whatever the layout, anything wrong right now stays full width at the top: a layout may rearrange a page, it may not demote an outage into a sidebar. Light, dark or auto, and auto keeps following — a visitor whose device switches to dark at sunset sees the open page re-theme itself. Roomy or compact spacing, where compact changes spacing only and never hides a service, so an outage cannot be tightened out of sight.
- Every option is a setting with a live preview — no template to fork and no designer needed
- One column or two; both show the same information, and neither can push an outage into a sidebar
- Light, dark or auto — and auto keeps following the visitor’s device, not just at first load
- Compact spacing changes spacing only: it never hides a service and never removes a section
- A history window of 30, 60 or 90 days, governing the uptime bars and the incident list together
Layout
Both layouts show exactly the same information. Only the arrangement changes.
Colour scheme
Auto follows each visitor’s own device setting.
Spacing
History shown
Accent colour
Taken from your organisation’s brand colour.
Live preview
Every option is a setting with a live preview — no template to fork. Whatever the layout, anything wrong right now stays full width at the top — a layout may rearrange the page, it may not demote an outage into a sidebar.
Your own domain, and we will set the record up for you
Point status.yourcompany.com at us with a CNAME and the certificate is obtained and renewed automatically. If that hostname sits under a DNS zone you already manage in InfraNest, on a provider that accepts writes, you do not even do that: “Set it up for me” creates the CNAME itself and starts verification, with no trip to the registrar. Verification runs in the background with a Check now button beside it, and the routing that makes the domain work is rebuilt from the database on every deploy and hourly as a safety net — so a missing route is temporary and self-correcting rather than a support ticket. Once it is live the page gets clean incident URLs with no slug in them, and that is the address used in the canonical tag and in the emails your subscribers receive. Renaming a page keeps the old URLs working, with one exception that is deliberate: if another page has since claimed that slug, the live page wins.
- Automatic HTTPS, obtained and renewed for you
- “Set it up for me” writes the CNAME itself where the zone is one you already manage here
- Verification runs in the background, and routing rebuilds itself hourly as a safety net
- Clean incident URLs on your own domain — used in the canonical tag and in subscriber emails
- Old URLs keep working after a rename, unless another live page has claimed the slug
Add a CNAME record in your DNS provider pointing this hostname at:
status.infranest.io
CNAME target
DNS can take a few minutes to propagate — we’ll keep checking automatically.
- HTTPS obtained and renewed automatically
- Incident links on your own domain carry no slug — and that is the address used in subscriber emails.
- Verification runs in the background, and routing is rebuilt from the database on every deploy and hourly as a safety net — so a missing route is temporary rather than a support ticket.
Email subscribers, handled the way you would want yours handled
Visitors subscribe from the public page and are emailed automatically when an incident opens or an update is posted — and those emails link to the incident, not to the front of your page, so the reader lands on the thing they were told about. It is double opt-in, and unconfirmed subscriptions are pruned on age. The form is protected by a bot check, a honeypot and rate limits, and the bot check arms when someone touches the form rather than when the page loads: a status page is what people open during an outage, many at once, and almost none of them are subscribing. Loading a third-party challenge for every reader would charge a thousand people for a form two of them will use. Subscribing twice is ignored rather than errored, because the same person in two tabs must not hit an error page on a public form. And the privacy posture is worth saying out loud, because these are members of the public who asked for outage emails about someone else’s service: we hold the minimum, admins see counts and statistics with no personal data, there is no subscriber export, and “clear all” really deletes everyone.
- Double opt-in, with unconfirmed subscriptions pruned on age
- Notification emails link to the incident itself, not to the front page
- The bot check arms on interaction, so a thousand readers during an outage are not charged for a form they never use
- Subscribing twice is ignored, not errored — a public form must not show anyone an error page
- Admins see counts, never addresses; there is no export, and “clear all” really deletes everyone
Check your inbox!
We sent you a confirmation email. Click the link to activate your subscription.
- Double opt-in. The bot check arms when you touch the form, not when the page loads.
- Emails link to the incident itself, not to the front of your page — the reader lands on the thing they were told about.
- Subscribing twice is ignored rather than errored: the same person in two tabs must not hit an error page on a public form.
Subscribers
3 confirmed
- Admins see counts, never addresses. There is no subscriber export, and “clear all” really deletes everyone.
- Everyone on a page gets that page’s notices. There is no per-component subscription — it multiplies the confirmation and unsubscribe surface for a marginal gain.
Put your status where people already are
Not everyone will visit your status page, so it comes to them. A server-rendered SVG badge can be hotlinked as an image in a README, a docs site or a footer — it needs no JavaScript, which is why it works in the places a script never runs, and it is edge-cacheable, themed and available in four languages. Alongside it is a live widget: one cacheable script rendered into a shadow root, with aria-live so screen readers announce a change, polling a lightweight feed every sixty seconds. Four layouts — a badge, a summary card with ninety-day uptime bars, a per-service list, and a banner strip that can hide itself entirely when everything is healthy. There is also a badge for a single monitor, independent of any status page, opt-in per check and addressed by an unguessable token rather than a sequential id, so switching one on does not expose the rest.
- A server-rendered SVG badge that works in a README, an email or anywhere a script does not run
- A live widget in four layouts, one of which hides itself when everything is fine
- Rendered into a shadow root with aria-live, so a screen reader announces a change
- A per-monitor badge behind an unguessable token, opt-in per check
- The Embed tab previews with the production renderer, so what you copy is what you will get
Show your live status on your own site, docs or README. The badge updates automatically and links back to this status page.
Layout
Live preview
Major outage
100% uptime over 90 days
Checkout & paymentsMajor outage
Search APIDegraded performance
WebsiteOperational
The strip can hide itself entirely while everything is healthy, so a page that embeds it shows nothing until there is something to say.
<img src="https://status.northwind.example/badge.svg" alt="Status">
<script src="https://status.northwind.example/widget.js" data-layout="summary"></script>
<script src="https://status.northwind.example/widget.js" data-layout="list"></script>
<script src="https://status.northwind.example/widget.js" data-layout="strip"></script>
One cacheable script, rendered into a shadow root, polling a light feed every 60 seconds.
Show “Powered by InfraNest” · Powered by InfraNest
Everything else it handles
The parts that are only interesting when you need them.
Announcements, without opening an incident
Post a maintenance notice, an incident summary or a general message straight to the top of the page, with a window for how long it should show. Planned maintenance appears as planned rather than as downtime, so a scheduled window does not read as an outage or dent your uptime story.
Who gets to see it
Public, or password-protected for an internal or customer-only audience — and a separate toggle for whether search engines may index it. The password gate is one shared piece of code used by all four public reads: the page, the history, the badge and the incident. Extracted deliberately, because a fifth route gets written by copying a fourth, and the copy that gets forgotten is the one that leaks.
It tells you which kind of missing it is
A slug that never existed, a page that exists but is not published, a published page, and a host that is not ours are four different answers rather than one 404 — because a single 404 for all four is exactly what makes “my status page is down” unanswerable at the moment you need to answer it.
Reachable three ways
A hosted URL the moment you create the page, your own domain once the CNAME lands, and embedded into a page you already have. You do not have to pick one, and the hosted URL keeps working after the custom domain is live.
Uptime that matches the monitoring
The uptime percentage and the bars come from the same check history the monitoring module reports on, over the window you chose. There is no separate calculation to disagree with, and a shorter window also makes the page faster.
A footer you can replace
Custom footer text and an optional link to go with it. The “Powered by InfraNest” line is baked in server-side and removing it is part of the white-label entitlement — re-checked at render, so a downgrade puts it back rather than leaving it off.
Group labels, tags and the small switches
Show or hide the group headers, the uptime bars, the overall uptime strip, planned maintenance, third-party services and the incident history. Tags are off by default, because tags are usually written for your team rather than for your customers.
Plans
Status pages are a counted limit. A custom domain is a feature gate, and private pages — password protection and the team view together, one entitlement rather than two — are another. Removing the “Powered by” line sits under white-label.
Publish a page in about five minutes
Point it at the checks you already run. Nothing goes public until you say so.
A hand-made status page vs InfraNest
The difference between a page you have to remember and a page that already knows.
By hand
- A page somebody has to remember to update, during the hour they are least free
- An incident that scrolls away, and a link in a ticket that now says everything is fine
- A status page for customers, and a separate scramble in Slack for the people fixing it
- A CNAME, a certificate and a renewal you own forever
- A mailing list you built yourself, with the privacy questions that come with it
With InfraNest
- A page built from the checks you already run, updating itself
- A permanent link per incident that outlives the incident and the history window
- The same page again, behind your sign-in, with on-call and runbooks on it
- Your own domain with the record written for you and HTTPS renewed automatically
- Double opt-in, no export, and “clear all” that really deletes everyone
One login, ten modules
Every module is in every plan, Free included — what changes is how much of each you get.
The cost of doing it separately
Buy each piece from a different tool and it adds up fast:
- Domain & DNS
- ~€30
- Uptime monitoring
- ~€29
- SSL tracking
- ~€15
- Status page
- ~€29
- Server panel
- ~€15
- Across 4–5 separate tools
- €100–150/mo
Frequently asked
Where does the status on the page come from?
From your monitoring. Each service on the page is backed by one of your checks, so its status is whatever that check last reported, and the banner at the top is computed from all of them — worst wins. There is nothing to update by hand and no second copy of the truth to keep in step. You choose which checks appear and what they are called publicly, so a monitor named “App — northwind-app.dev” can show up as “Web app”, and the certificate and database-port checks can stay internal.
What is the team view?
The same status page rewritten for the people fixing the problem, inside InfraNest behind your normal sign-in. Your public page answers one question — is something broken — and deliberately answers nothing else. The team view adds what a responder needs: who is on call, the incidents open right now with links to their public write-ups, and the services with uptime bars, last-checked times and a runbook link per service. None of it appears on the public page; that is enforced by a whitelist and two tests rather than by a filter someone has to remember.
Do incident links keep working after the incident is over?
Yes, and that is the point. Each incident has a permanent URL of its own, so a link you pasted into a ticket or a chat still lands on that incident — what it affected, when it started, how long it ran and every update in order — long after your status page has stopped talking about it. It outlives the history window too: that window governs how long a list should be, not how long a link should work.
Can I use my own domain?
Yes. Point a CNAME at us and HTTPS is obtained and renewed automatically. If the hostname sits under a DNS zone you already manage in InfraNest on a provider that accepts writes, “Set it up for me” creates the record itself and starts verification, so there is no trip to the registrar. Verification runs in the background, and the routing behind the domain is rebuilt from the database on every deploy and hourly as a safety net.
What happens to subscriber email addresses?
We hold the minimum. Subscriptions are double opt-in and unconfirmed ones are pruned on age; admins see counts and statistics with no personal data; there is no subscriber export, deliberately, with a test pinning that; and “clear all” really deletes everyone. These are members of the public who asked for outage emails about someone else’s service, so the bar is higher than for your own contact list. There is also no per-component subscription — everyone on a page gets that page’s notices, because per-component subscriptions multiply the confirmation and unsubscribe surface for a marginal gain.
Can I put the status somewhere other than the status page?
Two ways. A server-rendered SVG badge you hotlink as an image, which needs no JavaScript and therefore works in a README, a docs site, a footer or an email. And a live widget — one cacheable script into a shadow root, polling a light feed every sixty seconds — in four layouts: badge, summary card, per-service list, and a banner strip that hides itself when everything is healthy. There is also a badge for a single monitor, independent of any page, addressed by an unguessable token so enabling one does not expose the rest.
Can I keep the page private?
Yes — a page can be public or password-protected for an internal or customer-only audience, with a separate switch for whether search engines may index it. The password gate is one shared piece of code used by the page, the history, the badge and the incident view, so there is no route that quietly forgot to ask. A protected page also asks for the password before naming an incident, so the title does not leak in a link preview.
Tell people what is happening, without having to remember to
Point a status page at the checks you already run.
Free plan · No credit card required · Set up in minutes