DEV Community: Jenson

What Is a Status Page? Complete Guide for 2026

Jenson — Sun, 02 Aug 2026 17:34:17 +0000

A status page is the public page where you tell customers how your service is doing. Here is what goes on one, when to make it public, and how to set one up in minutes.

A status page is a single page, usually at status.yourcompany.com, where you show whether your service is healthy and post updates when it is not. When something breaks, it is the one place customers can check instead of opening a ticket or guessing. A good one turns a stressful outage into a calm, informed wait.

What a status page is for

It does three jobs. It answers the question are you down before support has to. It shows the current state of each part of your product at a glance. And it keeps a public record of past incidents and uptime, which is what prospects and procurement teams look for when they want to trust you.

Public or private

A public page is open to anyone and is the norm for customer-facing products. A private page sits behind a password or login and suits internal tools or early-stage products that are not ready to publish uptime to the world. You can start private and flip to public later. Either way, the page should only ever show what is actually true: a brand-new component with no data yet should say so, not a confident green.

What goes on it

Components: the parts of your product (API, dashboard, payments) each with a current status.
Uptime history: a 90-day track per component so visitors can see your record, not just the current minute.
Incidents: a timeline of what happened, what you are doing, and when it resolved.
Scheduled maintenance: planned work announced ahead of time so it does not read as an outage.
Subscribe: let customers get incident updates by email or RSS so they do not have to keep refreshing.

Set one up in minutes

The quickest path: create the components that match how customers think about your product, attach an uptime monitor to each so status reflects real checks rather than a manual toggle, choose public or private, and publish. Add your own domain with automatic TLS when you want it on status.yourcompany.com. From there, the only ongoing work is posting a clear update when an incident happens, and even that can be drafted for you.

If your product depends on third parties (a cloud host, payments, email), map those dependencies too so an upstream outage shows on your page as what it is. See the guide on monitoring your dependencies for how that works.

FAQ

What is a status page?

A public (or private) page that shows the current health of each part of your service and a history of incidents and uptime, so customers can check status themselves instead of contacting support.

Should my status page be public or private?

Public is standard for customer-facing products and builds trust. Private (password or login gated) suits internal tools or pre-launch products. You can start private and switch to public later.

Do I need uptime monitoring for a status page?

Not strictly, but it is far better. If each component is backed by a monitor, the status reflects real checks and updates itself, instead of relying on someone to toggle it by hand during an incident.

Can I use my own domain?

Yes. With Sentivel you can serve the page on a subdomain like status.yourcompany.com or your own custom domain with automatic TLS.

Originally published at https://www.sentivel.com/guides/what-is-a-status-page.

How to Create a Status Page in 2026

Jenson — Sun, 02 Aug 2026 17:34:12 +0000

A step-by-step guide to creating a status page: what to put on it, how to back it with monitoring, and how to publish it on your own domain in minutes.

A status page is the public page where customers see whether your service is healthy and read your updates when it is not. Creating one is quick if you do it in the right order. This guide walks through it end to end, and every step maps to something you set up in Sentivel in a few minutes.

Step 1: List your components

Start with the parts of your product a customer would notice going down, named the way they think about them: API, dashboard, payments, email. Do not mirror your internal architecture. Three to six clear components is usually right for a small product. Each one gets its own status on the page, so a problem points at the right thing instead of a single green or red dot for the whole service.

Step 2: Attach a monitor to each component

A status page that someone has to toggle by hand goes stale the moment an incident starts. Instead, back each component with a monitor. In Sentivel you point an HTTP monitor at a URL, or use a heartbeat for a cron job or worker that has no public URL, and the component status follows the checks automatically. Flap thresholds mean a brief blip never opens an incident, and a brand-new component reads as warming up rather than a premature green until it has proven itself.

Step 3: Choose a design and add your brand

Keep the layout minimal so the status is the loudest thing on the page. Add your logo, your colors, and links back to your site and support. Sentivel ships two clean designs, modern and classic, and handles light and dark for you, so the page looks like part of your product without any design work.

Step 4: Decide public or private

A public page is the norm for customer-facing products and builds trust with a visible track record. A private, password-gated page suits internal tools or a product that is not ready to publish uptime yet. You can start private and flip to public later, and in Sentivel the change takes effect immediately.

Step 5: Put it on your own domain

Customers expect the page at something like status.yourcompany.com. Sentivel gives you a vanity subdomain out of the box and supports your own custom domain with automatic TLS, so the page is on your brand rather than a shared host.

Step 6: Turn on subscriptions

Not everyone will sit on the page waiting for news. Offer email updates and an RSS feed so customers hear about an issue through a channel they already use. Add a status badge or an embeddable widget to your app or docs so people can find the page before they open a ticket.

Step 7: Map the providers you depend on

This step is optional and worth it. Most outages are not your code; they are a cloud host, a payments provider, or an email service having a bad day. Map those dependencies in Sentivel and, when one has an incident, Sentivel flags the affected component and auto-posts an honest, provider-attributed message on your page, then clears it when the upstream incident resolves. You can skip this entirely and add it later; a page with zero dependencies is a complete, finished status page.

Step 8: Publish and keep it current

Publish the page and link to it from your footer, help center, and support flow. From here the only ongoing work is posting a clear update when something breaks, and Sentivel can draft that update for you in plain language, review-first, so keeping the page current is quick even when your team is busy.

FAQ

How long does it take to create a status page?

A few minutes. In Sentivel you create your components, attach a monitor to each, add your branding, and publish. Mapping upstream providers is optional and can be added later.

Do I need monitoring to create a status page?

Not strictly, but it is far better. When each component is backed by a monitor, the status reflects real checks and updates itself, instead of relying on someone to toggle it by hand during an incident.

Can I create a free status page?

Yes. Sentivel is free to start, including a status page on a vanity subdomain with built-in monitoring. A custom domain and the fuller feature set are available as you grow.

Can I use my own domain?

Yes. Sentivel serves your page on a subdomain like status.yourcompany.com or your own custom domain with automatic TLS.

Originally published at https://www.sentivel.com/guides/how-to-create-a-status-page.

Status Page Examples for Every Use Case (2026)

Jenson — Sun, 02 Aug 2026 17:34:07 +0000

A tour of great status pages by industry, what each one gets right, and how to build the same thing in Sentivel.

A status page is often the first place a customer looks when something feels off. The good ones turn a tense moment into a calm, informed wait. The fastest way to design yours is to study pages that already do the job well, then build the same patterns without the busywork. Below is a tour of strong status pages by use case, what each gets right, and how you set it up in Sentivel.

Every page mentioned here is public, so you can open it and see for yourself. None of these companies are Sentivel customers. They are examples of the patterns that work, and each one is something you can reproduce in a Sentivel status page in minutes.

What a good status page has in common

Across industries, the pages people trust do the same handful of things. Sentivel builds each of these in by default, so you get them without wiring anything together:

A clear headline state at the top: one line that tells you whether everything is fine.
Components that match how customers think about the product, each with its own status.
A real uptime history, 90 days per component, so the page shows a track record, not just this minute.
Incident updates written in plain language, timestamped, and updated as things change.
Email and RSS subscribe, so customers get told rather than having to keep refreshing.
Scheduled maintenance announced ahead of time, so planned work never reads as an outage.

Developer tools

Developer audiences are demanding and technical, so these pages lead with precision. GitHub splits its services into named components (Git operations, API requests, Actions, Pages) and holds a long, searchable incident history. Cloudflare breaks status down by product and by region, which matters when an issue is local rather than global.

In Sentivel you get the same granularity by creating a component per service and attaching an HTTP or TCP monitor to each, so status reflects real checks. If you run in more than one place, multi-region checks confirm an outage from several regions before it ever shows on the page, so a single network blip in one region never opens a false incident.

SaaS platforms

SaaS pages balance detail with reassurance, because the audience is mixed: some visitors are admins, most are end users. Stripe groups status by API and by dashboard and pairs each incident with a concise, human summary. Figma and Notion keep their pages calm and minimal so the current state reads at a glance.

Sentivel is built for that reader. Group components by the jobs customers do, not by your internal architecture, and let the headline state speak to the least technical person who might visit. When an incident happens, Sentivel can draft the customer-facing update for you in plain language, and you review it before it posts. Nothing goes public without your sign-off.

Consumer apps

Consumer products get a flood of visitors the moment anything breaks, so their pages are built for scale and speed. Discord and Dropbox keep the layout simple, the language friendly, and the page fast even under a spike.

Sentivel status pages are edge cached, so a page load needs no database and no function. That means the page stays up and fast during a traffic spike or even during an outage of your own backend, which is exactly when the most people are looking at it. One clear line up top, a short explanation, and an email or RSS subscribe so visitors can walk away and still be told when it is fixed.

Gaming and hosting

Players care about specific servers and specific regions, so gaming and hosting pages break status down by location: the control panel, the website, and each game region shown separately.

Model that in Sentivel with one component per region or server, each backed by its own monitor, so a problem in one location shows up as exactly that and does not hide behind a global green. The 90-day uptime history per component gives players the reliability record they check before they commit.

Education and collaboration tools

Tools used in classrooms and shared workspaces get their heaviest traffic in narrow windows, so clarity beats cleverness. The app, the API, and real-time collaboration each get their own status, with a short recent-notices list.

Sentivel keeps the page calm and readable by default, with light and dark handled for you and incident updates in plain language. Add scheduled maintenance windows ahead of time so planned work during a quiet period never reads as an outage to a stressed teacher or student.

Agencies and small teams

A small team does not need a sprawling page. A single component, a short note, an uptime history, and a subscribe link is plenty. The win is brand consistency: the page should look like the rest of your site, sit on your own domain, and read in your voice.

Sentivel puts your page on your own custom domain with automatic TLS, with your logo, colors, and links. A tidy branded status page signals that you take reliability seriously, even if you rarely have an incident to post. Onboarding is complete with a single component and zero dependencies, so a small team is finished in minutes.

Internal and IT status pages

Not every status page is public. Internal pages keep staff informed about the systems they depend on, from portals and internal APIs to third-party services, and usually sit behind a password or login.

Sentivel supports private, password-gated pages, so you can run an internal page that does the same job as a public one without publishing your uptime to the world. You can start private and flip to public later, and the change takes effect immediately.

The practices worth copying, built in

The same patterns show up across the best pages. Here is each one, and where it already lives in Sentivel.

Minimal design that reads at a glance

The page has one job: show the current state clearly and fast. Sentivel ships two clean designs, modern and classic, both built so the status is the loudest thing on the page. Add your logo and colors and leave everything else quiet. During an incident, that clean layout is the difference between a customer who feels informed and one who feels lost.

Status backed by real monitoring

The strongest status pages are not toggled by hand. In Sentivel each component is tied to a monitor, so the status reflects real checks and updates itself the moment something changes. Flap thresholds mean a brief blip never opens an incident, and a brand-new component reads as warming up rather than a premature green until it has proven itself. That removes the worst failure mode of all: an outage in progress while the page still shows green because nobody flipped the switch.

Honest updates that keep flowing

Trust is built during the incident, not after it. Say what is wrong, what you are doing, and post again as things change. Sentivel can draft each update for you in plain language, always review-first, so keeping the page current is quick even when your team is busy fighting the fire.

A real uptime history

A 90-day history lets prospects, procurement teams, and existing customers judge your reliability on evidence rather than a promise. Sentivel keeps a rolling 90-day track per component, with hover detail per day, and you can trim the displayed window to 30, 60, or 90 days.

Subscribe, and find it easily

Not everyone will sit on the page waiting for news. Sentivel offers double opt-in email updates and an RSS feed, so customers hear about an issue through the channel they already use. Add a status badge or an embeddable widget to your app or docs so people can find the page before they open a ticket.

Show what you depend on

Most outages are not your code. They are a cloud host, a payments provider, or an email service having a bad day. This is where Sentivel goes further than a plain status page: map the providers you rely on, and when one has an incident, Sentivel flags the affected component and auto-posts an honest, provider-attributed message on your page, for example that you are aware of an issue with a service you rely on and some functionality may be affected until it is resolved. It is opt-in, never inferred, and it clears itself when the upstream incident resolves.

Publish yours

Everything above is one product. Create the components that match your product, attach a monitor to each, add your domain and branding, and publish. Map your upstream providers whenever you are ready, or never. You can have a page worth studying live in a few minutes.

FAQ

What makes a good status page?

A clear headline state, components that match how customers think about the product, a real 90-day uptime history, plain-language incident updates that keep flowing, email and RSS subscribe, and scheduled maintenance announced ahead of time. Sentivel builds all of these in by default.

Can I build these examples in Sentivel?

Yes. Each pattern here, from per-component status and regional breakdown to a private internal page and a branded custom domain, is something you set up in a Sentivel status page in minutes.

How many components should a status page have?

Enough to match how customers think about your product, and no more. A small team might have one component. A larger platform might split by API, dashboard, and region. In Sentivel you group by the jobs customers do, not by your internal architecture.

Does the status update itself, or do I toggle it by hand?

In Sentivel each component is backed by a monitor, so status reflects real checks and updates itself. Flap thresholds mean a brief blip never opens an incident, and you never have an outage in progress while the page still shows green.

Can a Sentivel status page show third-party outages?

Yes. Map the providers you depend on and, when one has an incident, Sentivel flags the affected component and auto-posts an honest, provider-attributed message on your page. It is opt-in and clears itself when the upstream incident resolves.

Originally published at https://www.sentivel.com/guides/status-page-examples.

Status Page Best Practices in 2026

Jenson — Sun, 02 Aug 2026 17:34:03 +0000

The practices that separate a status page customers trust from one they ignore, and how Sentivel builds each of them in by default.

A status page is only as useful as the habits behind it. The same practices show up on every page customers actually trust. Here is each one, why it matters, and where it already lives in Sentivel so you get it without extra work.

Show only what is true

The fastest way to lose trust is a green page during an outage. Back every component with a monitor so the status reflects real checks, not a switch someone forgot to flip. Sentivel does this by default, with flap thresholds so a brief blip never opens an incident and a warming-up state so a brand-new component is never a premature green.

Keep the design minimal

The page has one job: show the current state clearly and fast. Strip out anything that competes with that, match your brand, and let the status be the loudest thing on the page. During an incident, a clean layout is the difference between a customer who feels informed and one who feels lost.

Group components the way customers think

Name components after the jobs customers do, not your internal services. Aim for enough to point at the right problem and no more. Three to six clear components suits most products; a larger platform might split by API, dashboard, and region.

Write updates anyone can understand

Lead with what the reader needs: is it affecting me, and when will it be fixed. Skip the jargon and keep sentences short. Trust is built during the incident, so post again as things change, even when the change is just that you are still working on it. Sentivel can draft each update for you in plain language, always review-first.

Announce maintenance ahead of time

Planned work should never read as an outage. Schedule maintenance windows in advance so the page shows them as expected rather than as something breaking, and so customers are not surprised. Sentivel skips checks during a window, so planned work does not dent your uptime or fire a false alert.

Show a real uptime history

A 90-day history lets prospects, procurement teams, and existing customers judge your reliability on evidence rather than a promise. A page that shows only the current minute asks for trust; a page that shows months of green earns it. Sentivel keeps a rolling 90-day track per component with per-day detail.

Make it easy to subscribe and find

Let customers get updates through the channel they already use. Sentivel offers double opt-in email and an RSS feed, plus status badges and an embeddable widget you can drop into your app or docs. Link the page from your footer, help center, and support flow so people check it before they open a ticket.

Explain upstream outages honestly

Most outages trace back to a provider you depend on. Rather than flip a component to degraded with no explanation, tell customers the truth: the issue is upstream, here is which service, and here is what it affects. Sentivel builds this in with a dependency map you control, which auto-posts a factual, provider-attributed advisory and clears it when the upstream incident resolves. It never asserts you are down or makes unverifiable promises.

Put it on your own domain

A status page on your own domain reads as part of your product and signals that you take reliability seriously. Sentivel supports a custom domain with automatic TLS, so the page lives on your brand rather than a shared host.

FAQ

What is the most important status page best practice?

Only show what is true. Back every component with a monitor so the status reflects real checks, and never leave a green page up during an outage. Everything else builds on that credibility.

How often should I update a status page during an incident?

Post at the start, then at a regular cadence as things change, even when the update is just that you are still working on it. A page that goes quiet mid-incident reads worse than one that admits it does not yet have an answer.

Should a status page show scheduled maintenance?

Yes. Announce planned work ahead of time and label it clearly so it does not read as an outage. In Sentivel a maintenance window also skips checks, so planned work does not dent your uptime or fire a false alert.

How long should uptime history be on a status page?

90 days is the common standard and enough to show a real track record. Sentivel keeps a rolling 90-day history per component and lets you trim the displayed window to 30, 60, or 90 days.

Originally published at https://www.sentivel.com/guides/status-page-best-practices.

What Is Uptime Monitoring? Complete Guide for 2026

Jenson — Sun, 02 Aug 2026 17:33:58 +0000

What uptime monitoring actually checks, the difference between HTTP, keyword, heartbeat and TCP checks, and how to avoid the false-positive alerts that train people to ignore the pager.

Uptime monitoring is the practice of checking, on a schedule, whether a service is responding correctly, and alerting someone when it is not. The goal is not to collect a number. It is to learn about a real problem before your customers do, without crying wolf so often that people stop listening.

The kinds of check

HTTP: request a URL and judge the response by status code and timing. The workhorse for websites and APIs.
Keyword: an HTTP check that also asserts a word is present (or absent) in the body, so a 200 that renders an error page still counts as down.
Heartbeat: the inverse. Your cron job or worker pings the monitor on each run; if a ping does not arrive in the expected window, it is down. The right tool for things that have no public URL.
TCP: open a connection to a host and port, for databases, mail servers and other non-HTTP services.

Interval and what down really means

The interval is how often you check, commonly every minute or two. A single failed check is rarely proof of an outage: networks blip, a server hiccups, a deploy restarts a process. Treating one blip as down is the fastest way to a noisy, ignored pager.

Confirmation and flap thresholds

The fix is to require a run of consecutive failures before opening an incident, and a run of consecutive successes before resolving it. That confirmation window absorbs transient blips while still catching real, sustained failures quickly. A brief recovery in the middle of an outage should not split it into two incidents, and a confirmed recovery followed by a fresh failure should be a new one. Getting this state machine right is most of what separates a calm monitor from a noisy one.

False positives and where they come from

Beyond blips, the other big source of false alarms is the vantage point. A check runs from somewhere, and a network problem between that location and your service looks identical to your service being down. Confirmation thresholds catch a transient version of this, but a sustained regional path problem can still read as an outage from one location. The strongest defence is to check from several regions and only open an incident when more than one agrees. Sentivel does exactly that: a monitor with two or more regions is checked from each, and the per-region results collapse to a single consensus verdict before anything opens an incident, so one region's network problem never trips a false alarm. Together with flap thresholds, an outage has to be both sustained and seen from more than one place before it pages anyone.

Tie monitoring to your status page

A monitor is most useful when its confirmed state drives the matching component on your status page, so customers see an honest status without anyone toggling it by hand. A brand-new monitor should read as warming up until it has proven itself, never as a premature green.

FAQ

What is uptime monitoring?

Checking a service on a schedule (by HTTP request, keyword match, heartbeat ping or TCP connection) and alerting when it fails, so you find out about a real problem before your customers do.

What is the difference between HTTP and heartbeat monitoring?

HTTP monitoring reaches out to a URL and judges the response. Heartbeat monitoring is the inverse: your job pings the monitor on each run, and the absence of an expected ping is the signal. Heartbeats suit cron jobs and workers that have no public URL.

How do I avoid false-positive alerts?

Require several consecutive failed checks before opening an incident and several successes before resolving, so a transient blip never pages anyone. For sustained, region-specific network issues, check from multiple locations and only alert on consensus.

How often should checks run?

Every one to two minutes is typical. More frequent checks detect faster but add load and cost; pair the interval with confirmation thresholds so frequency does not translate into noise.

Originally published at https://www.sentivel.com/guides/uptime-monitoring.

How to Monitor Third-Party Dependencies in 2026

Jenson — Sun, 02 Aug 2026 17:33:53 +0000

When a provider you rely on goes down, your customers feel it as your outage. Here is how to monitor your third-party dependencies and post a clear, honest heads-up on your status page.

Almost no service runs alone. You depend on a cloud host, a payments provider, an email or SMS gateway, an auth provider, a CDN. When one of them has an incident, your product degrades even though nothing in your own code broke. To your customers it still looks like your outage, and your support inbox fills up with the same question: is it you, or is it something else?

Dependency monitoring is the practice of watching the providers you rely on and telling your customers, clearly, when one of them is the cause. This guide covers what to watch, how to map a provider to the part of your product it affects, and how to post a message that builds trust instead of confusion.

Why a provider's outage is your problem too

Your customers do not see your architecture. They see checkout failing, logins hanging, or emails not arriving. Whether the root cause is your database or a third party, the experience is the same, and silence reads as either you do not know or you are not saying. A short, accurate note that names the upstream provider does three things: it answers the support question before it is asked, it shows you are on top of the incident, and it sets the right expectation for when things recover.

What to monitor

Start with the providers whose outage would actually be visible to a customer. A good first list:

Your cloud or hosting provider, and the specific region you run in.
Payments, if a failed charge means a failed signup or checkout.
Auth or identity, if its downtime blocks sign-in.
Email and SMS providers, since a quiet failure here delays everything from receipts to alerts.
Your CDN and DNS, which fail loudly and globally.
Any core API your product is a thin layer over.

Most of these publish a status feed. The useful signal is not just whether the provider has declared an incident, but whether the specific part you depend on is affected, for example one cloud region rather than the whole provider.

Map each dependency to the component it affects

The link that matters is the one between a provider and the part of your own product that breaks when it is down. Map it explicitly: your Checkout component depends on your payments provider, your Login component depends on auth, your Notifications component depends on the email gateway. Keep it user-defined rather than inferred, because only you know which of your features actually rely on which provider, and an inferred guess that is wrong is worse than no guess at all.

Once the map exists, an upstream incident on a provider you depend on can automatically flag the affected component, instead of someone noticing the support tickets an hour later and updating the page by hand.

Post an honest upstream advisory

The message your customers see is the whole point. Keep it factual and attribute the cause to the provider without asserting anything you cannot verify. Something like: We are aware of an ongoing issue with a provider we rely on for payments. Some checkouts may be affected until it is resolved. We are monitoring it and will update here.

Notice what that does and does not say. It names the kind of dependency, it scopes the impact, and it promises updates. It does not claim your data is safe, it does not guess at a fix time, and it does not pretend the problem is smaller than it is. An advisory that overpromises costs you more trust than the outage itself.

How Sentivel does it

Sentivel lets you map each of your components to the providers it depends on, down to the specific part such as a single region. When a provider you have mapped has an incident, or the exact part you rely on goes unhealthy, Sentivel can automatically post a plain-English advisory on your status page that attributes the cause to the provider, and clear it when the upstream issue resolves. The dependency map you define is what drives the message.

This is not a new idea on its own. A couple of other tools will auto-flip a component when a third party is down. Where we focus is the part customers actually read: a clear, branded, honest message rather than a silent status change, driven by a dependency map you control. You can also keep it review-first if you would rather approve advisories before they post.

FAQ

What is dependency monitoring?

Watching the third-party providers your product relies on (cloud, payments, auth, email, CDN, and so on) so you know the moment one of them has an incident, and can tell your customers when a provider is the cause of a problem they are seeing.

How do I show a third-party outage on my status page?

Map the affected part of your product to the provider it depends on, then post an advisory that attributes the cause to the provider and scopes the impact. With Sentivel this can happen automatically from your dependency map, and clear itself when the upstream incident resolves.

Should I claim my customers' data is safe during an upstream outage?

No. Only say what you can verify. Name the provider and the likely impact, promise updates, and avoid unverifiable promises about data or fix times. Overpromising costs more trust than the outage.

Is automatic dependency flagging unique to Sentivel?

No, a few tools auto-flip a component when a third party is down. Sentivel's focus is the clear, honest, customer-facing message that the flip drives, from a dependency map you define and control.

Originally published at https://www.sentivel.com/guides/monitor-third-party-dependencies.

Incident Communication Best Practices in 2026

Jenson — Sun, 02 Aug 2026 17:33:49 +0000

What to say during an outage, how often to say it, and templates for each stage of an incident. Clear, honest updates cost you far less trust than the outage itself.

During an incident, what you say is part of the product. Customers can forgive an outage. What they remember is whether you told them what was happening, whether it was honest, and whether you said when they would hear from you again. Good incident communication is mostly a habit of structure and cadence, not eloquence.

What a good update contains

Acknowledgement: confirm you are aware and looking into it.
Impact: who and what is affected, scoped as precisely as you can.
Action: what you are doing right now, in plain terms.
Next update: when they will hear from you again, even if it is just to say no change yet.

The stages of an incident

Most updates fall into four states. Investigating: you know something is wrong and are looking. Identified: you have found the cause. Monitoring: you have applied a fix and are watching it hold. Resolved: it is over, with a short note on what happened. Moving through these in order, even briefly, tells a clear story.

Templates you can reuse

Investigating: We are investigating reports of errors affecting [area]. Some [users/requests] may see [symptom]. We will update by [time].
Identified: We have identified the cause as [plain description] and are working on a fix. [Area] remains affected. Next update by [time].
Monitoring: A fix has been applied and [area] is recovering. We are monitoring to confirm it holds, and will resolve once stable.
Resolved: This is resolved as of [time]. The cause was [short, honest description]. We are sorry for the disruption and will follow up with any longer-term fixes.

Tone and honesty

Say what you can verify and nothing more. Do not promise that data is safe, do not guess at a fix time you cannot commit to, and do not make the problem sound smaller than it is. An update that overpromises and is then contradicted costs more trust than the outage. When an issue is caused by a provider you depend on, say so and attribute it to them rather than implying the fault is entirely yours.

Cadence

Pick an interval and hold it. Even a no change yet, still working update at the time you promised is reassuring, because silence reads as either you do not know or you are not saying. Let customers subscribe so the update reaches them without refreshing the page.

FAQ

What should an incident status update include?

Four things: acknowledgement that you are aware, the impact and who it affects, what you are doing about it, and when the next update will come. Keep it plain and specific.

How often should I post updates during an outage?

Pick a cadence and keep it, even when there is nothing new. A short on-time no-change update is reassuring; unexplained silence is not.

Should I say customer data is safe during an incident?

Only if you have verified it. Avoid unverifiable promises about data or fix times. Overstating safety and being contradicted later costs more trust than the incident itself.

How do I communicate an outage caused by a third party?

Attribute it to the provider and scope the impact: we are aware of an issue with a provider we rely on for [function]; some [area] may be affected until it resolves. Name the dependency without overclaiming.

Originally published at https://www.sentivel.com/guides/incident-communication.

On-Call Schedules and Escalation Policies Explained (2026)

Jenson — Sun, 02 Aug 2026 17:33:44 +0000

How on-call rotations, escalation ladders and acknowledgements fit together, so the right person is reached when something breaks, without burning out the team.

On-call is how a team makes sure someone is responsible for responding when something breaks, around the clock if needed. Escalation is what happens when that someone does not answer. Done well, the right person is reached quickly and everyone else is left alone. Done badly, alerts go to a group chat that no one owns, and real problems sit until a customer complains.

Rotations

A rotation shares the on-call duty across a team on a schedule, so no one person carries the pager forever. A simple weekly handoff is enough to start. Larger teams layer rotations (a primary and a secondary, or a follow-the-sun setup across time zones) so coverage matches when people are awake.

Escalation policies

An escalation policy is the ladder an alert climbs until someone acknowledges it. A typical one: page the on-call person; if they do not acknowledge within a few minutes, page them again or page the secondary; if still nothing, page a wider group or a manager. Each step has a wait, so a missed phone gets backstopped automatically instead of an incident going unanswered.

Acknowledge to stop the noise

Acknowledging an alert tells the system a human has it, which stops the escalation from climbing further. This is the mechanism that lets you be aggressive about paging without spamming the whole team: the ladder only advances while no one has taken ownership.

Severity and channels

Not every alert deserves a 3am phone call. Route by severity: a major outage can ring a phone and send an SMS, while a minor degradation might only post to a channel or email. Matching urgency to impact is the difference between a pager people trust and one they mute.

Coverage and humane defaults

Plan for real life. People go on holiday, so let someone pause their own paging while the rest of the rotation still covers the gap. Watch for coverage holes where a schedule resolves to nobody, and make sure an unacknowledged page eventually reaches a human rather than falling into silence. Alert fatigue is a real failure mode: every page that was not worth waking up for makes the next real one easier to ignore.

FAQ

What is an escalation policy?

The ordered ladder an alert follows until someone acknowledges it: page the on-call person, wait, then page again or page a secondary, then widen to a group. Each step has a timeout so a missed alert is backstopped automatically.

What does acknowledging an incident do?

It tells the system a human has taken ownership, which stops the escalation ladder from climbing further. It is what lets you page aggressively without spamming the whole team.

How do on-call rotations work?

A rotation shares on-call duty across a team on a schedule (often a weekly handoff) so no one carries the pager indefinitely. Larger teams stack a primary and secondary, or run follow-the-sun across time zones.

How do I avoid alert fatigue?

Route by severity so only real, high-impact problems wake someone, confirm failures before paging so blips never do, and keep rotations and holiday cover honest so the load is shared.

Originally published at https://www.sentivel.com/guides/on-call-and-escalation.

How to Write an Incident Postmortem in 2026 (With Template)

Jenson — Sun, 02 Aug 2026 17:33:40 +0000

A postmortem turns an outage into something your team learns from instead of repeats. Here is the structure, why blameless matters, and a template you can copy.

A postmortem is the short, honest write-up you produce after an incident: what happened, why, and what you will change so it is less likely to happen again. Its only job is learning. If it turns into a search for someone to blame, people stop being candid, and the write-up stops being useful.

Why blameless

Blameless does not mean no accountability. It means you assume everyone acted reasonably given what they knew at the time, and you focus on the systems and conditions that let the failure happen rather than the person who happened to be holding the keyboard. People who fear blame hide detail, and hidden detail is exactly what you need to fix the real cause.

The structure

Summary: two or three sentences a busy reader can take away.
Impact: who was affected, how badly, and for how long.
Timeline: what happened and when, from first signal to resolution.
Root cause: the underlying condition, not just the trigger.
What went well and what did not: detection, response, communication.
Action items: concrete changes, each with an owner and a due date.

A template you can copy

Summary: On [date], [service] was [impact] for [duration]. The cause was [root cause]. We have [key fix] and are tracking [follow-ups].
Impact: [who/what was affected], [scope], [start] to [end].
Timeline: [time] first alert. [time] acknowledged. [time] cause identified. [time] fix applied. [time] resolved.
Root cause: [the underlying condition that made this possible].
What went well: [e.g. detection was fast]. What did not: [e.g. the alert was noisy / comms were late].
Action items: [change] owner [name] by [date].

Make the action items real

The part that prevents a repeat is the action items, and they only count if they are specific, owned, and dated. Aim for a few changes you will actually make, not a long list you will not. Revisit them; an action item with no follow-through is just a note. Publishing the postmortem, or at least the summary, on your status page or to affected customers is often the right call: it shows you took it seriously.

FAQ

What is a postmortem?

A short write-up after an incident covering what happened, the impact, a timeline, the root cause, and the concrete changes you will make so it is less likely to recur. Its purpose is learning, not blame.

What does a blameless postmortem mean?

You assume everyone acted reasonably with the information they had, and focus on the systems and conditions that allowed the failure rather than the individual involved. It keeps people candid, which is what makes the write-up useful.

What should a postmortem include?

A summary, the impact, a timeline, the root cause, an honest what-went-well-and-badly, and action items that each have an owner and a due date.

Should I share the postmortem with customers?

Often yes, at least the summary. A clear, honest retrospective on your status page or sent to affected customers shows you took the incident seriously and are fixing the underlying cause.

Originally published at https://www.sentivel.com/guides/how-to-write-a-postmortem.

How to Migrate From Atlassian Statuspage in 2026

Jenson — Sun, 02 Aug 2026 17:33:35 +0000

Move your components, incident history, and email subscribers from Atlassian Statuspage (or Instatus) to Sentivel in a few minutes with the built-in importer, then finish the switch with monitors and your custom domain.

Sentivel has a built-in importer for Atlassian Statuspage and Instatus. It brings across your components (with their grouping), your incident history with the full update threads, and your confirmed email subscribers. You paste an API key, the import runs once, and re-running it is always safe because nothing is ever added twice.

What the importer moves

Components, with their current status and their group layout mirrored as sections on your Sentivel page.
Incident history, up to the most recent 500 incidents, including every customer-facing update in each thread.
Confirmed email subscribers, so your customers keep getting notified without re-subscribing.

Scheduled maintenance windows are not imported automatically, because they are a different object in Sentivel; the importer tells you how many it skipped so you can recreate the upcoming ones. Monitors are also not created for imported components, since Statuspage has no monitoring to import from; you attach Sentivel monitors afterwards.

Step 1: Get your Statuspage API key and page ID

In Statuspage, open your avatar menu and choose API info. Copy the API key and the page ID shown beside it. For Instatus, create a key under Developer settings; the page ID is in the dashboard URL.

Step 2: Run the import

In Sentivel, go to Status pages and choose Import from Statuspage or Instatus. Pick the source, paste the key and page ID, choose which Sentivel page to import into, and press Import. The key is used once for the fetch and never stored. A summary shows exactly what was added and what was skipped.

Step 3: Attach monitors

Imported components show their history but have no checks yet. Add an HTTP, keyword, TCP, or heartbeat monitor for each component you want verified automatically. From then on the component's status is driven by real checks with flap protection, so a single network blip never opens a false incident.

Step 4: Map your third-party dependencies

This is the part Statuspage doesn't do. Map which of your components rely on which providers (AWS, Stripe, Cloudflare, and the rest of the catalog). When a provider you depend on has an incident, Sentivel posts a clear advisory on your page naming the provider, and clears it when the issue resolves.

Step 5: Move your domain

Point your status subdomain's CNAME at Sentivel under the page's custom-domain settings, verify, and your page is live at the same address your customers already know. Keep the Statuspage subscription until you've confirmed the new page, then cancel it.

FAQ

Does the importer work with Instatus too?

Yes. The same importer supports Instatus: choose Instatus as the source and use an API key from its Developer settings.

Will my subscribers need to confirm again?

No. Subscribers who were confirmed on your old page are imported as confirmed. It's your list, moved with you.

Is it safe to run the import twice?

Yes. The import is idempotent: components, incidents, and subscribers that already exist are skipped, never duplicated.

Is my Statuspage API key stored?

No. The key is used once to fetch your data during the import and is never stored or logged.

Originally published at https://www.sentivel.com/guides/migrate-from-statuspage.

10 Best Status Page Tools in 2026

Jenson — Sun, 02 Aug 2026 17:33:31 +0000

An honest comparison of the leading status page tools in 2026, by category and use case, including which have built-in monitoring, on-call and third-party dependency tracking. Written by Sentivel, with Sentivel included on the same terms.

A status page is where customers check whether your service is healthy, so the right tool depends on what else you need around it: monitoring to detect problems, on-call to wake the right person, and dependency tracking to explain a provider's outage. This is a practical comparison of the main options in 2026, grouped by what they are best at rather than ranked one-to-ten.

Two notes up front, in the interest of being straight with you. This guide is written and maintained by Sentivel, and Sentivel is included below on the same terms as everything else, with its limits stated as plainly as its strengths. And pricing in this space changes often, so the table describes each tool's pricing model rather than exact figures; check the vendor's current pricing before you decide.

Tool	Status page	Built-in monitoring	Third-party deps	On-call	Pricing model
Sentivel	Yes	Yes (multi-region)	Yes (user-mapped)	Yes	Free plan, one bundle
Atlassian Statuspage	Yes	No	Partial (components)	Via integrations	Per subscriber + seat
Better Stack	Yes	Yes (multi-region)	Partial (IsDown add-on)	Yes	Modular bundle
Instatus	Yes	Basic	Manual only	Yes	Per monitor, low entry
Hyperping	Yes	Yes (multi-region)	No	Yes	Flat rate
OpenStatus	Yes	Yes (multi-region)	No	Via integrations	Open source / SaaS
Uptime Kuma	Basic	Yes	No	No	Open source, self-host
Cachet	Yes	No	No	No	Open source, self-host
StatusGator	Aggregated	Yes	Yes (core)	Via integrations	Per monitor tiers
IsDown	Aggregated	Partial	Yes (core)	Via integrations	Per monitor tiers

All-in-one (status page + monitoring + on-call)

Better Stack bundles uptime monitoring, status pages, incident management and on-call, with an unusually generous free tier and checks from multiple regions. Its main trade-offs are modular pricing that gets hard to total as you add packs and seats, and third-party dependency tracking that comes via a separate IsDown integration rather than natively.

Hyperping offers a similar bundle with flat-rate pricing (not per seat), which favours larger teams, and genuine multi-region confirmation before it declares something down. It does not ingest third-party vendor status, so it cannot tell customers when a provider you depend on is the cause.

Instatus leads on status page design and speed and has a low entry price, with monitoring and on-call added more recently and still lighter than the others. Sentivel sits in this group too: a status page with built-in monitoring and on-call, checks that confirm an outage from multiple regions before opening an incident, plus the part we focus on, a user-defined dependency map that posts a clear, honest advisory when an upstream provider is the cause. We are still early, so the ecosystem of integrations is smaller than the incumbents, but the core is built to the same standard.

Status page only

Atlassian Statuspage is the mature incumbent: a deep incident workflow, a big integration ecosystem, and 150+ third-party components that can auto-reflect a provider's status. It has no built-in monitoring (you bring your own) and is the most expensive option as subscribers and seats grow. Cachet is the open-source, self-hosted take on the same job (incidents and components, no monitoring); note its 3.x rebuild is still in active development, so most production users run the older 2.x.

Open source and self-hosted

Uptime Kuma is the popular MIT-licensed, self-hosted monitor with a clean UI and dozens of notification channels, ideal if you want to own your data and run it yourself. It is single-node (no multi-region) and has no on-call or structured incident comms. OpenStatus is AGPL-licensed monitoring-as-code with a strong API, a Terraform provider and probing across many regions, self-hostable or hosted; it routes alerting out to external on-call tools rather than having its own.

Third-party dependency aggregators

StatusGator and IsDown are a different category: their core job is watching the official status pages of services you depend on (thousands of them) and alerting you early, with optional own-endpoint monitoring and aggregated boards. They are the deepest at vendor-outage detection, but they relay what providers publish, have no native on-call, and are not built around mapping a provider outage to which of your own components it affects with a customer-facing message.

How to choose

Just need a polished public page and already have monitoring: Statuspage, Instatus or a self-hosted Cachet.
Want monitoring, status and on-call in one tool: Better Stack or Hyperping (or Sentivel, if the dependency narrative matters to you).
Want to own your data and self-host: Uptime Kuma or OpenStatus.
Mainly need to know when third parties you rely on are down: StatusGator or IsDown.
Want an upstream outage explained to customers automatically from a map you control: that is the specific thing Sentivel focuses on.

FAQ

What is the best status page tool?

There is no single best one; it depends on what you need around the page. For an all-in-one with monitoring and on-call, Better Stack and Hyperping are strong. For a polished page when you already have monitoring, Atlassian Statuspage or Instatus. For self-hosting, Uptime Kuma or OpenStatus. For tracking third-party outages, StatusGator or IsDown.

What is the best free status page tool?

Atlassian Statuspage, Better Stack, Instatus and Hyperping all have free tiers, and Uptime Kuma, OpenStatus and Cachet are open source and free to self-host. Sentivel has a free plan. Check each free tier's current limits, since they change.

Which status page tools include built-in monitoring?

Better Stack, Hyperping, OpenStatus, Uptime Kuma and Sentivel include monitoring; Instatus and the aggregators include some. Atlassian Statuspage and Cachet do not, so they need a separate monitoring tool.

Is this comparison biased toward Sentivel?

It is written by Sentivel, which we say plainly. We have grouped tools by use case rather than ranking ourselves first, stated our real limitations (a smaller integration ecosystem than the incumbents), and pointed you to competitors where they are the better fit.

Originally published at https://www.sentivel.com/comparisons/best-status-page-tools.

6 Best Atlassian Statuspage Alternatives in 2026

Jenson — Sun, 02 Aug 2026 17:33:26 +0000

The best Atlassian Statuspage alternatives in 2026, grouped by use case, including which add built-in monitoring, on-call, and third-party dependency tracking. Written by Sentivel, included on the same terms.

Atlassian Statuspage is the mature incumbent, with a deep incident workflow and a large integration ecosystem. People look for an alternative for a few common reasons: it has no built-in monitoring, so you pay for a separate tool to detect problems; its pricing climbs steeply as subscribers and seats grow; and its third-party component handling is partial. Here are the strongest alternatives in 2026, grouped by what they are best at rather than ranked one-to-ten.

Two notes up front. This guide is written and maintained by Sentivel, and Sentivel is included below on the same terms as everything else, with its limits stated as plainly as its strengths. Pricing in this space changes often, so the table describes each tool's pricing model rather than exact figures; check the vendor's current pricing before you decide.

Tool	Built-in monitoring	Third-party deps	On-call	Pricing model
Sentivel	Yes (multi-region)	Yes (user-mapped)	Yes	Free plan, one bundle
Atlassian Statuspage	No	Partial (components)	Via integrations	Per subscriber + seat
Better Stack	Yes (multi-region)	Partial (IsDown add-on)	Yes	Modular bundle
Instatus	Basic	Manual only	Yes	Per monitor, low entry
Hyperping	Yes (multi-region)	No	Yes	Flat rate
OpenStatus	Yes (multi-region)	No	Via integrations	Open source / SaaS
Uptime Kuma	Yes	No	No	Open source, self-host

If you want monitoring and status in one tool

The most common reason to leave Statuspage is that you are tired of paying for and wiring up a separate monitoring tool. Better Stack bundles monitoring, status pages, incident management, and on-call with a generous free tier and multi-region checks; the trade-off is modular pricing that gets hard to total as you add packs and seats. Hyperping offers a similar bundle at a flat rate that favours larger teams, with genuine multi-region confirmation before it declares something down. Sentivel fits here too: a status page with built-in multi-region monitoring and on-call, plus the part we focus on, a user-defined dependency map that posts an honest advisory when an upstream provider is the cause.

If you mainly want a cheaper, cleaner page

Instatus is the closest like-for-like on the page itself, with a strong focus on design and speed and a lower entry price than Statuspage, plus monitoring and on-call added more recently and still lighter than the all-in-one tools. It is a good pick if the page is the whole job and cost is the reason you are switching.

If you want to self-host and own your data

Uptime Kuma is the popular MIT-licensed, self-hosted monitor with a clean UI and dozens of notification channels, ideal if you want to run it yourself; it is single-node with no structured incident comms. OpenStatus is AGPL-licensed monitoring-as-code with a strong API, a Terraform provider, and probing across many regions, self-hostable or hosted, routing alerts out to external on-call tools rather than having its own.

If you specifically want the upstream-outage story

Statuspage can auto-reflect a third-party component's status, but it stops at flipping a component. The thing Sentivel focuses on is the next step: you map which of your components depend on which providers, and when a provider has an incident, Sentivel posts a clear, branded, customer-facing message on your page that attributes the cause honestly and clears itself when the upstream incident resolves. It is opt-in and never inferred as fact.

How to choose

Leaving mainly to stop paying for separate monitoring: Better Stack, Hyperping, or Sentivel.
Leaving mainly on cost, page is the whole job: Instatus.
Want to self-host and own your data: Uptime Kuma or OpenStatus.
Want an upstream provider outage explained to customers automatically from a map you control: that is the specific thing Sentivel focuses on.
Happy with the workflow and just need more integrations: staying on Statuspage may be right.

FAQ

What is the best Atlassian Statuspage alternative?

It depends on why you are switching. For monitoring and status in one tool, Better Stack, Hyperping, or Sentivel. For a cheaper, cleaner page, Instatus. For self-hosting, Uptime Kuma or OpenStatus. For explaining a third-party outage to customers from a dependency map you control, Sentivel.

Why do people move off Atlassian Statuspage?

Three common reasons: it has no built-in monitoring, so you pay for a separate tool; its pricing rises steeply as subscribers and seats grow; and its third-party component handling stops at flipping a component rather than posting a customer-facing explanation.

Is there a free Statuspage alternative?

Yes. Better Stack, Instatus, and Hyperping have free tiers, Uptime Kuma and OpenStatus are open source and free to self-host, and Sentivel has a free plan. Check each free tier's current limits, since they change.

Which alternatives include built-in monitoring?

Better Stack, Hyperping, OpenStatus, Uptime Kuma, and Sentivel include monitoring, so you do not need a separate tool to detect problems. Atlassian Statuspage itself does not.

Is this comparison biased toward Sentivel?

It is written by Sentivel, which we say plainly. We grouped tools by why you might switch rather than ranking ourselves first, stated our real limitations (a smaller integration ecosystem), and pointed you to competitors where they are the better fit.

Originally published at https://www.sentivel.com/comparisons/statuspage-alternatives.