From b0fe974cc945e57454c1ce7f104de08e226e868b Mon Sep 17 00:00:00 2001 From: Maximilian Kaske <56969857+mxkaske@users.noreply.github.com> Date: Sun, 16 Aug 2026 21:21:31 +0200 Subject: [PATCH] chore: more content improvements (#2582) * chore: more content improvements * fix: content --- .../src/app/(landing)/play/checker/page.tsx | 2 + apps/web/src/content/docs.config.ts | 2 +- ...ency-monitoring-benchmark-hono-hetzner.mdx | 26 +++ ...cy-cf-workers-fly-koyeb-raylway-render.mdx | 40 +++- ...ring-latency-vercel-edge-vs-serverless.mdx | 33 +++- .../pages/blog/self-hosting-openstatus.mdx | 2 +- .../pages/blog/status-pages-is-politics.mdx | 26 +++ .../blog/your-customer-found-out-first.mdx | 26 +++ .../pages/compare/atlassian-statuspage.mdx | 32 +++ .../src/content/pages/compare/betterstack.mdx | 36 +++- .../web/src/content/pages/compare/checkly.mdx | 26 +++ .../web/src/content/pages/compare/datadog.mdx | 26 +++ .../src/content/pages/compare/incidentio.mdx | 26 +++ .../src/content/pages/compare/instatus.mdx | 26 +++ .../web/src/content/pages/compare/pingdom.mdx | 26 +++ .../src/content/pages/compare/statusio.mdx | 26 +++ .../src/content/pages/compare/uptime-kuma.mdx | 38 +++- .../content/pages/compare/uptime-robot.mdx | 26 +++ .../docs/concept/latency-vs-response-time.mdx | 68 ++++++- ...w-to-connect-openstatus-to-claude-code.mdx | 2 +- .../docs/guides/how-to-monitor-mcp-server.mdx | 99 +++++++++- .../guides/self-host-status-page-only.mdx | 66 ++++++- .../docs/guides/self-hosting-openstatus.mdx | 2 + .../pages/docs/reference/mcp-server.mdx | 2 +- .../pages/guides/api-service-disruption.mdx | 30 +++ .../guides/best-hosted-status-page-2026.mdx | 26 +++ ...best-incident-communication-tools-2026.mdx | 32 +++ .../best-opensource-status-page-2026.mdx | 26 +++ .../boring-is-better-for-status-pages.mdx | 32 +++ .../connect-openstatus-to-claude-code.mdx | 48 ++++- .../connect-openstatus-to-claude-desktop.mdx | 48 ++++- .../database-performance-degradation.mdx | 24 +++ .../pages/guides/deployment-rollback.mdx | 30 +++ .../dora-incident-reporting-requirements.mdx | 32 +++ .../pages/guides/error-budgets-explained.mdx | 181 +++++++++++++++++ .../pages/guides/feature-degradation.mdx | 32 ++- .../guides/hosted-uptime-kuma-alternative.mdx | 26 +++ ...us-compares-to-other-status-page-tools.mdx | 32 +++ .../src/content/pages/guides/http-headers.mdx | 26 +++ .../pages/guides/incident-communication.mdx | 184 ++++++++++++++++++ .../pages/guides/incident-severity-matrix.mdx | 38 ++++ .../iso-27001-incident-communication.mdx | 32 +++ .../migrate-from-atlassian-statuspage.mdx | 32 +++ .../pages/guides/migrate-from-betterstack.mdx | 38 ++++ .../pages/guides/migrate-from-checkly.mdx | 38 ++++ .../pages/guides/migrate-from-instatus.mdx | 38 ++++ .../guides/migrate-from-uptime-robot.mdx | 26 +++ .../guides/network-connectivity-issues.mdx | 24 +++ .../nis2-incident-reporting-requirements.mdx | 32 +++ ...public-postmortem-underrated-marketing.mdx | 32 +++ .../guides/public-vs-private-status-pages.mdx | 38 ++++ .../pages/guides/scheduled-maintenance.mdx | 30 +++ .../guides/security-incident-response.mdx | 30 +++ .../pages/guides/sla-vs-slo-vs-sli.mdx | 69 ++++++- .../slack-status-page-subscriptions.mdx | 44 +++++ .../guides/soc-2-status-page-requirements.mdx | 32 +++ ...five-atlassian-statuspage-alternatives.mdx | 26 +++ .../guides/top-five-instatus-alternatives.mdx | 32 +++ .../guides/top-five-pingdom-alternatives.mdx | 26 +++ .../guides/what-is-a-good-response-time.mdx | 165 ++++++++++++++++ .../pages/guides/what-is-a-status-page.mdx | 50 +++++ .../guides/what-is-incident-management.mdx | 70 ++++++- .../src/content/pages/guides/what-is-mttr.mdx | 125 +++++++++++- .../guides/what-is-synthetic-monitoring.mdx | 56 ++++++ .../guides/what-is-uptime-monitoring.mdx | 56 ++++++ .../why-every-saas-needs-a-status-page.mdx | 48 ++++- .../guides/why-is-my-monitor-failing.mdx | 32 +++ .../why-uptime-percentage-is-misleading.mdx | 60 +++++- apps/web/src/content/pages/home.mdx | 4 +- .../src/content/pages/product/status-page.mdx | 66 ++++++- .../src/content/pages/product/tooling/api.mdx | 26 +++ .../src/content/pages/product/tooling/cli.mdx | 26 +++ .../pages/product/tooling/mcp-server.mdx | 31 ++- .../pages/product/tooling/terraform.mdx | 26 +++ .../pages/product/uptime-monitoring.mdx | 50 +++++ .../src/content/pages/tools/cdn-checker.mdx | 26 +++ .../src/content/pages/tools/checker-slug.mdx | 8 + apps/web/src/content/pages/tools/checker.mdx | 133 ++++++++++++- apps/web/src/content/pages/tools/curl.mdx | 12 ++ .../src/content/pages/tools/mcp-health.mdx | 2 + .../content/pages/tools/severity-matrix.mdx | 44 +++++ .../src/content/pages/tools/uptime-sla.mdx | 66 ++++++- .../web/src/content/pages/unrelated/about.mdx | 14 ++ apps/web/src/content/pages/use-case/agent.mdx | 32 +++ .../content/pages/use-case/api-providers.mdx | 26 +++ .../src/content/pages/use-case/compliance.mdx | 32 +++ .../web/src/content/pages/use-case/crypto.mdx | 26 +++ .../pages/use-case/enterprise-sales.mdx | 26 +++ .../content/pages/use-case/open-source.mdx | 28 ++- .../pages/use-case/reduce-support-tickets.mdx | 26 +++ .../src/content/pages/use-case/startups.mdx | 38 ++++ 91 files changed, 3516 insertions(+), 64 deletions(-) create mode 100644 apps/web/src/content/pages/guides/error-budgets-explained.mdx create mode 100644 apps/web/src/content/pages/guides/incident-communication.mdx create mode 100644 apps/web/src/content/pages/guides/what-is-a-good-response-time.mdx diff --git a/apps/web/src/app/(landing)/play/checker/page.tsx b/apps/web/src/app/(landing)/play/checker/page.tsx index f8a6dbd1..612c0b11 100644 --- a/apps/web/src/app/(landing)/play/checker/page.tsx +++ b/apps/web/src/app/(landing)/play/checker/page.tsx @@ -13,6 +13,7 @@ import { createJsonLDGraph, getJsonLDBreadcrumbList, getJsonLDFAQPage, + getJsonLDHowTo, getJsonLDWebPage, } from "../../../../lib/metadata/structured-data"; import { @@ -52,6 +53,7 @@ export default async function Page(props: { { name: page.metadata.title, url: `${BASE_URL}/play/checker` }, ]), getJsonLDFAQPage(page), + getJsonLDHowTo(page), ]); return ( diff --git a/apps/web/src/content/docs.config.ts b/apps/web/src/content/docs.config.ts index 528f82c5..ab2a78d6 100644 --- a/apps/web/src/content/docs.config.ts +++ b/apps/web/src/content/docs.config.ts @@ -134,7 +134,7 @@ export const docsNav: DocsNavSection[] = [ }, { slug: "guides/how-to-monitor-mcp-server", - label: "How to Monitor Your Model Context Provider (MCP) Server", + label: "How to Monitor an MCP Server", }, { slug: "guides/how-to-run-synthetic-test-github-action", diff --git a/apps/web/src/content/pages/blog/global-latency-monitoring-benchmark-hono-hetzner.mdx b/apps/web/src/content/pages/blog/global-latency-monitoring-benchmark-hono-hetzner.mdx index 787ae66e..3dc17389 100644 --- a/apps/web/src/content/pages/blog/global-latency-monitoring-benchmark-hono-hetzner.mdx +++ b/apps/web/src/content/pages/blog/global-latency-monitoring-benchmark-hono-hetzner.mdx @@ -148,3 +148,29 @@ Through this global setup, I gained valuable insights into external network perf My 2cts, if you want to pick a PaaS to deploy your next project, pick the one that fits your needs the best, because in the end, the network differences are minimal! If you want to try monitoring our app from multiple global locations, you can try our [global speed checker](/play/checker) for free. + +## Frequently asked questions + +
+ +Barely. In our 7-day benchmark from 17 probes across Fly, Koyeb, and Railway, providers in the same region reported less than 10% latency difference. For example, Fly and Koyeb probes in Frankfurt both showed ~80ms P95 to Hetzner Finland. Geographic distance is the dominant factor. + +
+ +
+ +Frankfurt probes averaged ~80ms P95. US East probes were higher due to transatlantic routing. Singapore probes from Fly, Koyeb, and Railway all reported similar latencies with less than 10% difference between providers, confirming distance is the primary factor. + +
+ +
+ +Network performance alone should not drive your decision. Our benchmark showed minimal latency differences between Fly, Koyeb, and Railway when monitoring the same target from the same region. Pick the PaaS that fits your workflow, pricing, and deployment needs β€” the network differences are negligible. + +
+ +
+ +Deploy your app on any provider, then configure openstatus to monitor it from multiple regions across Fly, Koyeb, and Railway simultaneously. openstatus checks all selected regions in parallel every minute, giving you a true multi-provider, multi-region latency baseline without internal network bias. + +
diff --git a/apps/web/src/content/pages/blog/monitoring-latency-cf-workers-fly-koyeb-raylway-render.mdx b/apps/web/src/content/pages/blog/monitoring-latency-cf-workers-fly-koyeb-raylway-render.mdx index 0bfaaf70..6c31b06b 100644 --- a/apps/web/src/content/pages/blog/monitoring-latency-cf-workers-fly-koyeb-raylway-render.mdx +++ b/apps/web/src/content/pages/blog/monitoring-latency-cf-workers-fly-koyeb-raylway-render.mdx @@ -7,7 +7,7 @@ image: "/assets/posts/monitoring-latency/all-hosting-providers.png" category: "education" faq: - question: "Which cloud provider has the lowest latency?" - answer: "In our benchmark, Cloudflare Workers had the lowest average latency at 182ms across 6 global regions, with a P75 of 138ms. Fly.io in production (with min_machines_running=1) averaged just 61ms, but with cold starts it averaged 1,471ms." + answer: "In our benchmark, Cloudflare Workers had the lowest average latency of the providers left on their default configuration: 182ms across 6 global regions, with a P75 of 138ms. Fly.io was faster still when kept warm β€” 61ms with min_machines_running=1 β€” but averaged 1,471ms once cold starts were allowed." - question: "Does Fly.io have cold start issues?" answer: "Yes. With auto_stop_machines enabled and min_machines_running=0, Fly.io averaged 1,471ms due to cold starts (~1.5s machine boot time). Setting min_machines_running=1 eliminates cold starts and brings the average down to 61ms." - question: "How does Cloudflare Workers latency compare to Railway and Render?" @@ -25,7 +25,7 @@ You want to know which cloud providers offer the lowest latency? In this post, I compare the latency of [Cloudflare Workers](#cloudflare-workers), [Fly](#flyio), [Koyeb](#koyeb), [Railway](#railway) and [Render](#render) using -[OpenStatus](https://www.openstatus.dev). +[openstatus](https://www.openstatus.dev). I deployed the application on the cheapest or free tier offered by each provider. @@ -49,7 +49,7 @@ app.get("/", (c) => { You can find the code in the [`status-code` repository](https://github.com/openstatusHQ/status-code), it’s open source πŸ˜‰. -OpenStatus monitored our endpoint every **10 minutes** from **6 locations** +Openstatus monitored our endpoint every **10 minutes** from **6 locations** located in Amsterdam, Ashburn, Hong Kong, Johannesburg, Sao Paulo and Sydney. It's a good way to test our own product and improve it. @@ -288,7 +288,7 @@ The machine starts slowly, as indicated by the logs showing a start time of 2024-02-14T11:24:17.628 proxy[286560ea703108] ams [info] machine became reachable in 7.03669ms ``` -#### OpenStatus Prod metrics +#### Openstatus Prod metrics If you update your fly.toml file to include the following, you can get the zero cold start and achieve a better latency. @@ -666,5 +666,35 @@ We use Fly.io in production and are satisfied with it. I haven't included Vercel in this test. But we have a blog post comparing [Vercel Serverless vs Edge vs Serverless](/blog/monitoring-latency-vercel-edge-vs-serverless). +Want the same measurement for your own endpoint? Run it through the +[website speed test](/play/checker) β€” 28 regions with the per-phase timing +breakdown, and no account needed. + If you want to monitor your API or website, create an account on -[OpenStatus](/app/sign-up?ref=blog-monitoring). +[openstatus](/app/sign-up?ref=blog-monitoring). + +## Frequently asked questions + +
+ +In our benchmark, Cloudflare Workers had the lowest average latency of the providers left on their default configuration: 182ms across 6 global regions, with a P75 of 138ms. Fly.io was faster still when kept warm β€” 61ms with min_machines_running=1 β€” but averaged 1,471ms once cold starts were allowed. + +
+ +
+ +Yes. With auto_stop_machines enabled and min_machines_running=0, Fly.io averaged 1,471ms due to cold starts (~1.5s machine boot time). Setting min_machines_running=1 eliminates cold starts and brings the average down to 61ms. + +
+ +
+ +Cloudflare Workers averaged 182ms with 100% uptime. Railway averaged 381ms with 99.991% uptime (1 failure). Render averaged 451ms with 99.89% uptime (12 failures). Cloudflare Workers deploy globally to 275+ locations, while Railway and Render run from a single region. + +
+ +
+ +Render had the most failures with 12 failed checks and 99.89% uptime over 2 weeks. Railway had 1 failure (99.991% uptime). Cloudflare Workers, Fly.io, and Koyeb all had 0 failures and 100% uptime. + +
diff --git a/apps/web/src/content/pages/blog/monitoring-latency-vercel-edge-vs-serverless.mdx b/apps/web/src/content/pages/blog/monitoring-latency-vercel-edge-vs-serverless.mdx index a431da80..18acaa76 100644 --- a/apps/web/src/content/pages/blog/monitoring-latency-vercel-edge-vs-serverless.mdx +++ b/apps/web/src/content/pages/blog/monitoring-latency-vercel-edge-vs-serverless.mdx @@ -336,5 +336,36 @@ Edge functions have similar latency regardless of the user's location. If you value your users and have a worldwide audience, you should consider Edge Functions. -Create an account on [OpenStatus](/app/sign-up) to +You can reproduce this for your own deployment with the +[website speed test](/play/checker) β€” it runs from the same 28 regions and breaks +each request into DNS, TCP, TLS, and TTFB, which is how the cold-start gap above +becomes visible. + +Create an account on [openstatus](/app/sign-up) to monitor your API and get notified when your latency increases. + +## Frequently asked questions + +
+ +Yes. In our benchmark from 6 global regions, Edge functions averaged 106ms (P50) vs 246ms for warm Serverless and 859ms for cold Serverless. Edge is about 9x faster during cold starts and 2x faster when warm. + +
+ +
+ +In our test, Vercel Serverless cold starts averaged 859ms (P50), with P95 at 1,046ms and P99 at 1,156ms. Functions were pinged every 30 minutes to ensure they scaled down between requests. + +
+ +
+ +Vercel Edge functions have negligible cold starts. In our benchmark, Edge functions maintained a consistent P50 of 106ms and P99 of 328ms regardless of request frequency, compared to Serverless which jumped from 246ms (warm) to 859ms (cold). + +
+ +
+ +Vercel Serverless functions are deployed in a single region (iad1 β€” Washington, D.C. by default). All requests are routed through a nearby data center before being forwarded to the function's region. Edge functions are deployed globally and execute in the datacenter closest to the user. + +
diff --git a/apps/web/src/content/pages/blog/self-hosting-openstatus.mdx b/apps/web/src/content/pages/blog/self-hosting-openstatus.mdx index af8e05a5..9c68859b 100644 --- a/apps/web/src/content/pages/blog/self-hosting-openstatus.mdx +++ b/apps/web/src/content/pages/blog/self-hosting-openstatus.mdx @@ -74,6 +74,6 @@ Self-hosting is powerful, but it isn't a silver bullet. Monitoring your own moni Whether you prefer the simplicity of openstatus's managed SaaS or the control of a self-hosted instance, the barrier to entry has never been lower. Self-hosting is no longer an afterthought β€” it's a fully featured, reliable way to keep tabs on your stack. -Give the updated self-hosting guide a spin and let the team know how it works for your setup! +Give the updated [self-hosting guide](/docs/guides/self-hosting-openstatus) a spin and let the team know how it works for your setup! If you only want the status page and not the monitoring stack, there's a [lightweight status-page-only setup](/docs/guides/self-host-status-page-only) that runs four services instead of the full platform. Don't forget to join the [community](https://www.openstatus.dev/discord) if you run into issues! And you can check out my work at [GitHub](https://github.com/zapteryx) :) diff --git a/apps/web/src/content/pages/blog/status-pages-is-politics.mdx b/apps/web/src/content/pages/blog/status-pages-is-politics.mdx index 78955e5f..06ec904e 100644 --- a/apps/web/src/content/pages/blog/status-pages-is-politics.mdx +++ b/apps/web/src/content/pages/blog/status-pages-is-politics.mdx @@ -55,3 +55,29 @@ Until then, every vendor who publishes honest incident reports is subsidizing co --- The founder who lost that deal made the harder choice. They could have scrubbed their page, played the game, and closed the deal. They didn't. That takes conviction. The least the rest of us can do is stop pretending that a green status page means anything at all. + +## Frequently asked questions + +
+ +Every system has incidents. A status page that has been green for months likely means the vendor isn't reporting incidents, not that they aren't having them. Without standardized reporting, a clean status page is indistinguishable from an opaque one. + +
+ +
+ +Instead of comparing which page looks cleaner, ask vendors to show their incident history for the past 6 months. If they claim zero incidents, press harder. Treat transparency as a trust signal, not a liability. + +
+ +
+ +When there's no standard for what gets reported, buyers rationally pick the vendor with fewer visible incidents. The signal is inverted: transparency looks like unreliability, and opacity looks like stability. This rewards the wrong behavior. + +
+ +
+ +Big organizations know public status pages are political documents. They run private, internal status pages so that teams across silos can coordinate on the actual operational truth β€” not the sanitized version crafted for public consumption. + +
diff --git a/apps/web/src/content/pages/blog/your-customer-found-out-first.mdx b/apps/web/src/content/pages/blog/your-customer-found-out-first.mdx index dd750a06..3b72607c 100644 --- a/apps/web/src/content/pages/blog/your-customer-found-out-first.mdx +++ b/apps/web/src/content/pages/blog/your-customer-found-out-first.mdx @@ -97,3 +97,29 @@ None of this is exotic. It's just the difference between monitoring built to *kn This is why we build [openstatus](https://www.openstatus.dev): synthetic checks that run your actual transactions with real assertions, from regions all over the world, tied to a status page that's part of the incident flow instead of an afterthought. It's [open source](https://github.com/openstatusHQ/openstatus) β€” the checker, the dashboard, all of it β€” because "trust our monitoring" should not itself require blind trust. Your customers already monitor your product with every request they make. The only question is whether you find out before they tell you. + +## Frequently asked questions + +
+ +Because most monitoring checks the wrong thing: a cached homepage instead of the login, checkout, or API paths customers actually use. A CDN-served 200 can stay green while every authenticated request fails. + +
+ +
+ +No. Error pages, maintenance pages, empty JSON responses, and broken backends frequently return 200. A meaningful check asserts on the response body and latency, not just the status code. + +
+ +
+ +A single-region check tells you the service is reachable from that region β€” nothing more. DNS issues, routing problems, and regional provider outages routinely take a service down for one continent while it stays up for another. + +
+ +
+ +Customers forgive incidents; they don't forgive silence. Publishing before the support tickets arrive turns 'they didn't even know' into 'they told me before I noticed' β€” and deflects the duplicate tickets while you fix the actual problem. + +
diff --git a/apps/web/src/content/pages/compare/atlassian-statuspage.mdx b/apps/web/src/content/pages/compare/atlassian-statuspage.mdx index 9445e235..b6e7c044 100644 --- a/apps/web/src/content/pages/compare/atlassian-statuspage.mdx +++ b/apps/web/src/content/pages/compare/atlassian-statuspage.mdx @@ -97,6 +97,38 @@ With OpsGenie shutting down in April 2027, this is also a good time to consolida - [Status Pages for Compliance](/use-case/compliance) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes. Openstatus includes built-in uptime monitoring from 28 global regions β€” something Atlassian Statuspage does not offer at all. Openstatus pricing is flat ($30/mo) and does not scale with subscriber count. Atlassian Statuspage charges per subscriber tier, meaning your bill grows as your audience does. Openstatus is also open-source and self-hostable. + +
+ +
+ +Yes. Atlassian Statuspage has no built-in monitoring. You must connect a separate tool (Datadog, Pingdom, etc.) to detect incidents. Openstatus monitors your endpoints from 28 regions simultaneously and can update your status page automatically based on check results. + +
+ +
+ +Atlassian Statuspage starts at $29/month for one page and 100 subscribers, jumping to $99/month for three pages and $399/month for custom HTML/CSS. Subscriber-count tiers add cost as your audience grows. Openstatus starts at $30/month with flat pricing, unlimited subscribers, and monitoring included. + +
+ +
+ +OpsGenie, Atlassian's incident management tool often used alongside Statuspage, is shutting down in April 2027. Teams using the Statuspage + OpsGenie combination will need to find replacements for both. Openstatus covers the monitoring and status page layer in one product. + +
+ +
+ +Yes. Openstatus is open-source (AGPL-3.0) and fully self-hostable. Atlassian Statuspage is a closed-source SaaS with no self-hosting option. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/betterstack.mdx b/apps/web/src/content/pages/compare/betterstack.mdx index 3f54758f..b0bd273f 100644 --- a/apps/web/src/content/pages/compare/betterstack.mdx +++ b/apps/web/src/content/pages/compare/betterstack.mdx @@ -57,7 +57,9 @@ BetterStack's base price looks competitive, but add-ons for private status pages ## Built for AI and Agentic Workflows -Openstatus ships a CLI that integrates natively into AI-driven workflows. Whether you're using an AI agent or building your own agentic automation, the openstatus CLI lets you create monitors, trigger checks, and manage incidents programmatically, no browser required. BetterUptime has no CLI and no tooling designed for machine-to-machine interaction. +Openstatus ships a CLI that integrates natively into AI-driven workflows. Whether you're using an AI agent or building your own agentic automation, the openstatus CLI lets you create monitors, trigger checks, and manage incidents programmatically, no browser required. BetterStack has no CLI and no tooling designed for machine-to-machine interaction. + +There is also an [MCP server](/docs/reference/mcp-server), so an AI client can query monitor state and manage incidents directly over the Model Context Protocol. ## When to Choose openstatus @@ -90,6 +92,38 @@ Use our **[BetterStack import tool](/guides/migrate-from-betterstack)** to autom - [Status Pages for Compliance](/use-case/compliance) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes. openstatus offers uptime monitoring from 28 regions (vs. BetterStack's 4), an open-source codebase, parallel check scheduling, and unlimited status page subscribers β€” all included in the base price. BetterStack charges extra for private status pages ($42/mo.) and subscriber tiers ($42/mo. per 1000). openstatus is also bootstrapped and self-hostable. + +
+ +
+ +openstatus starts free (Hobby plan) and paid plans begin at $30/month (Starter) and $100/month (Pro). Private status pages and unlimited subscribers are included. BetterStack's equivalent features require paid add-ons on top of their base price. + +
+ +
+ +openstatus monitors from 28 regions worldwide across 3 cloud providers. BetterStack uses approximately 4 regions. openstatus also uses a parallel scheduling strategy β€” all selected regions fire simultaneously β€” whereas BetterStack uses round-robin scheduling, cycling through regions one at a time. + +
+ +
+ +Yes. openstatus is open-source (AGPL-3.0 license) and fully self-hostable with Docker. BetterStack is a closed-source SaaS product with no self-hosting option. + +
+ +
+ +Parallel monitoring (openstatus) checks all selected regions simultaneously at each interval, giving you a true global snapshot of availability. Round-robin monitoring (BetterStack) cycles through regions one at a time, so each check only tests from a single location. Parallel monitoring detects regional outages faster. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/checkly.mdx b/apps/web/src/content/pages/compare/checkly.mdx index c1a05bc1..e923ba93 100644 --- a/apps/web/src/content/pages/compare/checkly.mdx +++ b/apps/web/src/content/pages/compare/checkly.mdx @@ -83,6 +83,32 @@ If you rely heavily on Playwright browser checks, openstatus is not a direct rep - [Status Pages for API Providers](/use-case/api-providers) - [Pricing](/pricing) +## Frequently asked questions + +
+ +It depends on your use case. Openstatus is focused on uptime monitoring and status pages β€” it excels at HTTP, TCP, and DNS checks from 28 global regions. Checkly is focused on synthetic monitoring with browser-based checks using Playwright. If you need uptime monitoring with a public status page, openstatus is the stronger choice. If you need end-to-end browser testing as monitoring, Checkly is more suitable. + +
+ +
+ +Yes. Openstatus monitors from 28 regions worldwide. Checkly uses approximately 19 regions. Openstatus also checks all regions simultaneously (parallel scheduling) rather than cycling through them. + +
+ +
+ +Yes. Openstatus includes branded status pages with custom domains, maintenance windows, and subscriber notifications on all plans. Checkly does not offer a built-in public status page product. + +
+ +
+ +Yes. Openstatus is AGPL-3.0-licensed and fully self-hostable. Checkly is a closed-source SaaS product. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/datadog.mdx b/apps/web/src/content/pages/compare/datadog.mdx index cf60443f..db86a874 100644 --- a/apps/web/src/content/pages/compare/datadog.mdx +++ b/apps/web/src/content/pages/compare/datadog.mdx @@ -86,6 +86,32 @@ If you depend on Datadog's browser synthetics and trace correlation, keep those - [Status Pages for API Providers](/use-case/api-providers) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes, for uptime and API monitoring with a status page. Openstatus runs HTTP, TCP, and DNS checks from 28 regions with flat pricing and a built-in status page, and it's open-source. Datadog Synthetics is far more powerful for browser-based, multi-step synthetic tests inside a full observability platform β€” but its per-run, per-seat pricing climbs steeply, and it has no standalone free tier for synthetics. + +
+ +
+ +Datadog prices synthetic tests per run and per location, so frequent checks across multiple regions add up fast β€” published comparisons cite thousands of dollars a month for high-frequency uptime checks. Openstatus uses flat pricing: paid plans start at $30/month for 20 monitors across 28 regions with no per-run fees and unlimited team members. + +
+ +
+ +Yes. Openstatus includes a branded public status page with custom domains, maintenance windows, and subscriber notifications on every plan. Datadog offers a status page product, but it's a separate part of the platform and assumes you're already a Datadog customer. + +
+ +
+ +If you need browser-based, scripted multi-step synthetic tests tightly correlated with APM traces, logs, and metrics in one platform, Datadog is the stronger choice. Openstatus is the better fit when you mainly need uptime and API checks plus a status page without the platform cost. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/incidentio.mdx b/apps/web/src/content/pages/compare/incidentio.mdx index f4c88b40..e1d88d9d 100644 --- a/apps/web/src/content/pages/compare/incidentio.mdx +++ b/apps/web/src/content/pages/compare/incidentio.mdx @@ -83,6 +83,32 @@ If you only need the detection and communication layer, openstatus covers it alo - [Status Pages for Compliance](/use-case/compliance) - [Pricing](/pricing) +## Frequently asked questions + +
+ +It depends on what you need. Incident.io is an incident management platform β€” on-call scheduling, Slack-based workflows, AI post-mortems. Openstatus is a monitoring and status page platform. If your primary need is detecting outages and communicating them to users, openstatus is the more direct fit. If you already have monitoring and need sophisticated incident coordination across a large on-call team, incident.io is built for that. + +
+ +
+ +No. Incident.io does not monitor your services. It receives alerts from external tools like Datadog, PagerDuty, or Prometheus and routes them through its incident workflow. You still need a separate monitoring tool. Openstatus includes uptime monitoring from 28 regions as part of the same product. + +
+ +
+ +Openstatus covers the detect-and-communicate part of incident response: monitors detect issues and your status page communicates them to users. It does not have on-call scheduling, escalation policies, or Slack-based incident coordination. For teams that need those workflows, incident.io is the stronger choice. + +
+ +
+ +Openstatus starts at $30/month with unlimited team members. Incident.io uses per-seat pricing on paid plans and targets mid-to-large engineering teams. For small teams that only need monitoring and a status page, openstatus is significantly cheaper. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/instatus.mdx b/apps/web/src/content/pages/compare/instatus.mdx index b5d49336..d1a68872 100644 --- a/apps/web/src/content/pages/compare/instatus.mdx +++ b/apps/web/src/content/pages/compare/instatus.mdx @@ -84,6 +84,32 @@ Use our **[Instatus import tool](/guides/migrate-from-instatus)** to automatical - [Status Pages for Compliance](/use-case/compliance) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes, especially if you need real uptime monitoring alongside your status page. Instatus is a status-page-first product with basic HTTP monitoring added later. Openstatus was built around monitoring first β€” checking from 28 global regions simultaneously β€” with status pages as a native part of the product, not a bolt-on. + +
+ +
+ +Yes. Openstatus includes branded status pages with custom domains, maintenance windows, and subscriber notifications on all paid plans. The status page is tightly coupled to your monitors, so incidents and response times reflect real check results. + +
+ +
+ +Instatus starts at $20/month for one custom-domain status page. Openstatus starts at $30/month and includes uptime monitoring from 28 regions, unlimited team members, and monitoring-as-code tooling. If you need both monitoring and a status page, openstatus covers both in one plan. + +
+ +
+ +Yes. Openstatus is open-source (AGPL-3.0) and fully self-hostable. Instatus is a closed-source SaaS with no self-hosting option. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/pingdom.mdx b/apps/web/src/content/pages/compare/pingdom.mdx index 07e0ec11..2cdf45ad 100644 --- a/apps/web/src/content/pages/compare/pingdom.mdx +++ b/apps/web/src/content/pages/compare/pingdom.mdx @@ -89,6 +89,32 @@ If you rely on Pingdom's RUM or transaction monitoring, openstatus is not a drop - [Reduce Support Tickets with a Status Page](/use-case/reduce-support-tickets) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes, for uptime monitoring and status pages. Openstatus monitors from 28 global regions simultaneously, is open-source and self-hostable, includes a built-in public status page, and starts free. Pingdom is a closed-source SolarWinds product with no free tier and no public status page, though it offers real user monitoring (RUM) and transaction checks that openstatus does not. + +
+ +
+ +No. Pingdom discontinued its free tier after the SolarWinds acquisition. The cheapest paid plan starts at around $15/month (billed annually) for 10 uptime checks, with a 14-day trial. Openstatus has a permanent free plan with 1 monitor across 6 regions. + +
+ +
+ +Openstatus includes a built-in branded public status page with custom domains, maintenance windows, and subscriber notifications on every plan. Pingdom does not offer a public status page product β€” you would need a separate tool for incident communication. + +
+ +
+ +Yes. Openstatus is AGPL-3.0-licensed and fully self-hostable. Pingdom is a closed-source SaaS owned by SolarWinds with no self-hosting option. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/statusio.mdx b/apps/web/src/content/pages/compare/statusio.mdx index 4da60d65..f6d6fbff 100644 --- a/apps/web/src/content/pages/compare/statusio.mdx +++ b/apps/web/src/content/pages/compare/statusio.mdx @@ -83,6 +83,32 @@ Status.io costs nearly 3x more than openstatus's Starter plan β€” and doesn't in - [Status Pages for Enterprise Sales](/use-case/enterprise-sales) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes. Openstatus includes built-in uptime monitoring from 28 global regions, which Status.io does not offer. Openstatus is open-source, self-hostable, and starts at $30/month with unlimited team members. Status.io is a closed-source SaaS starting around $79/month with no monitoring capabilities. + +
+ +
+ +Yes. Status.io is a hosted status page platform with no built-in monitoring. You still need a separate tool to detect incidents. Openstatus monitors your endpoints from 28 regions simultaneously and can reflect real check results on your status page. + +
+ +
+ +Status.io starts around $79/month. Openstatus starts at $30/month and includes uptime monitoring, unlimited team members, and developer tooling (CLI, Terraform, GitHub Actions) that Status.io does not offer. + +
+ +
+ +Yes. Openstatus is open-source (AGPL-3.0) and fully self-hostable. Status.io is a closed-source SaaS with no self-hosting option. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/uptime-kuma.mdx b/apps/web/src/content/pages/compare/uptime-kuma.mdx index b24ca48d..edcb604c 100644 --- a/apps/web/src/content/pages/compare/uptime-kuma.mdx +++ b/apps/web/src/content/pages/compare/uptime-kuma.mdx @@ -14,7 +14,7 @@ faq: - question: "Does openstatus support self-hosting like Uptime Kuma?" answer: "Yes. openstatus is AGPL-3.0 licensed and can be self-hosted with Docker. You also get the option to use the managed cloud service without managing any infrastructure." - question: "Can openstatus monitor from multiple regions unlike Uptime Kuma?" - answer: "Yes. openstatus monitors from 28 regions across 3 cloud providers (AWS, GCP, Fly.io) simultaneously. Uptime Kuma only checks from the single server where it is installed, which means it cannot detect regional outages." + answer: "Yes. openstatus monitors from 28 regions across 3 cloud providers (Fly.io, Koyeb, and Railway) simultaneously. Uptime Kuma only checks from the single server where it is installed, which means it cannot detect regional outages." --- ## Looking for an Uptime Kuma alternative? @@ -76,15 +76,51 @@ Uptime Kuma is free software, but running it requires a server. A basic VPS cost 4. **Configure alerts** β€” openstatus supports Slack, Discord, Email, PagerDuty, OpsGenie, and more 5. **Decommission your server** β€” once your monitors are running on openstatus, you can shut down your Uptime Kuma instance and stop paying for the VPS +openstatus ships automated importers for Statuspage, Better Stack, Instatus, and Checkly, but not for Uptime Kuma β€” so monitors are recreated rather than imported. [Monitoring as code](/docs/concept/uptime-monitoring-as-code) turns that into a one-time YAML file rather than an afternoon of dashboard clicking, and the same file stays version-controlled afterwards. + If you prefer to self-host openstatus instead, check the [GitHub repository](https://github.com/openstatusHQ/openstatus) for Docker setup instructions. ## Related Resources +- [A hosted Uptime Kuma alternative](/guides/hosted-uptime-kuma-alternative) β€” the case for managed hosting in more depth - [Best Open Source Status Pages in 2026](/guides/best-opensource-status-page-2026) - [Why Every SaaS Needs a Status Page](/guides/why-every-saas-needs-a-status-page) - [Status Pages for Open Source Projects](/use-case/open-source) +- [Uptime monitoring](/uptime-monitoring) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes, especially if you want managed cloud hosting or global multi-region monitoring. Both are open-source, but openstatus is available as a SaaS (no server to maintain) and monitors from 28 regions worldwide. Uptime Kuma is self-hosted only and checks from a single server location. + +
+ +
+ +The main difference is hosting model and monitoring coverage. Uptime Kuma is self-hosted only β€” you run it on your own server and it monitors from that single location. openstatus is available as a managed SaaS or self-hosted, and checks from 28 regions across multiple cloud providers simultaneously. + +
+ +
+ +openstatus has a free Hobby plan (1 monitor, 6 regions, 1 status page) with no credit card required. Uptime Kuma is fully free and open-source but requires you to provision, host, and maintain your own server. + +
+ +
+ +Yes. openstatus is AGPL-3.0 licensed and can be self-hosted with Docker. You also get the option to use the managed cloud service without managing any infrastructure. + +
+ +
+ +Yes. openstatus monitors from 28 regions across 3 cloud providers (Fly.io, Koyeb, and Railway) simultaneously. Uptime Kuma only checks from the single server where it is installed, which means it cannot detect regional outages. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/compare/uptime-robot.mdx b/apps/web/src/content/pages/compare/uptime-robot.mdx index fed7d04b..a838f1f7 100644 --- a/apps/web/src/content/pages/compare/uptime-robot.mdx +++ b/apps/web/src/content/pages/compare/uptime-robot.mdx @@ -92,6 +92,32 @@ Most teams complete the switch in under an hour. If you need help, reach out at - [Reduce Support Tickets with a Status Page](/use-case/reduce-support-tickets) - [Pricing](/pricing) +## Frequently asked questions + +
+ +Yes. Openstatus monitors from 28 global regions simultaneously (UptimeRobot checks from a single location at a time), is open-source and self-hostable, includes unlimited team members on paid plans, and supports OpenTelemetry export and CI/CD integration via GitHub Actions β€” none of which UptimeRobot offers. + +
+ +
+ +Openstatus starts free and paid plans begin at $30/month with unlimited team members. UptimeRobot charges an additional $19 per seat for team members, which adds up quickly for larger teams. + +
+ +
+ +Yes. Openstatus checks from 28 regions worldwide across multiple cloud providers. UptimeRobot does not offer meaningful multi-region monitoring. + +
+ +
+ +Yes. Openstatus is open-source (AGPL-3.0 license) and self-hostable. UptimeRobot is a closed-source SaaS with no self-hosting option. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx b/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx index 69b64cdf..de39c9d0 100644 --- a/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx +++ b/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx @@ -57,9 +57,9 @@ To measure latency, you can monitor endpoints like `/ping` or `/healthcheck` wit ``` -Response time is the total time from the moment a user's request is sent until the moment the first byte of the server's response is received. It includes both the network latency and the server's processing time. +Response time is the total time from the moment a user's request is sent until the server's response has been fully received. It includes the network latency, the server's processing time, and the time spent streaming the response body back. -Response time = network latency + server processing time +Response time = network latency + server processing time + transfer time The server processing time is the duration the server spends on tasks like: @@ -69,6 +69,37 @@ The server processing time is the duration the server spends on tasks like: A high response time often indicates a problem with the server-side application itself. For example, slow database queries or inefficient application code can dramatically increase the response time, even if the network latency is low. +## The request in phases: DNS, TCP, TLS, TTFB, transfer + +"Latency" and "response time" are summaries. A single request is really five +consecutive phases, and knowing which one is slow is the difference between guessing +and fixing. openstatus records each phase as its own duration: + +| Phase | What it measures | What a slow number means | +| --- | --- | --- | +| **DNS** | Resolving the hostname to an IP address | Slow or distant nameservers, or a TTL so short that nothing is ever cached | +| **Connect** | The TCP handshake opening the socket | Mostly physical distance. This is the phase a CDN or edge deployment shortens | +| **TLS** | Negotiating the encrypted connection | A long certificate chain, no session resumption, or an old TLS version | +| **TTFB** | Request sent β†’ first byte of the response returns | Your application's own work: database queries, rendering, upstream API calls | +| **Transfer** | Streaming the rest of the response body | A large payload, no compression, or a slow link | + +Two clarifications that trip people up. + +**TTFB here is a phase duration, not a cumulative timer.** Many tools define "time +to first byte" as everything from the start of the request β€” DNS, connect, and TLS +included. In this breakdown those phases are already accounted for separately, so +TTFB isolates the part your server is actually responsible for. A 40ms TTFB behind a +300ms connect phase is a fast application sitting a long way from the probe. + +**Response time is the sum, not the first byte.** The connection phases β€” DNS, +connect, and TLS β€” are the network cost of getting there before your application does +any work. Add TTFB and transfer and you have total response time, which is what a +user waits through. + +This is also why a single number hides the diagnosis. Two endpoints both answering +in 600ms are not equivalent if one spends 500ms in TLS and the other spends 500ms in +TTFB. The first is a connection problem you fix with infrastructure; the second is +code. ## Why the distinction matters for uptime monitoring @@ -114,17 +145,48 @@ By monitoring both metrics, you can quickly pinpoint whether a performance slowd - Could be network saturation or a DDoS attack. - Check: network bandwidth, traffic patterns, security. +## How to measure both + +You need two things: the phase breakdown, and more than one vantage point. + +**For a single check right now**, run the URL through the +[global speed test](/play/checker). It requests from 28 regions in parallel and +returns all five phases per region, which is enough to tell a distance problem from +an application problem in one pass. No account required. + +**For anything you care about over time**, one sample is not evidence. Latency moves +with traffic, deploys, and time of day, so a number from a single moment tells you +almost nothing about the distribution your users actually see. +[Uptime monitoring](/uptime-monitoring) re-runs the same check on a schedule, keeps +the history, and alerts on degradation rather than only on failure β€” which is the +difference between finding out from a graph and finding out from a customer. + +Whichever you use, measure from where your users are. A check that only runs from +the same continent as your origin will report healthy numbers indefinitely while +users on the other side of the world time out. + ## What openstatus tracks openstatus monitors and displays: - **Total response time** β€” the complete user experience. -- **Detailed timing breakdown** β€” DNS, TCP, TLS, request, response. +- **Detailed timing breakdown** β€” DNS, connect, TLS, TTFB, and transfer. - **Regional differences** β€” compare performance across locations. - **Historical trends** β€” identify patterns over time. +## Related reliability concepts + +Latency and response time are the raw measurements. These build on top of them: + +- **[What is a good response time?](/guides/what-is-a-good-response-time)** β€” target numbers for both the server and the browser half, judged at the right percentile. +- **[SLA vs SLO vs SLI](/guides/sla-vs-slo-vs-sli)** β€” turning a measurement into an internal target and a customer promise. +- **[Error budgets explained](/guides/error-budgets-explained)** β€” how much failure your target actually permits, and what to do when it is spent. +- **[What is MTTR?](/guides/what-is-mttr)** β€” measuring recovery once something has gone wrong. +- **[Why uptime percentage alone is misleading](/guides/why-uptime-percentage-is-misleading)** β€” why a single availability number hides the distribution. + ## Next steps +- **[Run a one-off speed test](/play/checker)** β€” see the timing breakdown for your own URL from 28 regions, no account needed. - **[Create your first monitor](/docs/tutorial/create-your-first-monitor)** β€” start tracking these metrics. - **[Understanding uptime monitoring](/docs/concept/uptime-monitoring)** β€” broader monitoring concepts. - **[HTTP monitor reference](/docs/reference/http-monitor)** β€” technical specifications. diff --git a/apps/web/src/content/pages/docs/guides/how-to-connect-openstatus-to-claude-code.mdx b/apps/web/src/content/pages/docs/guides/how-to-connect-openstatus-to-claude-code.mdx index 3c6b1a66..d86d4f74 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-connect-openstatus-to-claude-code.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-connect-openstatus-to-claude-code.mdx @@ -93,7 +93,7 @@ If you have a write-scoped key, try drafting an incident β€” Claude Code will sh > draft a status report on my "api" page: investigating elevated latency on the payment endpoint ``` - + ## What you've accomplished diff --git a/apps/web/src/content/pages/docs/guides/how-to-monitor-mcp-server.mdx b/apps/web/src/content/pages/docs/guides/how-to-monitor-mcp-server.mdx index 8e0264e4..b53323ed 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-monitor-mcp-server.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-monitor-mcp-server.mdx @@ -1,14 +1,22 @@ --- category: Guides -title: How to Monitor Your Model Context Provider (MCP) Server -description: Learn how to monitor your MCP server with openstatus using JSON-RPC ping checks +title: How to Monitor an MCP Server +description: Monitor an MCP server with openstatus - JSON-RPC health checks, tools/list assertions, authenticated endpoints, and uptime alerts from 28 regions. +seo: + title: "How to Monitor an MCP Server - Health Checks & Uptime" sidebar: label: Monitor your MCP Server --- +> **Just want to test a server once?** Run it through the free +> [MCP server health check](/play/mcp-health) β€” full JSON-RPC handshake from your +> browser, no account. This guide is for monitoring it continuously. + ## Problem -Running a Model Context Provider (MCP) server is critical for your AI applications, but traditional HTTP monitoring often falls short. MCP servers communicate using the JSON-RPC 2.0 protocol, requiring specific request/response patterns that standard health checks don't cover. How can you confidently ensure your MCP server is healthy and responsive at all times, without custom scripts or complex setups? +Running a Model Context Protocol (MCP) server is critical for your AI applications, but traditional HTTP monitoring often falls short. MCP servers communicate using the JSON-RPC 2.0 protocol, requiring specific request/response patterns that standard health checks don't cover. A server can return `200 OK` with an HTML error page, stop echoing the JSON-RPC `id`, or quietly return an empty `tools/list` β€” and every one of those looks healthy to a status-code pinger while breaking every AI client that connects. + +How can you confidently ensure your MCP server is healthy and responsive at all times, without custom scripts or complex setups? ## Solution @@ -80,9 +88,11 @@ The key fields in this YAML configuration: - `statusCode` β€” ensures the HTTP response is `200 OK`. - `textBody` β€” verifies that the response payload exactly matches the expected JSON-RPC `ping` result. -### 3. Test your MCP server (optional) +### 3. Test your MCP server online first -Before deploying your monitor, you can manually test your MCP server's `ping` endpoint with `curl` to confirm it responds as expected. This helps verify the `target` value for your `textBody` assertion. +Before deploying a monitor, confirm the server actually speaks MCP. The quickest way is the [MCP server health check](/play/mcp-health) β€” paste your URL and it runs the full handshake (`initialize`, `ping`, `tools/list`) from the browser, shows the per-step latency, and tells you whether the endpoint is Healthy, Partial, Auth Required, or Unreachable. Use it to read off the exact response your assertion needs to match. + +You can also test the `ping` endpoint manually with `curl`. This helps verify the `target` value for your `textBody` assertion. ```bash curl -X POST \\ @@ -103,13 +113,92 @@ openstatus monitors apply --config openstatus.yaml This command uploads your configuration, and monitoring will begin immediately. +## Monitoring an MCP server that requires authentication + +Most production MCP servers are not public. An unauthenticated `ping` against one returns `401 Unauthorized`, usually with a `WWW-Authenticate: Bearer` header, so a monitor without credentials will report your healthy server as down. + +Add the same `Authorization` header your AI clients use: + +```yaml + request: + url: https://mcp.example.com/mcp + method: POST + headers: + Authorization: Bearer + User-Agent: openstatus + Accept: application/json, text/event-stream + Content-Type: application/json +``` + +Two things to plan for: + +- **Token rotation is the most common false alarm.** When the token expires, the monitor goes down while the server is perfectly healthy. Assert on `statusCode` `eq` `200` so a `401` fails loudly and is easy to recognise, rather than debugging it as an outage. +- **Keep the credential out of your repository.** This YAML is meant to be version-controlled, so use a token scoped to read-only health checks β€” not a production credential β€” and rotate it on a schedule you control. + +If you are unsure which authorization server issues your token, the [health check tool](/play/mcp-health) parses the `WWW-Authenticate` challenge and surfaces the OAuth resource metadata for you. + +## Monitoring tool availability and latency + +A `ping` proves the server is answering. It does not prove the server still exposes the tools your agents call β€” an empty `tools/list` is the failure mode that breaks AI clients while every uptime dashboard stays green. + +Add a second monitor that calls `tools/list` and asserts a known tool name is present: + +```yaml +mcp-tools: + name: "MCP tools/list" + description: "Verify the MCP server still exposes its tools" + frequency: "5m" + active: true + regions: ["iad", "ams", "sin"] + retry: 3 + kind: http + request: + url: https://hf.co/mcp + method: POST + body: > + { + "jsonrpc": "2.0", + "id": "openstatus", + "method": "tools/list" + } + headers: + User-Agent: openstatus + Accept: application/json, text/event-stream + Content-Type: application/json + assertions: + - kind: statusCode + compare: eq + target: 200 + - kind: textBody + compare: contains + target: "your_tool_name" +``` + +Assert on the bare tool name, not on `"name":"your_tool_name"`. `contains` matches literally, and servers differ in whether they emit a space after the JSON key β€” an assertion written against the compact form fails the moment a server pretty-prints its response. + +`tools/list` is also the more honest latency signal. `ping` usually returns an empty result and measures little more than the network round trip, whereas `tools/list` exercises the server's actual request path β€” which is what an agent waits on. Run it at a lower frequency than `ping` if you want to keep request volume down. + +## What to alert on + +Not every MCP failure deserves the same response: + +- **`ping` failing across all regions** β€” the server is down. Alert immediately. +- **`ping` failing in one region** β€” usually a network path problem rather than your server. Retries handle most of these, which is what `retry: 3` is for. +- **`401` after a period of `200`s** β€” a rotated or expired token. This is a credentials problem, not an outage. +- **`tools/list` succeeding but missing a tool** β€” a deploy removed or renamed a tool. Nothing is "down", but your agents are already broken. +- **Latency climbing on `tools/list` while `ping` stays flat** β€” the server is under load in its application layer rather than its network layer. + ## What you've accomplished - Configured a JSON-RPC based monitor for your MCP server - Implemented precise assertions to validate `ping` responses +- Handled authenticated endpoints without turning token rotation into a false outage +- Added a `tools/list` check so a missing tool is caught before your agents hit it - Set up global monitoring to detect localised or widespread issues - Automated monitor deployment using a version-controlled YAML configuration +Both monitors run on [openstatus uptime monitoring](/uptime-monitoring) from up to 28 regions, with alerting and history β€” so a broken handshake reaches you before it reaches the agents depending on it. + ## What's next - **[Export metrics to OTLP](/docs/guides/how-to-export-metrics-to-otlp-endpoint)** β€” integrate your MCP monitoring data with your existing observability platform. diff --git a/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx b/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx index 9a2f9a80..6b206ceb 100644 --- a/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx +++ b/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx @@ -1,9 +1,45 @@ --- category: Guides title: Self-Host the openstatus Status Page (Lightweight) -description: Deploy only the openstatus status page and dashboard on your own infrastructure, without monitoring, analytics, or background services. +seo: + title: "Self-Hosted Status Page: Options, Tradeoffs, and Setup" +description: How to self-host a status page - what you actually take on by running it yourself, when hosting it is the wrong call, and a Docker Compose setup that runs the status page without any monitoring infrastructure. +faq: + - question: "Should I self-host my status page?" + answer: "Self-host if you need the status page inside your own network, have compliance rules about where incident data lives, or want to run it at infrastructure cost rather than per-seat pricing. Do not self-host if the page is your primary outage communication channel and it would share infrastructure with the systems it reports on - a status page that goes down with your product is worse than no status page." + - question: "Can I self-host only the status page, without monitoring?" + answer: "Yes. The lightweight Docker Compose stack runs four services - database, one-shot migration runner, dashboard, and status page - and omits automated monitoring, analytics, the API server, and private location probes. It suits teams who already have monitoring elsewhere and manage incidents manually." + - question: "Is self-hosting a status page free?" + answer: "The software is free and open-source under AGPL-3.0, but running it is not. You pay for the host, the storage backing the database, TLS certificates and a domain, plus your own time for upgrades, backups, and keeping the thing online. For a status page specifically, that last item is the real cost, because it has to stay up precisely when the rest of your infrastructure does not." + - question: "Where should I host a self-hosted status page?" + answer: "Somewhere with no shared failure domain with your production systems - a different provider, or at minimum a different region and account. The entire purpose of the page is to be reachable during an outage, so hosting it next to the thing that breaks defeats it." --- +## Should you self-host a status page? + +Worth answering before the Docker section, because self-hosting a status page has a +trap that other self-hosted software does not. + +**Self-host when:** the page has to live inside your own network, compliance rules +constrain where incident data is stored, you want infrastructure cost instead of +per-seat pricing, or you intend to modify it. + +**Do not self-host when:** the status page is your main channel for telling customers +about an outage, and it would run on the infrastructure that outage affects. A status +page that goes down alongside your product is worse than no status page β€” customers +lose the one place that was supposed to answer them. If you self-host anyway, put it +in a different failure domain: another provider, or at minimum a different region and +account. + +**The cost is not the licence.** The software is AGPL-3.0 and free. You pay in host, +storage, TLS, domain, and your own time for upgrades and backups β€” and for this +particular workload, in the obligation to keep it available exactly when everything +else is not. If that trade sounds wrong, the [hosted status page](/status-page) exists +so someone else carries it. + +For a first-hand account of what running it is actually like, a contributor wrote up +[self-hosting openstatus: the hurdles then, the experience now](/blog/self-hosting-openstatus). + ## Problem You want a status page to communicate incidents and maintenance to your users, but you don't need automated monitoring, analytics, or alerting. You may already have your own monitoring tools, or you simply want a lightweight way to manage your public-facing status page. @@ -140,7 +176,35 @@ docker compose -f docker-compose-lightweight.yaml ps **Port conflicts:** If ports 3000, 3001, or 8080 are already in use on your machine, update the host port mappings in `docker-compose-lightweight.yaml`. For example, change `"3000:3000"` to `"4000:3000"` to use port 4000 instead. +## Frequently asked questions + +
+ +Self-host if you need the status page inside your own network, have compliance rules about where incident data lives, or want to run it at infrastructure cost rather than per-seat pricing. Do not self-host if the page is your primary outage communication channel and it would share infrastructure with the systems it reports on β€” a status page that goes down with your product is worse than no status page. + +
+ +
+ +Yes. The lightweight Docker Compose stack runs four services β€” database, one-shot migration runner, dashboard, and status page β€” and omits automated monitoring, analytics, the API server, and private location probes. It suits teams who already have monitoring elsewhere and manage incidents manually. + +
+ +
+ +The software is free and open-source under AGPL-3.0, but running it is not. You pay for the host, the storage backing the database, TLS certificates and a domain, plus your own time for upgrades, backups, and keeping the thing online. For a status page specifically, that last item is the real cost, because it has to stay up precisely when the rest of your infrastructure does not. + +
+ +
+ +Somewhere with no shared failure domain with your production systems β€” a different provider, or at minimum a different region and account. The entire purpose of the page is to be reachable during an outage, so hosting it next to the thing that breaks defeats it. + +
+ ## Next steps - **[Self-host openstatus (full)](/docs/guides/self-hosting-openstatus)** β€” add automated monitoring, analytics, and alerting. +- **[Hosted status page](/status-page)** β€” the same status page without the upgrades, backups, and availability burden. +- **[Self-hosting: the hurdles then, the experience now](/blog/self-hosting-openstatus)** β€” a contributor's account of running it. - **[Join our Discord](https://www.openstatus.dev/discord)** β€” get help from the community. diff --git a/apps/web/src/content/pages/docs/guides/self-hosting-openstatus.mdx b/apps/web/src/content/pages/docs/guides/self-hosting-openstatus.mdx index b2648d11..5d4f940a 100644 --- a/apps/web/src/content/pages/docs/guides/self-hosting-openstatus.mdx +++ b/apps/web/src/content/pages/docs/guides/self-hosting-openstatus.mdx @@ -14,6 +14,8 @@ You want to run openstatus on your own infrastructure instead of using the hoste openstatus provides a Docker Compose setup that makes self-hosting straightforward. This guide walks you through deploying all necessary services and configuring your self-hosted instance. +> **Only want the status page?** If you already have monitoring elsewhere and just need somewhere to publish incidents, the [lightweight status-page-only setup](/docs/guides/self-host-status-page-only) runs four services instead of the full stack β€” no Tinybird, no probes, no API server. + ## Prerequisites - Docker and Docker Compose installed diff --git a/apps/web/src/content/pages/docs/reference/mcp-server.mdx b/apps/web/src/content/pages/docs/reference/mcp-server.mdx index 04d73fac..420448f4 100644 --- a/apps/web/src/content/pages/docs/reference/mcp-server.mdx +++ b/apps/web/src/content/pages/docs/reference/mcp-server.mdx @@ -99,7 +99,7 @@ The MCP client gates every tool call behind your approval β€” the server does no ### Notifying subscribers -Every mutation tool has a **required** `notify: boolean` field β€” there is no default. The tool's input schema rejects calls that omit it, which forces the LLM to make an explicit choice (and therefore ask the user) before firing. +Every publishing tool β€” `create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance` β€” has a **required** `notify: boolean` field, with no default. The tool's input schema rejects calls that omit it, which forces the LLM to make an explicit choice (and therefore ask the user) before firing. `update_status_report` edits metadata only and carries no `notify` field at all. This required-field behaviour is specific to MCP. The dashboard AI assistant and the Slack agent wrap these same tools in an approval step that strips `notify` from the model-facing schema and injects it from a human toggle defaulting to `false`. MCP exposes the raw schema, so the caller must supply `notify` explicitly. diff --git a/apps/web/src/content/pages/guides/api-service-disruption.mdx b/apps/web/src/content/pages/guides/api-service-disruption.mdx index 24a0c0e2..a19bddad 100644 --- a/apps/web/src/content/pages/guides/api-service-disruption.mdx +++ b/apps/web/src/content/pages/guides/api-service-disruption.mdx @@ -83,3 +83,33 @@ Stripe consistently provides context about the source of information and sets cl - Include workaround instructions if available - Link to status dashboard or real-time monitoring - Add contact information for urgent support needs + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +Provide updates every 30-60 minutes during active incidents, even if there's no significant change. Users appreciate knowing you're still working on the issue. Once resolved, a final summary is essential. + +
+ +
+ +Yes, if you can. Being specific helps users understand the scope and that you're transparent about dependencies. Companies like Vercel, Stripe, and GitHub regularly name their providers during incidents. Just remain professional and factual. + +
+ +
+ +Include error rates (e.g., '5% of requests failing'), affected endpoints, and timeframes when you have them. Avoid oversharing internal metrics that might confuse users. Focus on impact-oriented data that helps them assess how they're affected. + +
+ +
+ +Use this template specifically for API-related issues, third-party provider failures, or integration connectivity problems. Use Database Performance for database-specific issues, Deployment Rollback for deployment failures, or Network Connectivity for regional/CDN issues. + +
diff --git a/apps/web/src/content/pages/guides/best-hosted-status-page-2026.mdx b/apps/web/src/content/pages/guides/best-hosted-status-page-2026.mdx index b2cf04b8..ae1c4cdf 100644 --- a/apps/web/src/content/pages/guides/best-hosted-status-page-2026.mdx +++ b/apps/web/src/content/pages/guides/best-hosted-status-page-2026.mdx @@ -133,3 +133,29 @@ Atlassian Statuspage is still defensible if you live in the Atlassian world and ## Need Help or Have Questions? If you need help along the way, feel free to join our [Discord community](https://www.openstatus.dev/discord), check our [documentation](https://www.openstatus.dev/docs) for more information, or reach out to us via [email](mailto:ping@openstatus.dev). + +## Frequently asked questions + +
+ +openstatus is our top pick for 2026. It bundles built-in synthetic monitoring with the status page, ships an MCP server for AI coding agents, supports monitoring-as-code via Terraform, and starts at $30/month with unlimited team members. + +
+ +
+ +Look for built-in monitoring (or easy integration with your existing stack), monitoring-as-code support (a Terraform provider), subscriber channels (email, SMS, webhook, Slack), private-page support, transparent pricing without per-seat surprises, and β€” increasingly β€” an MCP server so coding agents can drive it. + +
+ +
+ +For most teams, yes. Hosted status pages remove the operational burden of running uptime infrastructure (which ironically is the thing you're trying to communicate about). Self-hosting only makes sense when you have strict data residency requirements or already operate the underlying infrastructure at scale. + +
+ +
+ +openstatus and Betterstack are the most cost-effective. openstatus starts at $30/month with monitoring and unlimited seats included, while Betterstack has a usable free tier. Atlassian Statuspage, Instatus, and Status.io get expensive quickly once you need private pages or larger subscriber lists. + +
diff --git a/apps/web/src/content/pages/guides/best-incident-communication-tools-2026.mdx b/apps/web/src/content/pages/guides/best-incident-communication-tools-2026.mdx index e67c6684..1b2dc661 100644 --- a/apps/web/src/content/pages/guides/best-incident-communication-tools-2026.mdx +++ b/apps/web/src/content/pages/guides/best-incident-communication-tools-2026.mdx @@ -129,3 +129,35 @@ For everyone else β€” and that's the majority of teams β€” **openstatus** is the ## Need Help or Have Questions? If you need help along the way, feel free to join our [Discord community](https://www.openstatus.dev/discord), check our [documentation](https://www.openstatus.dev/docs) for more information, or reach out to us via [email](mailto:ping@openstatus.dev). + +## Frequently asked questions + +
+ +Incident communication covers everything from internal coordination (who's working on the problem, what's the current status, where's the war room) to external messaging (status page updates, subscriber notifications, postmortems). A good incident communication tool covers both sides β€” your engineers and your users β€” and ties them together so updates don't drift between channels. + +
+ +
+ +Incident management platforms like incident.io and Rootly are Slack-first tools focused on internal coordination: creating war rooms, assigning roles, tracking timelines, and automating workflows. Status pages like openstatus, Atlassian Statuspage, and Instatus are externally-facing communication tools for your users. openstatus bridges both with a status page, a Slack agent for internal coordination, and built-in monitoring. + +
+ +
+ +openstatus is typically the best choice for small teams. It includes a status page, monitoring, a Slack agent, and unlimited team members at $30/month. incident.io and Rootly are per-seat priced and aimed at larger orgs. Atlassian Statuspage and Instatus cover the external side only and require a separate tool for internal coordination. + +
+ +
+ +Yes, and many teams do. A common stack is incident.io or Rootly for internal coordination, plus Atlassian Statuspage or openstatus for external communication. The downside is two products, two bills, and updates that can drift between them. Tools that cover both sides β€” like openstatus β€” reduce that overhead. + +
+ +
+ +Only openstatus includes built-in synthetic monitoring. incident.io, Rootly, Atlassian Statuspage, and Instatus all expect you to bring monitoring from another tool (Datadog, New Relic, Pingdom, etc.) and ingest the alerts. + +
diff --git a/apps/web/src/content/pages/guides/best-opensource-status-page-2026.mdx b/apps/web/src/content/pages/guides/best-opensource-status-page-2026.mdx index e2c8cb28..716c4c1a 100644 --- a/apps/web/src/content/pages/guides/best-opensource-status-page-2026.mdx +++ b/apps/web/src/content/pages/guides/best-opensource-status-page-2026.mdx @@ -95,3 +95,29 @@ Unfortunately, as of 2026, the project seems to have stalled. With its last majo ### The Verdict If you are starting a new project or migrating an old status page today, **openstatus** is the clear winner. Its modern architecture, active maintenance, and built-in integrations make it the easiest way to keep your users informed while your engineering team focuses on fixing the actual outages. + +## Frequently asked questions + +
+ +openstatus is the top pick for 2026. It is actively maintained, offers both cloud-hosted and self-hosted deployments, includes built-in uptime monitoring, and integrates with Slack out of the box. + +
+ +
+ +Focus on active maintenance, deployment flexibility (hosted vs. self-hosted), built-in monitoring, notification integrations (Slack, email, webhooks), and how easy it is for your end users to understand the current status at a glance. + +
+ +
+ +Yes. Tools like openstatus, Vigil, Cachet, and Statping-ng can all be self-hosted at no licensing cost. Keep in mind you will still need to provision and maintain your own infrastructure, so factor in server and operational costs. + +
+ +
+ +Upptime pioneered a clever GitOps approach using GitHub Actions and Pages, but its last major release was in 2020. Because it is no longer actively maintained, we recommend choosing an actively developed alternative like OpenStatus for production use. + +
diff --git a/apps/web/src/content/pages/guides/boring-is-better-for-status-pages.mdx b/apps/web/src/content/pages/guides/boring-is-better-for-status-pages.mdx index 4ef597c2..a38f71cf 100644 --- a/apps/web/src/content/pages/guides/boring-is-better-for-status-pages.mdx +++ b/apps/web/src/content/pages/guides/boring-is-better-for-status-pages.mdx @@ -89,6 +89,38 @@ That's not settling for less. That's understanding what matters. Migrating from your current status page? [Contact us](mailto:ping@openstatus.dev), we'll help you move over. +## Frequently asked questions + +
+ +JavaScript frameworks add load, parse, and execution time before rendering meaningful content. During an incident when users' connectivity might be degraded, this delay destroys trust. Static HTML renders instantly and works even when JavaScript fails, which is exactly what you need during a crisis. + +
+ +
+ +Animated status indicators that require JavaScript to show if you're down create a critical failure mode - if the script fails, the page shows nothing, which is indistinguishable from being completely offline. Status information should be visible immediately in plain HTML. + +
+ +
+ +No. During an incident, different users seeing different versions of your status page creates confusion and erodes trust. When customers compare notes and realize they're seeing conflicting information, you've turned an operational problem into a credibility crisis. + +
+ +
+ +External dependencies like graphing services or CDNs create additional failure modes. When those services fail - and they will - your status page loses functionality at the exact moment it matters most. Plain HTML and CSS have decades of battle-testing with no unexpected edge cases. + +
+ +
+ +A good status page works in grayscale for colorblind users, supports keyboard navigation and screen readers, loads instantly, provides RSS/Atom feeds for automated monitoring, and displays text-based updates that remain readable even if CSS fails. Accessibility isn't optional during high-stress moments. + +
+ --- Start free. No credit card required. Set up your first status page in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/connect-openstatus-to-claude-code.mdx b/apps/web/src/content/pages/guides/connect-openstatus-to-claude-code.mdx index 6a6a1c35..5ad837c2 100644 --- a/apps/web/src/content/pages/guides/connect-openstatus-to-claude-code.mdx +++ b/apps/web/src/content/pages/guides/connect-openstatus-to-claude-code.mdx @@ -27,9 +27,9 @@ faq: - question: "Do I need a separate MCP credential for Claude Code?" answer: "No. Authentication is the standard `x-openstatus-key` header β€” the same API key the openstatus CLI, REST API, and Terraform provider use. There is no MCP-specific OAuth flow." - question: "Can Claude Code accidentally notify subscribers when creating an incident?" - answer: "No. Every mutation tool requires an explicit `notify: true | false` field. Claude Code must show the notify choice before firing the tool, so an LLM cannot quietly fan out an alert by omitting the flag." + answer: "No. Every publishing tool (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`) requires an explicit `notify: true | false` field. Claude Code must show the notify choice before firing the tool, so an LLM cannot quietly fan out an alert by omitting the flag. `update_status_report` is metadata-only and has no notify path at all." - question: "How do I give Claude Code read-only access to my workspace?" - answer: "Create an API key with `read` scope. The MCP server filters mutation tools out of the `tools/list` response for read-only keys, so Claude Code only sees `list_status_pages`, `list_status_reports`, and `list_maintenances`." + answer: "Create an API key with `read` scope. The MCP server filters write tools out of the `tools/list` response for read-only keys, so Claude Code sees only the 14 read tools β€” status pages and page components, status reports, maintenances, monitors, response logs, notifications, private locations, and audit logs. None of the `create_*`, `update_*`, or `resolve_*` tools are registered for that session." - question: "Where do MCP-driven changes appear in the audit log?" answer: "Every mutation routed through the MCP server lands in the audit log under `actor_type = 'mcp'`, with `actor_id` set to the API key id and `actor_user_id` set to the user who created the key. This separates AI-driven actions from CLI, dashboard, and direct API mutations." - question: "Can I commit the MCP configuration to my repository?" @@ -150,6 +150,50 @@ Three properties make this safe enough for a real incident: - **[Openstatus CLI](/tooling/cli)** β€” for terminal workflows that don't need an LLM in the loop. - **[Slack Agent](/status-page#slack-agent)** β€” for teams that live in Slack. +## Frequently asked questions + +
+ +Yes. Claude Code supports stdio, HTTP, and SSE transports. The openstatus MCP server is a stateless Streamable HTTP endpoint, registered with `claude mcp add --transport http`. + +
+ +
+ +Claude Code can list status pages, status reports, and maintenance windows; create new status reports; append updates to existing reports; resolve reports; edit metadata; and schedule maintenance windows β€” all scoped to the workspace tied to your API key. + +
+ +
+ +No. Authentication is the standard `x-openstatus-key` header β€” the same API key the openstatus CLI, REST API, and Terraform provider use. There is no MCP-specific OAuth flow. + +
+ +
+ +No. Every publishing tool (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`) requires an explicit `notify: true | false` field. Claude Code must show the notify choice before firing the tool, so an LLM cannot quietly fan out an alert by omitting the flag. `update_status_report` is metadata-only and has no notify path at all. + +
+ +
+ +Create an API key with `read` scope. The MCP server filters write tools out of the `tools/list` response for read-only keys, so Claude Code sees only the 14 read tools β€” status pages and page components, status reports, maintenances, monitors, response logs, notifications, private locations, and audit logs. None of the `create_*`, `update_*`, or `resolve_*` tools are registered for that session. + +
+ +
+ +Every mutation routed through the MCP server lands in the audit log under `actor_type = 'mcp'`, with `actor_id` set to the API key id and `actor_user_id` set to the user who created the key. This separates AI-driven actions from CLI, dashboard, and direct API mutations. + +
+ +
+ +Yes. Create a project-scoped `.mcp.json` at the repo root with the MCP server definition, and use `${OPENSTATUS_API_KEY}` for the header value so the secret stays out of source control. + +
+ --- Start free. No credit card required. Configure Claude Code to drive your status pages in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/connect-openstatus-to-claude-desktop.mdx b/apps/web/src/content/pages/guides/connect-openstatus-to-claude-desktop.mdx index f7d2c5af..a1b5dc0d 100644 --- a/apps/web/src/content/pages/guides/connect-openstatus-to-claude-desktop.mdx +++ b/apps/web/src/content/pages/guides/connect-openstatus-to-claude-desktop.mdx @@ -29,9 +29,9 @@ faq: - question: "Why don't I see the openstatus tools after editing the config?" answer: "The two most common causes are not fully quitting Claude Desktop (it only loads MCP servers at launch β€” close the window is not enough, you have to Cmd+Q on macOS or File β†’ Quit on Windows) and `npx` not being on the PATH that Claude Desktop sees. Install Node.js 18+ from nodejs.org if `node --version` is missing in your shell." - question: "Can Claude Desktop accidentally notify subscribers when posting an incident?" - answer: "No. Every mutation tool requires an explicit `notify: true | false` field. Claude must show the notify choice before firing the tool, so an LLM cannot quietly fan out an alert by omitting the flag." + answer: "No. Every publishing tool (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`) requires an explicit `notify: true | false` field. Claude must show the notify choice before firing the tool, so an LLM cannot quietly fan out an alert by omitting the flag. `update_status_report` is metadata-only and has no notify path at all." - question: "How do I give Claude Desktop read-only access to my workspace?" - answer: "Create an API key with `read` scope. The MCP server filters mutation tools out of the `tools/list` response for read-only keys, so Claude Desktop only sees `list_status_pages`, `list_status_reports`, and `list_maintenances`." + answer: "Create an API key with `read` scope. The MCP server filters write tools out of the `tools/list` response for read-only keys, so Claude Desktop sees only the 14 read tools β€” status pages and page components, status reports, maintenances, monitors, response logs, notifications, private locations, and audit logs. None of the `create_*`, `update_*`, or `resolve_*` tools are registered for that session." - question: "Where do MCP-driven changes appear in the audit log?" answer: "Every mutation routed through Claude Desktop lands in the audit log under `actor_type = 'mcp'`, with `actor_id` set to the API key id and `actor_user_id` set to the user who created the key. This separates AI-driven actions from CLI, dashboard, and direct API mutations." --- @@ -142,6 +142,50 @@ Three properties make this safe enough for a real incident: - **[Openstatus CLI](/tooling/cli)** β€” for terminal workflows that don't need an LLM in the loop. - **[Slack Agent](/status-page#slack-agent)** β€” for teams that live in Slack. +## Frequently asked questions + +
+ +Yes, but indirectly. Claude Desktop launches MCP servers as local stdio processes, so a remote HTTP server like openstatus has to be bridged through `npx mcp-remote` β€” a small open-source proxy that translates Claude Desktop's stdio calls into HTTP requests. You configure `mcp-remote` once in `claude_desktop_config.json` and Claude Desktop treats openstatus like any other local server. + +
+ +
+ +On macOS, the file lives at `~/Library/Application Support/Claude/claude_desktop_config.json`. On Windows, it lives at `%APPDATA%\Claude\claude_desktop_config.json`. Create the file if it does not exist. + +
+ +
+ +No. Authentication is the standard `x-openstatus-key` header β€” the same API key the openstatus CLI, REST API, and Terraform provider use. There is no MCP-specific OAuth flow. + +
+ +
+ +The two most common causes are not fully quitting Claude Desktop (it only loads MCP servers at launch β€” close the window is not enough, you have to Cmd+Q on macOS or File β†’ Quit on Windows) and `npx` not being on the PATH that Claude Desktop sees. Install Node.js 18+ from nodejs.org if `node --version` is missing in your shell. + +
+ +
+ +No. Every publishing tool (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`) requires an explicit `notify: true | false` field. Claude must show the notify choice before firing the tool, so an LLM cannot quietly fan out an alert by omitting the flag. `update_status_report` is metadata-only and has no notify path at all. + +
+ +
+ +Create an API key with `read` scope. The MCP server filters write tools out of the `tools/list` response for read-only keys, so Claude Desktop sees only the 14 read tools β€” status pages and page components, status reports, maintenances, monitors, response logs, notifications, private locations, and audit logs. None of the `create_*`, `update_*`, or `resolve_*` tools are registered for that session. + +
+ +
+ +Every mutation routed through Claude Desktop lands in the audit log under `actor_type = 'mcp'`, with `actor_id` set to the API key id and `actor_user_id` set to the user who created the key. This separates AI-driven actions from CLI, dashboard, and direct API mutations. + +
+ --- Start free. No credit card required. Configure Claude Desktop to drive your status pages in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/database-performance-degradation.mdx b/apps/web/src/content/pages/guides/database-performance-degradation.mdx index d1d95686..b7f72bad 100644 --- a/apps/web/src/content/pages/guides/database-performance-degradation.mdx +++ b/apps/web/src/content/pages/guides/database-performance-degradation.mdx @@ -106,3 +106,27 @@ Watch for these indicators that might trigger using this template: - Connection timeouts - User reports of slowness - Database monitoring alerts + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +Match your communication to your audience. For developer-focused products, include technical details like p95 latency, query times, and specific database components. For general users, focus on impact: 'slower response times' instead of 'elevated connection pool exhaustion.' + +
+ +
+ +Yes, once resolved. Technical audiences appreciate transparency and can learn from your incidents. Share root cause, mitigation steps taken, and preventative measures. This builds trust and demonstrates engineering maturity. + +
+ +
+ +Trigger notifications when p95 latency exceeds 2x normal, error rates exceed 1%, connection timeouts occur, or when user reports indicate widespread slowness. Set up automated monitoring alerts to catch these thresholds early. + +
diff --git a/apps/web/src/content/pages/guides/deployment-rollback.mdx b/apps/web/src/content/pages/guides/deployment-rollback.mdx index 77ce868a..2259bc03 100644 --- a/apps/web/src/content/pages/guides/deployment-rollback.mdx +++ b/apps/web/src/content/pages/guides/deployment-rollback.mdx @@ -159,3 +159,33 @@ After resolution, consider adding context about prevention: - Use **API Service Disruption** if rollback affects external integrations - Use **Database Performance** if rollback impacts database operations - Use **Security Incident** if deployment exposed security issues + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +If error rates exceed 5% or critical functionality is broken, initiate rollback immediately. Don't wait to debug in production. Roll back first, then investigate the issue in a safe environment. Time is critical - every minute of impact affects user trust. + +
+ +
+ +Communicate the rollback decision immediately, then provide updates during the process. Users appreciate knowing you're taking action. Example: 'We've initiated a rollback and expect completion in 10 minutes' is better than waiting until it's done. + +
+ +
+ +This suggests the problem isn't with the recent deployment. Pivot your communication to general incident response, investigate the root cause, and consider whether you need to roll back further or take other remediation steps. Update users with revised information. + +
+ +
+ +Yes. Even quick rollbacks deserve analysis. Document what went wrong, why it wasn't caught in testing, and what process changes will prevent recurrence. Share key findings with users if appropriate to show continuous improvement. + +
diff --git a/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx b/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx index 5d9eb298..2a6e7b75 100644 --- a/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx +++ b/apps/web/src/content/pages/guides/dora-incident-reporting-requirements.mdx @@ -140,6 +140,38 @@ Financial services regulation carries supervisory consequences that a guide cann - [What is MTTR](/guides/what-is-mttr) β€” duration and downtime feed the classification criteria - [Status pages for crypto exchanges and DeFi protocols](/use-case/crypto) β€” if you are a CASP or token issuer +## Frequently asked questions + +
+ +Three stages. An initial notification no later than 4 hours after classifying an incident as major, and in any case no later than 24 hours from becoming aware of it. An intermediate report within 72 hours of the initial notification, submitted even if there is no change in status. A final report no later than one month after the most recent intermediate report. The detail sits in Commission Delegated Regulation 2025/301, with reporting templates in Implementing Regulation 2025/302. + +
+ +
+ +Yes, where client interests are affected. Article 19(3) requires financial entities to inform clients without undue delay when a major ICT-related incident has an impact on their financial interests, including the measures taken to mitigate adverse effects. Article 14 separately requires crisis communication plans providing for responsible disclosure of major incidents to clients, counterparts, and the public. + +
+ +
+ +At classification, not at detection. You have up to 24 hours from becoming aware of an incident, and once you classify it as major you have 4 hours from that moment β€” whichever comes first binds. This makes your classification decision and its timestamp a regulated artifact, and it means a slow classification does not buy you time. + +
+ +
+ +Financial entities across the EU β€” credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and intermediaries, trading venues, central counterparties, fund managers, and more β€” plus ICT third-party service providers designated as critical. If you sell software to financial entities, DORA reaches you contractually through Chapter V rather than directly. + +
+ +
+ +It can serve the Article 19(3) client information duty and support the Article 14 communication plan. It cannot serve the regulator reports β€” those go to your competent authority on prescribed templates through a designated channel. The two are different audiences with different content and different clocks. + +
+ --- Start your status page diff --git a/apps/web/src/content/pages/guides/error-budgets-explained.mdx b/apps/web/src/content/pages/guides/error-budgets-explained.mdx new file mode 100644 index 00000000..44b09494 --- /dev/null +++ b/apps/web/src/content/pages/guides/error-budgets-explained.mdx @@ -0,0 +1,181 @@ +--- +title: "Error Budgets Explained" +seo: + title: "Error Budget: How to Calculate and Use One" +description: "How to calculate an error budget from your SLO, what burn rate means, and what to actually do when the budget runs out. With a per-SLO downtime table." +author: "openstatus" +publishedAt: "2026-08-15" +category: "fundamentals" +faq: + - question: "What is an error budget?" + answer: "An error budget is the amount of unreliability you are allowed before you break your own target. If your SLO is 99.9% availability over a month, you are permitting 0.1% of that month to fail - about 43 minutes. That 43 minutes is the budget. It is not a forecast or a tolerance for sloppiness; it is a quantity you are expected to spend." + - question: "How do you calculate an error budget?" + answer: "Error budget = (100% βˆ’ SLO) Γ— the measurement window. For a 99.9% monthly SLO, that is 0.1% of 30 days, or roughly 43 minutes. For a 99.99% monthly SLO it is about 4 minutes 19 seconds. Calculate it against the window your agreement actually uses - a yearly window is ten times more forgiving than a monthly one for the same percentage." + - question: "What is error budget burn rate?" + answer: "Burn rate is how fast you are consuming the budget relative to the pace that would exactly exhaust it over the window. A burn rate of 1 means you will finish the period with exactly zero budget left. A burn rate of 14.4 means you are spending 2% of a 30-day budget every hour, and the entire month's allowance disappears in about two days." + - question: "What happens when the error budget is spent?" + answer: "That is a policy decision you should make before it happens, not during the incident. The common policy is to freeze feature deploys and redirect engineering to reliability work until the budget recovers at the start of the next window. The point is that the budget converts an argument about whether to slow down into a number that already decided it." + - question: "What is the difference between an error budget and an SLA?" + answer: "An SLA is the promise you make to customers, with financial consequences. The error budget is the operating room between that promise and the stricter internal target you hold yourself to. The SLA says what happens if you fail; the error budget tells you how close you are to failing, while there is still time to act." +--- + +An error budget is the most useful number in reliability work, and the one most teams +define once and then never look at again. It turns "should we ship this risky change +on a Friday?" from an argument about temperament into a question with an answer. + +This guide assumes you already know how SLIs, SLOs, and SLAs relate. If not, start +with [SLA vs SLO vs SLI](/guides/sla-vs-slo-vs-sli) β€” the error budget only makes +sense once those three are distinct in your head. + +## What an Error Budget Actually Is + +Your SLO is a target for reliability. The error budget is its complement: the +unreliability you have explicitly permitted. + +If your SLO is 99.9% availability measured monthly, you are saying 0.1% of the month +is allowed to fail. That is roughly 43 minutes. Those 43 minutes are not a tolerance +for carelessness β€” they are a resource you are expected to spend, on deploys, +migrations, experiments, and the incidents that follow from them. + +A team that ends every month with a full budget is not winning. It is shipping too +slowly. + +## How to Calculate It + +The formula is one line: + +``` +Error budget = (100% βˆ’ SLO) Γ— measurement window +``` + +The window matters as much as the percentage. Here is the same set of targets +measured over 30 days and over a year: + +| SLO | Budget per 30-day month | Budget per year | +| --- | --- | --- | +| 99% | 7h 12m | 3d 15h 36m | +| 99.5% | 3h 36m | 1d 19h 48m | +| 99.9% | 43m 12s | 8h 45m 36s | +| 99.95% | 21m 36s | 4h 22m 48s | +| 99.99% | 4m 19s | 52m 34s | +| 99.999% | 26s | 5m 15s | + +Two things fall out of that table. First, each additional nine cuts your room to +manoeuvre by 10Γ— β€” 99.99% is not "slightly better than" 99.9%, it is a different +operating model requiring redundancy and automated failover. Second, a yearly window +is enormously more forgiving than a monthly one. A four-hour outage is a rounding +error against a 99.9% annual budget and a catastrophic overrun against the monthly +one. Agree on the window before you agree on the number. + +You can work the same arithmetic for any target with the [SLA calculator](/play/uptime-sla). + +## Burn Rate: the Part That Makes It Operational + +A budget you check monthly is a postmortem tool. Burn rate is what makes it a +warning system. + +Burn rate measures how fast you are consuming the budget relative to the pace that +would exactly exhaust it over the window. A burn rate of 1 means you will end the +period with precisely nothing left. A burn rate of 2 means you will run out halfway +through. + +This is what you alert on, because it catches a problem while the budget still has +something in it: + +| Burn rate | Budget consumed | Over | Meaning | +| --- | --- | --- | --- | +| 14.4Γ— | 2% | 1 hour | The month's budget is gone in ~2 days. Wake someone up. | +| 6Γ— | 5% | 6 hours | Serious, sustained degradation. Page during working hours. | +| 1Γ— | 10% | 3 days | Slow bleed. File a ticket, not an alert. | + +The fast burn rates catch outages. The slow ones catch the more insidious failure β€” +a small regression that never trips a threshold but quietly eats the month. + +## What to Do When It Runs Out + +Decide this in advance, in writing, while nobody is stressed. A budget with no +policy attached is just a metric. + +The conventional policy is a **feature freeze**: when the budget is exhausted, +non-essential deploys stop and engineering effort redirects to reliability until the +window resets. Variations that work: + +- **Graduated response.** At 50% consumed, review what spent it. At 75%, require + sign-off for risky changes. At 100%, freeze. +- **Freeze the risky surface only.** Halt deploys to the service that missed its + SLO rather than the whole organisation. +- **Borrow deliberately.** Sometimes a launch is worth overrunning for. That should + be an explicit, recorded decision by someone accountable β€” not something that + happens because nobody was watching. + +The value is not the freeze. It is that the decision was made when everyone was +calm, so the conversation during the incident is about facts rather than about who +is most senior in the room. + +## Common Mistakes + +**Setting the SLO equal to the SLA.** Then the budget is zero and the first bad +deploy is a contractual breach. The internal target must be stricter than the public +promise β€” that gap *is* the budget. + +**Measuring the budget against a window nobody agreed on.** Monthly and yearly +windows differ by more than 10Γ— in practice. Pick one and use it everywhere. + +**Counting only hard downtime.** If your SLI is availability but users experience a +service that responds in eight seconds, the budget says you are fine while customers +churn. Include latency in the SLI β€” and be precise about which measurement you mean, +since [latency and response time](/docs/concept/latency-vs-response-time) are not +the same number β€” or accept that the budget only describes part of the experience. +See also [why uptime percentage alone is misleading](/guides/why-uptime-percentage-is-misleading). + +**Treating leftover budget as a scoreboard.** An unspent budget is unshipped work. + +## How openstatus Fits In + +An error budget is arithmetic on top of an SLI, so it is only as good as the +measurement underneath it. openstatus does not compute the budget for you β€” it +measures the number you compute it from. + +[Uptime monitoring](/uptime-monitoring) runs checks from up to 28 regions and keeps +the history, which matters for two reasons. Regional failures are invisible to a +single-probe check, and a budget calculated from one vantage point will understate +what your users actually experienced. And a budget needs a continuous record over +the whole window β€” you cannot reconstruct last month's consumption from a dashboard +that only shows the present. + +From there the budget is a subtraction: allowed downtime for your target, minus what +the history says you actually spent. Publishing the result on a +[status page](/status-page) is what turns it from an internal number into the +evidence behind your SLA. + +## Frequently asked questions + +
+ +An error budget is the amount of unreliability you are allowed before you break your own target. If your SLO is 99.9% availability over a month, you are permitting 0.1% of that month to fail β€” about 43 minutes. That 43 minutes is the budget. It is not a forecast or a tolerance for sloppiness; it is a quantity you are expected to spend. + +
+ +
+ +Error budget = (100% βˆ’ SLO) Γ— the measurement window. For a 99.9% monthly SLO, that is 0.1% of 30 days, or roughly 43 minutes. For a 99.99% monthly SLO it is about 4 minutes 19 seconds. Calculate it against the window your agreement actually uses β€” a yearly window is ten times more forgiving than a monthly one for the same percentage. + +
+ +
+ +Burn rate is how fast you are consuming the budget relative to the pace that would exactly exhaust it over the window. A burn rate of 1 means you will finish the period with exactly zero budget left. A burn rate of 14.4 means you are spending 2% of a 30-day budget every hour, and the entire month's allowance disappears in about two days. + +
+ +
+ +That is a policy decision you should make before it happens, not during the incident. The common policy is to freeze feature deploys and redirect engineering to reliability work until the budget recovers at the start of the next window. The point is that the budget converts an argument about whether to slow down into a number that already decided it. + +
+ +
+ +An SLA is the promise you make to customers, with financial consequences. The error budget is the operating room between that promise and the stricter internal target you hold yourself to. The SLA says what happens if you fail; the error budget tells you how close you are to failing, while there is still time to act. + +
diff --git a/apps/web/src/content/pages/guides/feature-degradation.mdx b/apps/web/src/content/pages/guides/feature-degradation.mdx index df2c58b0..7a0c1027 100644 --- a/apps/web/src/content/pages/guides/feature-degradation.mdx +++ b/apps/web/src/content/pages/guides/feature-degradation.mdx @@ -12,7 +12,7 @@ faq: - question: "How do I communicate partial degradation percentages to users?" answer: "Be specific: '50% success rate - retry usually works' or '10% error rate - most requests succeeding.' Avoid vague terms like 'some' or 'many.' Percentages help users assess their likelihood of being affected and whether retrying makes sense." - question: "What if I don't know which feature is causing issues?" - answer: "Start with what you know: 'We're investigating reports of errors. Some users may be affected.' Then update as you learn more: 'We've confirmed the issue is with [specific feature].' Narrow the scope as quickly as possible to reduce user uncertainty." + answer: "Start with the symptom you can confirm, not a hedge: 'We're investigating elevated error rates on checkout. Next update in 30 minutes.' State what you have actually observed and when you will report again, then narrow it as you learn more: 'We've confirmed the issue is with [specific feature].' Avoid 'some users may be affected' β€” it commits to nothing and reads as evasion." --- Use this template when specific features are degraded or unavailable, but the core service remains operational. Helps users understand what's working and what isn't. @@ -364,3 +364,33 @@ Thank you for your patience while we resolved this issue. - Use **Database Performance** if degradation is caused by database issues - Use **Network Connectivity** if some regions can't access the feature - Use **Deployment Rollback** if a recent deployment caused the degradation + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +Use degraded when the feature still works partially (e.g., 50% success rate, slower than normal, or intermittent failures). Use outage when the feature is completely unavailable (100% failure rate). Clear distinction helps users set expectations. + +
+ +
+ +For major features, list both. Users need to know what still works so they can continue their workflow. For minor features, focus on what's broken and state 'all other features operating normally.' The feature impact matrix format works well for complex degradations. + +
+ +
+ +Be specific: '50% success rate - retry usually works' or '10% error rate - most requests succeeding.' Avoid vague terms like 'some' or 'many.' Percentages help users assess their likelihood of being affected and whether retrying makes sense. + +
+ +
+ +Start with the symptom you can confirm, not a hedge: 'We're investigating elevated error rates on checkout. Next update in 30 minutes.' State what you have actually observed and when you will report again, then narrow it as you learn more: 'We've confirmed the issue is with [specific feature].' Avoid 'some users may be affected' β€” it commits to nothing and reads as evasion. + +
diff --git a/apps/web/src/content/pages/guides/hosted-uptime-kuma-alternative.mdx b/apps/web/src/content/pages/guides/hosted-uptime-kuma-alternative.mdx index edbf290a..987fae49 100644 --- a/apps/web/src/content/pages/guides/hosted-uptime-kuma-alternative.mdx +++ b/apps/web/src/content/pages/guides/hosted-uptime-kuma-alternative.mdx @@ -77,6 +77,32 @@ Most Kuma setups are small enough to move in well under an hour. - [What Is Uptime Monitoring?](/guides/what-is-uptime-monitoring) - [Status Pages for Open-Source Projects](/use-case/open-source) +## Frequently asked questions + +
+ +Not literally β€” they're separate projects β€” but openstatus fills the same need without the self-hosting. Both are open-source uptime monitors with status pages. The key difference: Uptime Kuma runs on a single server you maintain, while openstatus is a managed, multi-region service. You can still self-host openstatus if you want full control. + +
+ +
+ +Uptime Kuma checks from a single location β€” the server you run it on. If that server has a network blip, you get false alerts; if it goes down, your monitoring goes down with it. It also can't tell you whether an outage is regional, because there's only one vantage point. A managed, multi-region tool solves both. + +
+ +
+ +Yes. Some teams run Uptime Kuma internally for homelab or internal services and use openstatus for external, multi-region checks and a public status page. They complement each other. + +
+ +
+ +Uptime Kuma is free to run if you cover your own hosting. openstatus has a permanent free plan for the managed service (1 monitor, 6 regions), paid plans from $30/month, and is also free to self-host under AGPL-3.0. + +
+ --- Open-source monitoring, without the VPS to babysit diff --git a/apps/web/src/content/pages/guides/how-openstatus-compares-to-other-status-page-tools.mdx b/apps/web/src/content/pages/guides/how-openstatus-compares-to-other-status-page-tools.mdx index 63dd67b9..a27171ad 100644 --- a/apps/web/src/content/pages/guides/how-openstatus-compares-to-other-status-page-tools.mdx +++ b/apps/web/src/content/pages/guides/how-openstatus-compares-to-other-status-page-tools.mdx @@ -190,3 +190,35 @@ For Betterstack, Datadog, and Status.io, migration is typically a manual rebuild ## Need Help or Have Questions? If you need help along the way, feel free to join our [Discord community](https://www.openstatus.dev/discord), check our [documentation](https://www.openstatus.dev/docs) for more information, or reach out to us via [email](mailto:ping@openstatus.dev). + +## Frequently asked questions + +
+ +openstatus is the only tool that combines built-in synthetic monitoring, monitoring-as-code via Terraform, native OpenTelemetry export, private locations, an MCP server for AI coding agents, unlimited team members, and the option to self-host as open-source. Most competitors cover one or two of these β€” none cover all of them. + +
+ +
+ +Yes, for most use cases. openstatus covers the core incident communication workflows (components, incidents, maintenances, subscribers) and adds built-in monitoring, monitoring-as-code, and an MCP server that Atlassian Statuspage doesn't ship. The one area where Atlassian still leads is deep Jira/Opsgenie integration for teams already standardized on Atlassian tooling. + +
+ +
+ +openstatus starts at $30/month with unlimited team members and monitoring included. That's typically cheaper than Atlassian Statuspage ($99/month for private pages), Status.io ($349/month for advanced features), or Betterstack once you add private-page and styling add-ons. Instatus has a comparable free tier but no monitoring. + +
+ +
+ +Yes. openstatus ships a one-click importer for Atlassian Statuspage and Instatus that moves components, component groups, incidents with full update history, maintenances, and email subscribers. For other tools, components and subscribers can be imported via CSV. + +
+ +
+ +Yes. openstatus powers status pages for teams across SaaS, fintech, and infrastructure companies, and runs synthetic checks from multiple regions globally. The hosted platform is fully managed, and the same codebase backs the self-hosted distribution. + +
diff --git a/apps/web/src/content/pages/guides/http-headers.mdx b/apps/web/src/content/pages/guides/http-headers.mdx index f1ed1d51..df5e654b 100644 --- a/apps/web/src/content/pages/guides/http-headers.mdx +++ b/apps/web/src/content/pages/guides/http-headers.mdx @@ -193,6 +193,32 @@ Response headers reveal more than status codes alone: - Missing `Strict-Transport-Security` on production is worth alerting on - `Cache-Control: no-store` on a high-traffic route means zero caching is helping you +## Frequently asked questions + +
+ +HTTP headers are metadata key-value pairs sent alongside HTTP requests and responses. They define content types, authentication, caching behavior, security policies, and more. + +
+ +
+ +Cache-Control is an HTTP response header that tells browsers and CDNs how long to cache a response. Directives like max-age, no-cache, and no-store control caching behavior. + +
+ +
+ +X-Forwarded-For contains a chain of IPs added by each proxy. X-Real-IP is set by the first proxy and reflects just the original client IP. + +
+ +
+ +CF-Ray is a Cloudflare-specific header that uniquely identifies a request. It's the first thing Cloudflare support will ask for when debugging an issue. + +
+ --- Start monitoring your API responses diff --git a/apps/web/src/content/pages/guides/incident-communication.mdx b/apps/web/src/content/pages/guides/incident-communication.mdx new file mode 100644 index 00000000..f1d67787 --- /dev/null +++ b/apps/web/src/content/pages/guides/incident-communication.mdx @@ -0,0 +1,184 @@ +--- +title: "Incident Communication" +seo: + title: "Incident Communication: Templates, Cadence, and What to Say" +description: "What to write during an outage, at which severity, and how often. The four update stages, a cadence table by severity, copy-paste templates by scenario, and the phrases that make incidents worse." +author: "openstatus" +publishedAt: "2026-08-15" +category: "education" +faq: + - question: "What should you say in an incident update?" + answer: "What is broken in user terms, who it affects, what you are doing, and when you will next post. Never speculate on cause in the first update - you will be wrong, and the correction costs more trust than the delay would have. If you know nothing yet, say that you are investigating and give a next-update time. 'We are investigating reports of elevated error rates on the API. Next update in 30 minutes' is a complete first update." + - question: "How often should you post incident updates?" + answer: "Match cadence to severity: every 30 minutes for a full outage, every hour for major degradation, and at meaningful change only for minor issues. Post on schedule even when there is nothing new - silence reads as abandonment, and 'still investigating, next update in 30 minutes' is a real update. Missing a promised update does more damage than the outage itself in most cases." + - question: "Should you admit fault in an incident update?" + answer: "Say what happened plainly, without either minimising it or performing contrition. 'A configuration change caused 40 minutes of failed logins' is better than both 'some users may have experienced intermittent issues' and a paragraph of apology. Customers are deciding whether to trust your future updates, and precision is what earns that." + - question: "What is the difference between an incident update and a postmortem?" + answer: "An update is written during the incident for people who are currently blocked - short, factual, and focused on impact and next update time. A postmortem is written afterwards for people deciding whether to keep trusting you - it covers timeline, root cause, and what changes so it does not recur. Updates buy patience; postmortems buy trust back." + - question: "Who should write incident updates?" + answer: "Someone who is not fixing the incident. The responder deep in the problem is the worst-placed person to write clearly about it, and asking them to context-switch slows recovery. Assign a communications role at the start of any SEV1 or SEV0 - usually the incident commander or a support lead working from what responders report." +--- + +Most teams treat incident communication as something that happens to them. The +outage starts, someone asks "should we post something?", and a paragraph gets +written by whoever is least busy β€” usually the person who should be fixing it. + +It is worth doing better, because the communication is what customers actually +experience. They do not see your remediation. They see whether you told them, how +fast, and whether the update was honest. A well-run incident with silent comms reads +as incompetence; a bad incident with clear comms often ends with customers thanking +you. + +This is the hub for how to do it: the update stages, cadence by severity, templates +per scenario, and the phrases to avoid. + +## The Four Stages of an Incident Update + +Nearly every status page convention β€” and every template on this site β€” uses the same +four stages. They exist because they answer different questions. + +| Stage | The question it answers | What goes in it | +| --- | --- | --- | +| **Investigating** | Do you know? | Confirm the symptom in user terms and commit to a next update time. No cause, no ETA. | +| **Identified** | Do you know why? | What is broken and who it affects. A fix is underway. Still no promised ETA unless you are certain. | +| **Monitoring** | Is it fixed? | The fix is deployed and you are watching. Say what recovery looks like so users can verify. | +| **Resolved** | Is it over? | Confirm normal service, state duration and scope, and say whether a postmortem follows. | + +The stage most teams get wrong is **Investigating**. It feels empty to post "we are +looking into it" β€” so they wait until they have something substantial, and by then +customers have been guessing for forty minutes. The first update is not there to +inform. It is there to tell people they do not need to open a support ticket. + +The other common error is skipping **Monitoring** and jumping to Resolved. If the fix +regresses, you now have to reopen an incident you declared over, which costs +disproportionate credibility. + +## Cadence by Severity + +Cadence is the promise you are actually making. The content of an update matters less +than posting when you said you would. + +| Severity | Impact | Update every | Where | +| --- | --- | --- | --- | +| **SEV0 / SEV1** | Full outage or critical feature down for everyone | 30 minutes | Status page, email subscribers, in-app | +| **SEV2** | Major degradation, or a subset of users fully broken | 1 hour | Status page, subscribers | +| **SEV3** | Minor degradation, workaround exists | On meaningful change | Status page | +| **SEV4** | Cosmetic or single-customer | Direct to affected customer | Support channel, not the status page | + +Two rules make this work. + +**Post on schedule even with nothing new.** "Still investigating, no change, next +update in 30 minutes" is a complete update. Silence is read as abandonment, and the +gap between your last update and now is the number customers remember. + +**Never promise an ETA you are not certain of.** A missed ETA converts a technical +problem into a trust problem. Promise the *next update time* instead β€” that is +entirely within your control. + +If you have not agreed on what SEV1 means with your team, do that before the next +incident: the [incident severity matrix](/guides/incident-severity-matrix) explains +the tiers, and the [severity matrix builder](/play/severity-matrix) generates one you +can adapt. + +## Templates by Scenario + +Copy-paste starting points for the incidents that actually recur, each with wording +for all four stages: + +- **[API service disruption](/guides/api-service-disruption)** β€” outages and third-party service failures. +- **[Database performance degradation](/guides/database-performance-degradation)** β€” slow queries and connection exhaustion. +- **[Deployment rollback](/guides/deployment-rollback)** β€” a release you had to reverse. +- **[Feature degradation](/guides/feature-degradation)** β€” one capability broken while the product works. +- **[Network connectivity issues](/guides/network-connectivity-issues)** β€” regional and routing problems. +- **[Scheduled maintenance](/guides/scheduled-maintenance)** β€” planned work, announced in advance. +- **[Security incident response](/guides/security-incident-response)** β€” the one with legal and disclosure constraints attached. + +Adapt them rather than pasting verbatim. A template's value is that it stops you +composing prose at 3am, not that the exact sentences are optimal for your product. + +## What Not to Say + +**"Some users may be experiencing intermittent issues."** This is four hedges in one +sentence. If logins are failing, say logins are failing. + +**Cause in the first update.** Early theories are usually wrong. Correcting a public +diagnosis costs more than the twenty minutes of not naming one. + +**Blaming a provider as an explanation.** Naming a dependency is fine as fact. +Presenting it as absolution is not β€” customers bought availability from you, and your +provider's outage is your architecture's problem. + +**Apologies in place of information.** One sentence of apology, then facts. A long +apology with no detail reads as a company that would rather manage feelings than tell +you what is happening. + +**Marketing voice.** No "we're working hard to deliver the best possible experience". +Plain, specific, slightly boring β€” which is +[what status pages should be](/guides/boring-is-better-for-status-pages). + +## After the Incident + +Resolved is not finished. For anything at SEV2 or above, publish a postmortem: +timeline, what actually broke, and what changes so it does not recur. Customers who +lost an hour of work want evidence you understand why. Done well it is also +[surprisingly good marketing](/guides/public-postmortem-underrated-marketing) β€” few +companies do it, and it demonstrates engineering maturity better than any landing +page. + +Track [MTTR](/guides/what-is-mttr) alongside it, but do not confuse the two: MTTR +measures how fast you recovered, not how well you communicated while recovering. A +team can halve MTTR and still lose customers by saying nothing for an hour. + +If you operate under a compliance regime, incident communication is frequently a +control rather than a courtesy β€” see +[SOC 2](/guides/soc-2-status-page-requirements), +[ISO 27001](/guides/iso-27001-incident-communication), +[DORA](/guides/dora-incident-reporting-requirements), and +[NIS2](/guides/nis2-incident-reporting-requirements) for what each expects, including +notification deadlines measured in hours. + +## Where It Gets Published + +All of this needs somewhere to land. A [status page](/status-page) is the +canonical location β€” one URL customers can check without asking, hosted away from the +infrastructure that is failing. Subscribers get updates pushed by email, and you can +[deliver them into customer Slack channels](/guides/slack-status-page-subscriptions) +for the accounts that ask. + +Whether that page is public or private is a real decision with different tradeoffs β€” +[public vs private status pages](/guides/public-vs-private-status-pages) covers it. +And the updates only get written if something tells you to write them, which is what +[uptime monitoring](/uptime-monitoring) is for: the alternative is +[finding out from a customer](/blog/your-customer-found-out-first). + +## Frequently asked questions + +
+ +What is broken in user terms, who it affects, what you are doing, and when you will next post. Never speculate on cause in the first update β€” you will be wrong, and the correction costs more trust than the delay would have. If you know nothing yet, say that you are investigating and give a next-update time. "We are investigating reports of elevated error rates on the API. Next update in 30 minutes" is a complete first update. + +
+ +
+ +Match cadence to severity: every 30 minutes for a full outage, every hour for major degradation, and at meaningful change only for minor issues. Post on schedule even when there is nothing new β€” silence reads as abandonment, and "still investigating, next update in 30 minutes" is a real update. Missing a promised update does more damage than the outage itself in most cases. + +
+ +
+ +Say what happened plainly, without either minimising it or performing contrition. "A configuration change caused 40 minutes of failed logins" is better than both "some users may have experienced intermittent issues" and a paragraph of apology. Customers are deciding whether to trust your future updates, and precision is what earns that. + +
+ +
+ +An update is written during the incident for people who are currently blocked β€” short, factual, and focused on impact and next update time. A postmortem is written afterwards for people deciding whether to keep trusting you β€” it covers timeline, root cause, and what changes so it does not recur. Updates buy patience; postmortems buy trust back. + +
+ +
+ +Someone who is not fixing the incident. The responder deep in the problem is the worst-placed person to write clearly about it, and asking them to context-switch slows recovery. Assign a communications role at the start of any SEV1 or SEV0 β€” usually the incident commander or a support lead working from what responders report. + +
diff --git a/apps/web/src/content/pages/guides/incident-severity-matrix.mdx b/apps/web/src/content/pages/guides/incident-severity-matrix.mdx index b1f356d6..47531ca1 100644 --- a/apps/web/src/content/pages/guides/incident-severity-matrix.mdx +++ b/apps/web/src/content/pages/guides/incident-severity-matrix.mdx @@ -310,3 +310,41 @@ We are investigating a critical issue affecting checkout. The majority of paymen --- Use the [Incident Severity Matrix Builder](/play/severity-matrix) to classify incidents interactively, test your thresholds against real scenarios, and customize the matrix for your team. + +## Frequently asked questions + +
+ +SEV0 indicates a critical incident β€” typically a complete service outage or confirmed security breach that requires immediate response from senior engineering leadership. It's the highest severity level and triggers the most aggressive communication and escalation protocols. + +
+ +
+ +Most teams use 3 or 4 levels. Four levels (SEV0 through SEV3) provide enough granularity to distinguish between a full outage and a minor cosmetic bug without overcomplicating triage during a live incident. + +
+ +
+ +Severity measures the impact of an incident β€” how many users are affected and how badly. Priority reflects business urgency and resource allocation. A typo on your pricing page might be low severity but high priority if it's costing you conversions. Your severity matrix should classify based on impact alone; priority is a triage decision. + +
+ +
+ +In most cases, yes. Security incidents carry outsized risk even when few users are immediately affected β€” the blast radius can expand quickly and the reputational impact is disproportionate. Treating all confirmed security incidents as SEV0 ensures you mobilize the right resources immediately. + +
+ +
+ +Review it quarterly, or after any major incident where the classification felt wrong. If your team consistently debates whether something is a SEV1 or SEV2, your thresholds probably need adjustment. + +
+ +
+ +SEV0 and SEV1 incidents always require a postmortem. SEV2 requires a team-level postmortem. SEV3 postmortems are optional. The postmortem closes the loop by documenting root cause, timeline, and action items to prevent recurrence. + +
diff --git a/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx b/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx index 471001f0..bab22494 100644 --- a/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx +++ b/apps/web/src/content/pages/guides/iso-27001-incident-communication.mdx @@ -112,6 +112,38 @@ If you are writing the incident procedure that A.5.26 tests, 27035-1 is the more - [What is MTTR](/guides/what-is-mttr) β€” recovery measurement for A.5.30 - [What is synthetic monitoring](/guides/what-is-synthetic-monitoring) β€” one input to A.8.16 +## Frequently asked questions + +
+ +No. No Annex A control names a status page. A.5.26 requires incident response according to documented procedures, and those procedures normally include communication to affected parties. A status page is one way to implement and evidence that communication step. + +
+ +
+ +Mainly A.5.26 (response to information security incidents) and A.5.28 (collection of evidence), with supporting relevance to A.5.24, A.5.25, A.5.27, A.5.29, A.5.30, and A.8.16. It is one implementation detail inside a handful of the 93 controls. + +
+ +
+ +SOC 2 tests whether your stated controls operated effectively over a period. ISO 27001 certifies that you run a management system β€” the emphasis is on documented procedures, defined responsibilities, and demonstrable continual improvement. Practically, ISO auditors care more about whether your procedure exists and is followed than about sampling a large incident population. + +
+ +
+ +No. Annex A is a reference set. You select applicable controls through risk assessment and justify inclusions and exclusions in your Statement of Applicability. If you exclude a control, you must be able to explain why. + +
+ +
+ +The standard does not set a number; your own retention policy does, and the auditor checks that you follow it. Certification cycles run three years with annual surveillance audits, so evidence spanning at least twelve months is a practical floor. + +
+ --- Start your status page diff --git a/apps/web/src/content/pages/guides/migrate-from-atlassian-statuspage.mdx b/apps/web/src/content/pages/guides/migrate-from-atlassian-statuspage.mdx index 88df33b6..a310c7d5 100644 --- a/apps/web/src/content/pages/guides/migrate-from-atlassian-statuspage.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-atlassian-statuspage.mdx @@ -150,3 +150,35 @@ Watch a full migration from Atlassian Statuspage to openstatus in real time. - [Blog: Import from Statuspage, Betterstack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) - [Docs: How to Import a Status Page](https://www.openstatus.dev/docs/guides/how-to-import-status-page) - [Top Five Atlassian Statuspage Alternatives](/guides/top-five-atlassian-statuspage-alternatives) + +## Frequently asked questions + +
+ +The import itself takes under 2 minutes. You'll need your Statuspage API key and optionally your Page ID if you have multiple pages. + +
+ +
+ +No. Openstatus imports your components, component groups, incidents (with all updates), maintenances, and email subscribers. SMS and Slack subscribers are not supported β€” you'll see a warning during preview. + +
+ +
+ +Yes. The importer shows a full preview of what will be imported β€” including counts per resource type and any warnings β€” before you confirm. + +
+ +
+ +Atlassian Statuspage doesn't expose monitor configurations via their API, so components are imported as static components. You can connect openstatus monitors to them after import. + +
+ +
+ +Components, component groups, and subscribers are deduplicated by name β€” the importer skips existing resources. However, incidents and maintenances are always created as new entries, so re-running the import will produce duplicates for those. + +
diff --git a/apps/web/src/content/pages/guides/migrate-from-betterstack.mdx b/apps/web/src/content/pages/guides/migrate-from-betterstack.mdx index ca5015fe..50866ff5 100644 --- a/apps/web/src/content/pages/guides/migrate-from-betterstack.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-betterstack.mdx @@ -179,3 +179,41 @@ Watch a full migration from Better Stack to openstatus in real time. - [Import from Statuspage, Better Stack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) -- blog announcement covering all three supported providers. - [How to Import a Status Page](https://www.openstatus.dev/docs/guides/how-to-import-status-page) -- docs guide with detailed instructions and screenshots. - [Top Five Atlassian Statuspage Alternatives](/guides/top-five-atlassian-statuspage-alternatives) -- comparison of status page providers including Better Stack and openstatus. + +## Frequently asked questions + +
+ +Yes. openstatus is the only provider that imports monitors from Better Stack β€” including URL, check frequency, HTTP method, headers, and regions. + +
+ +
+ +No. Better Stack doesn't expose subscribers via their API, so subscriber import is not available. You'll need to re-invite subscribers manually. + +
+ +
+ +You can still import. Without a status page ID, the importer will import your monitors, monitor groups, and incidents from the Better Stack Uptime API. + +
+ +
+ +Better Stack regions are mapped to the nearest openstatus probe location: US β†’ iad (Virginia), EU β†’ fra (Frankfurt), AS β†’ sin (Singapore), AU β†’ syd (Sydney). + +
+ +
+ +Better Stack intervals are snapped to the nearest supported openstatus frequency: 30s, 1m, 5m, 10m, 30m, or 1h. + +
+ +
+ +Monitors, components, and component groups are deduplicated β€” the importer checks for existing resources before creating new ones. However, incidents and maintenances are always created as new entries, so re-running will produce duplicates for those. + +
diff --git a/apps/web/src/content/pages/guides/migrate-from-checkly.mdx b/apps/web/src/content/pages/guides/migrate-from-checkly.mdx index c22c95ef..ea4488d5 100644 --- a/apps/web/src/content/pages/guides/migrate-from-checkly.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-checkly.mdx @@ -181,3 +181,41 @@ Once the import finishes, there are a few things to verify: - [Import from Statuspage, Better Stack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) β€” blog announcement covering cross-provider import. - [How to Import a Status Page](https://www.openstatus.dev/docs/guides/how-to-import-status-page) β€” docs guide with detailed instructions and screenshots. - [What is Synthetic Monitoring](/guides/what-is-synthetic-monitoring) β€” background on the monitoring model openstatus and Checkly share. + +## Frequently asked questions + +
+ +Yes. openstatus imports your Checkly API and URL checks as HTTP monitors β€” including the request URL, method, headers, body, check frequency, and run locations. TCP, ICMP, DNS, and SSL checks are imported when a target can be derived. + +
+ +
+ +API and URL checks import as HTTP monitors. TCP, ICMP, DNS, and SSL map to their openstatus job types. Browser, Playwright, multi-step, heartbeat, gRPC, traceroute, and AI checks have no HTTP-family equivalent and are skipped with a reason in the preview. + +
+ +
+ +Two values: a Checkly API key (User Settings β†’ API keys) and your Checkly account ID (Account Settings β†’ General). Checkly requires the account ID on every API request, so both are mandatory. + +
+ +
+ +Checkly's AWS-region locations are mapped to the nearest openstatus probe: us-east-1 β†’ iad, us-west-2 β†’ sea, eu-west-1 β†’ lhr, eu-central-1 β†’ fra, ap-southeast-1 β†’ sin, ap-southeast-2 β†’ syd, and so on. Unmapped locations fall back to iad. + +
+ +
+ +They import as static components. Checkly's status-page services are abstract entities that don't reference a specific check via the API, so openstatus can't auto-link them to imported monitors. You can link a monitor to any component after import. + +
+ +
+ +Monitors, components, and component groups are deduplicated β€” the importer checks for existing resources before creating new ones. Incidents and maintenances are always created as new entries, so re-running will produce duplicates for those. + +
diff --git a/apps/web/src/content/pages/guides/migrate-from-instatus.mdx b/apps/web/src/content/pages/guides/migrate-from-instatus.mdx index d5ec550b..7615933b 100644 --- a/apps/web/src/content/pages/guides/migrate-from-instatus.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-instatus.mdx @@ -108,3 +108,41 @@ Watch a full migration from Instatus to openstatus in real time. - [Blog: Importing from Statuspage, Betterstack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) - [Docs: How to import a status page](https://www.openstatus.dev/docs/guides/how-to-import-status-page) - [Top five Atlassian Statuspage alternatives](/guides/top-five-atlassian-statuspage-alternatives) + +## Frequently asked questions + +
+ +openstatus automatically detects which Instatus components are groups vs regular components based on the group references in your data, and creates the correct hierarchy. + +
+ +
+ +No. Only email subscribers are imported. Webhook, Slack, Discord, Microsoft Teams, Google Chat, and phone subscribers are skipped β€” you'll see a warning showing how many were skipped. + +
+ +
+ +Instatus maintenances have a start time and duration. Openstatus calculates the end time as start + duration and imports them with the correct time range. + +
+ +
+ +Yes. Instatus uses the same status names as openstatus (investigating, identified, monitoring, resolved), so the mapping is 1:1. + +
+ +
+ +You can specify a Page ID to import a specific page. Run the import once per page if you have multiple. + +
+ +
+ +Components, component groups, and subscribers are deduplicated β€” existing resources are skipped. However, incidents and maintenances are always inserted as new entries, so re-running will create duplicates for those. + +
diff --git a/apps/web/src/content/pages/guides/migrate-from-uptime-robot.mdx b/apps/web/src/content/pages/guides/migrate-from-uptime-robot.mdx index 10099703..411aad3b 100644 --- a/apps/web/src/content/pages/guides/migrate-from-uptime-robot.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-uptime-robot.mdx @@ -113,6 +113,32 @@ Leave both tools running for a week or two. Once you trust the openstatus alerts Join our [Discord community](https://www.openstatus.dev/discord), check the [documentation](https://www.openstatus.dev/docs), or reach out via [email](mailto:ping@openstatus.dev). +## Frequently asked questions + +
+ +openstatus's one-click importer covers status-page tools (Instatus, Atlassian Statuspage, Better Stack) β€” it imports components, incidents, maintenances, and subscribers. UptimeRobot is a monitoring tool, so its monitors are recreated rather than imported: rebuild them in the dashboard, or define them as code with the Terraform provider or CLI. Most setups take under an hour. + +
+ +
+ +For a typical setup of a few dozen monitors, under an hour. If you define monitors as code with Terraform or the CLI, you can script the whole thing and apply it in one go. + +
+ +
+ +Historical uptime data stays in UptimeRobot β€” it isn't transferred. openstatus starts collecting data the moment your monitors go live. Many teams run both in parallel for a short period before switching off UptimeRobot. + +
+ +
+ +Common reasons: UptimeRobot checks from a single location while openstatus checks from 28 regions in parallel; UptimeRobot restricted its free tier to non-commercial use in October 2024; openstatus is open-source and self-hostable; and openstatus includes monitoring as code, a CLI, and an MCP server for AI agents. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/guides/network-connectivity-issues.mdx b/apps/web/src/content/pages/guides/network-connectivity-issues.mdx index 2e4d73f1..414bf513 100644 --- a/apps/web/src/content/pages/guides/network-connectivity-issues.mdx +++ b/apps/web/src/content/pages/guides/network-connectivity-issues.mdx @@ -265,3 +265,27 @@ recurrence. - Use **API Service Disruption** if network issues primarily affect API calls - Use **Database Performance** if network latency affects database connections - Use **Security Incident** if connectivity issues are attack-related + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +Use monitoring data from multiple geographic locations, check CDN provider dashboards, and review user reports by location. Tools like uptime monitors with multi-region checks can quickly identify geographic patterns in outages. + +
+ +
+ +Yes, if safe and practical. Direct IPs, alternate endpoints, or backup URLs can help users during CDN or DNS issues. Just ensure the workaround is secure and won't create additional problems once the primary issue is resolved. + +
+ +
+ +You can still communicate transparently without waiting for your provider. Say 'We're experiencing connectivity issues that appear related to our CDN provider. We're investigating with them and will update you shortly.' Users care about your transparency, not your provider's timeline. + +
diff --git a/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx b/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx index 347dbb39..cd0bb162 100644 --- a/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx +++ b/apps/web/src/content/pages/guides/nis2-incident-reporting-requirements.mdx @@ -125,6 +125,38 @@ Your obligations live in your member state's transposition, which may differ on - [Security incident response template](/guides/security-incident-response) β€” wording for recipient notification - [What is incident management](/guides/what-is-incident-management) β€” the process underneath Article 21 +## Frequently asked questions + +
+ +Three stages under Article 23(4). An early warning within 24 hours of becoming aware of a significant incident. A full incident notification within 72 hours of becoming aware, updating the early warning with an initial assessment of severity, impact, and any indicators of compromise. A final report within one month of the incident notification, covering root cause and remedial measures. If the incident is still ongoing when the final report is due, you submit a progress report instead and the final report follows within one month of the incident being handled. + +
+ +
+ +Yes, separately from regulator reporting. Article 23(1) requires entities to notify the recipients of their services, without undue delay, of significant incidents likely to adversely affect the provision of that service. Article 23(2) adds that where a significant cyber threat exists, you inform recipients of measures or remedies they can take. + +
+ +
+ +It can serve the Article 23(1) obligation to notify service recipients. It cannot serve the 24-hour, 72-hour, or one-month reports β€” those go to your CSIRT or competent authority through a designated national channel, usually a specific portal or form. Publishing to a status page is not notifying a regulator. + +
+ +
+ +Article 23(3) sets the baseline: an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Implementing acts add quantitative thresholds for certain digital infrastructure and digital provider sectors, and national transpositions may add detail. + +
+ +
+ +The directive entered into force in January 2023 with a member state transposition deadline of 17 October 2024. Because it is a directive rather than a regulation, the binding rules are in each member state's national law, and transposition ran late in a number of countries. Check the national implementation that applies to you rather than the directive text alone. + +
+ --- Start your status page diff --git a/apps/web/src/content/pages/guides/public-postmortem-underrated-marketing.mdx b/apps/web/src/content/pages/guides/public-postmortem-underrated-marketing.mdx index bd911107..8a9e92b1 100644 --- a/apps/web/src/content/pages/guides/public-postmortem-underrated-marketing.mdx +++ b/apps/web/src/content/pages/guides/public-postmortem-underrated-marketing.mdx @@ -93,6 +93,38 @@ The question isn't whether you'll have an incident - it's whether you'll have th When your database catches fire and 5,000 people watch you put it out, that's not a disaster - that's the kind of trust you can't buy with any marketing budget. +## Frequently asked questions + +
+ +Public postmortems demonstrate engineering depth, operational maturity, and build trust that no marketing can replicate. When GitLab live-streamed their database recovery, they gained massive respect from the developer community instead of losing customers. Transparency proves you understand your systems and take incidents seriously. + +
+ +
+ +Include five key elements: a clear timeline with exact timestamps, deep root cause analysis (not just symptoms), blameless language focused on systems not individuals, concrete action items with owners and deadlines, and leadership visibility showing founders take responsibility. + +
+ +
+ +Start immediately when the incident begins - don't wait for the postmortem. Share real-time updates on your status page, Twitter/X, and Slack communities as you respond. The postmortem comes later as thorough analysis, but transparency starts the moment something breaks. + +
+ +
+ +Status page updates are real-time communications during active incidents telling users what's happening now. Postmortems are detailed analyses published after resolution, explaining root causes, systemic failures, and prevention plans. Great companies do both - immediate transparency plus thorough follow-up. + +
+ +
+ +The opposite is true. Shallow or hidden responses to incidents signal shallow engineering culture. Detailed postmortems with root cause analysis and systemic thinking prove your team understands their systems. Technical buyers evaluating your infrastructure find this reassuring, not concerning. + +
+ --- Start free. No credit card required. Set up your first status page in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/public-vs-private-status-pages.mdx b/apps/web/src/content/pages/guides/public-vs-private-status-pages.mdx index e7d80eef..1f81c47b 100644 --- a/apps/web/src/content/pages/guides/public-vs-private-status-pages.mdx +++ b/apps/web/src/content/pages/guides/public-vs-private-status-pages.mdx @@ -87,6 +87,44 @@ Match the transparency to the audience. Customers need confidence. Teams need co **Openstatus gives you both.** Create public pages for customer transparency and private pages with full metrics for your team-all from one platform. +## Frequently asked questions + +
+ +Public status pages are open to anyone and designed for customer-facing communication with reviewed, confirmed updates. Private status pages are access-controlled and designed for internal teams, partners, or enterprise clients with real-time metrics, auto-incidents, and detailed operational data. + +
+ +
+ +Create a public status page when you want to proactively communicate service status to customers, reduce support tickets, and build trust through transparency. It's especially important once you have paying customers or when your service reliability directly impacts user workflows. + +
+ +
+ +You need a private status page when you have more than 10 team members who need real-time operational visibility, when you have enterprise customers with contractual SLA requirements, or when you have partners integrating with your platform who need self-service status information. + +
+ +
+ +Yes, but it depends on your audience. For internal teams, auto-incidents are highly valuable - they close the gap between detection and awareness. For partner-facing pages, skip auto-incidents and use reviewed status reports instead, as brief internal hiccups don't need to appear on your partner's dashboard. + +
+ +
+ +Common authentication methods include email domain protection (for known organizations), simple password protection (for broader access or RSS support), SSO integration (for enterprise customers), and IP restriction (for locked-down network environments). Choose based on your audience and security requirements. + +
+ +
+ +No. Public status pages should not use auto-incidents. Every update should be reviewed before publication to ensure accuracy and appropriate messaging. A brief monitoring anomaly or false alarm shouldn't create unnecessary customer concern. + +
+ --- Start free. No credit card required. Set up your first status page in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/scheduled-maintenance.mdx b/apps/web/src/content/pages/guides/scheduled-maintenance.mdx index d16034ad..c6ee7cfa 100644 --- a/apps/web/src/content/pages/guides/scheduled-maintenance.mdx +++ b/apps/web/src/content/pages/guides/scheduled-maintenance.mdx @@ -364,3 +364,33 @@ A: We'll provide updates every hour and notify you of any time extensions. **Q: Can you reschedule?** A: This timing was chosen for minimal impact. Please contact support if you have urgent concerns. + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +Minimum 48 hours for minor maintenance under 30 minutes with no downtime. 1 week notice for standard maintenance 1-4 hours with read-only mode. 2+ weeks notice for major maintenance over 4 hours with full downtime. + +
+ +
+ +Provide updates every hour and notify users immediately of any time extensions. Include the new estimated completion time and reason for the extension. + +
+ +
+ +Yes, always include multiple timezones for global audiences or use UTC time with a timezone converter link. This prevents confusion about when maintenance will occur. + +
+ +
+ +Always include exact date and time with timezone, expected duration, impact description, what users can and cannot do during maintenance, and who to contact with questions. + +
diff --git a/apps/web/src/content/pages/guides/security-incident-response.mdx b/apps/web/src/content/pages/guides/security-incident-response.mdx index 833a271d..549a29e6 100644 --- a/apps/web/src/content/pages/guides/security-incident-response.mdx +++ b/apps/web/src/content/pages/guides/security-incident-response.mdx @@ -214,3 +214,33 @@ about key rotation requirements. - Minor configuration issues β†’ Use general service disruption template Only use security incident language when there's an actual security concern to avoid alarm fatigue. + +## Related + +This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates. + +## Frequently asked questions + +
+ +No. Only communicate publicly when there's a confirmed incident with user impact or when you're taking visible security measures (like requiring password resets). Internal security reviews and patched vulnerabilities without exploitation typically don't require public disclosure. + +
+ +
+ +This varies by jurisdiction and industry. GDPR requires notification within 72 hours for personal data breaches. CCPA has requirements for California residents. Healthcare (HIPAA) and payment systems (PCI DSS) have specific rules. Always consult with legal counsel before publishing security incident communications. + +
+ +
+ +Share enough to demonstrate competence and transparency, but avoid tactical details that could help attackers. Good: 'unauthorized access attempts to our admin panel.' Bad: 'SQL injection on /admin/login using parameter X.' Wait until the vulnerability is fully patched and no longer exploitable before sharing technical details. + +
+ +
+ +Only if there's evidence of credential compromise or unauthorized access to authentication systems. Don't create alarm fatigue by requesting password changes for unrelated security work. Be specific about why you're asking and which accounts are affected. + +
diff --git a/apps/web/src/content/pages/guides/sla-vs-slo-vs-sli.mdx b/apps/web/src/content/pages/guides/sla-vs-slo-vs-sli.mdx index aaeb895e..011ae124 100644 --- a/apps/web/src/content/pages/guides/sla-vs-slo-vs-sli.mdx +++ b/apps/web/src/content/pages/guides/sla-vs-slo-vs-sli.mdx @@ -1,5 +1,7 @@ --- title: "SLA vs SLO vs SLI Explained" +seo: + title: "SLO vs SLA vs SLI: What's the Difference?" description: "Learn the critical differences between SLAs, SLOs, and SLIs. Understand how to measure service reliability, set internal targets, and make customer promises without over-committing or under-delivering." author: "openstatus" publishedAt: "2026-02-09" @@ -23,6 +25,19 @@ Getting this wrong has real consequences. Either you over-promise to customers a Here's what they actually mean, how they relate, and how to use them without screwing up. +## The Short Version + +| | SLI | SLO | SLA | +| --- | --- | --- | --- | +| **What it is** | A measurement | An internal target | An external promise | +| **Who it's for** | Your monitoring | Your team | Your customers | +| **Example** | P95 latency is 180ms | P95 under 200ms, 99.5% of the time | 99.9% uptime, or 10% credit | +| **If you miss it** | Nothing β€” it's just data | Slow down, spend error budget | Service credits, refunds, churn | +| **Who sets it** | Engineering | Engineering and product | Legal and sales | + +The rest of this guide is why each row reads the way it does, and what breaks when +teams collapse the three columns into one. + ## What They Actually Are ### SLI (Service Level Indicator) @@ -36,6 +51,14 @@ An SLI is a specific metric you can measure. Not a feeling. Not a goal. A measur "The site should feel fast" is not an SLI. "P95 page load time under 2 seconds" is an SLI. The difference is whether you can measure it objectively and build alerts around it. +Picking a latency SLI means being precise about which number you mean β€” request +latency and end-to-end response time are not the same measurement, and teams often +write an SLO against one while their monitoring reports the other. See +[latency vs response time](/docs/concept/latency-vs-response-time) before you commit +a threshold to writing. The same trap applies to availability: a single uptime +percentage hides how the downtime was distributed, which is why +[uptime percentage alone is misleading](/guides/why-uptime-percentage-is-misleading). + ### SLO (Service Level Objective) An SLO is your internal target for an SLI. It's what you promise yourself, not what you promise customers. @@ -73,6 +96,14 @@ SLA β†’ External promise to customers (has buffer from SLO) The gap between your SLO (99.95%) and your SLA (99.9%) is your **error budget**. That's the buffer that lets you deploy new features, run experiments, and handle incidents without immediately violating customer agreements. +Those two percentages translate into wall-clock minutes, and the difference is +bigger than it looks β€” 99.9% and 99.95% are 43 and 21 minutes per month +respectively. Run your own numbers with the [SLA calculator](/play/uptime-sla) +before agreeing to a tier. + +For how to calculate that budget, alert on its burn rate, and decide what happens +when it runs out, see [error budgets explained](/guides/error-budgets-explained). + If your SLO and SLA are the same number, one bad deploy breaks your promises. You've eliminated the margin that makes continuous deployment possible. ## Common Mistakes Teams Make @@ -133,7 +164,7 @@ The lesson: don't promise what you can't measure. And don't measure without sett Your public page shows the commitments you've made to customers. Historical uptime against SLA targets. Incident timelines showing when you came close toβ€”but didn't breachβ€”agreements. -This is customer-facing transparency. It's not real-time operations data. It's curated, reviewed communication. +This is customer-facing transparency. It's not real-time operations data. It's curated, reviewed communication. A [public status page](/status-page) is where the SLA number stops being a clause in a contract and becomes something a customer can check for themselves. ### Private Status Page (Track SLOs) @@ -147,6 +178,8 @@ Whether public or private, everything flows from the SLIs. If you can't measure Your entire reliability strategyβ€”internal targets, customer promises, incident response prioritiesβ€”depends on accurate, continuous SLI measurement. +"Continuous" is the load-bearing word. An SLI sampled by hand, or from one machine in one region, will not tell you whether you met a monthly target. [openstatus uptime monitoring](/uptime-monitoring) runs the checks on a schedule from 28 regions and keeps the history, so the number you report at the end of the month is one you measured rather than one you estimated. + ## "But We're Just Three People" If you're a small startup with 5 engineers and 200 customers, implementing a full SLI/SLO/SLA framework might feel like bringing a spreadsheet to a knife fight. You're not wrong. @@ -182,10 +215,42 @@ If you can't measure it, you can't manage it. And you definitely shouldn't promi --- -**OpenStatus tracks all three layers.** Monitor your SLIs, set alerts for SLO thresholds, and display SLA compliance on public and private status pagesβ€”all from one platform. +**openstatus tracks all three layers.** Monitor your SLIs, set alerts for SLO thresholds, and display SLA compliance on public and private status pagesβ€”all from one platform. Try out our SLA calculator +## Frequently asked questions + +
+ +An SLI is a specific metric you measure (like API response time). An SLO is your internal target for that metric (stricter than customer promises). An SLA is your public promise to customers with consequences if you fail. They stack: SLI β†’ SLO β†’ SLA. + +
+ +
+ +The gap between your SLO and SLA is your error budget - the buffer that lets you deploy features, run experiments, and handle incidents without immediately violating customer agreements. If they're the same number, one bad deploy breaks your promises. + +
+ +
+ +A good SLI is specific, measurable, and directly correlates with user experience. If the metric degrades and users don't notice, it's not an SLI. Examples: P95 API response time under 200ms, 99.9% uptime, error rate below 0.1%. + +
+ +
+ +Limit yourself to 3-5 SLIs. Pick metrics that directly impact user experience. Tracking too many creates alert fatigue and buries real issues under noise. Focus on what matters: availability, latency, and error rates. + +
+ +
+ +No. Early-stage startups should skip SLAs entirely until they have the infrastructure to measure and maintain them. Focus on tracking 2-3 SLIs, being transparent about uptime, and communicating clearly during incidents. Formalize SLAs when enterprise customers start requesting them. + +
+ --- Start free. No credit card required. Set up your first status page in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/slack-status-page-subscriptions.mdx b/apps/web/src/content/pages/guides/slack-status-page-subscriptions.mdx index 1f8e6ffc..0e63637f 100644 --- a/apps/web/src/content/pages/guides/slack-status-page-subscriptions.mdx +++ b/apps/web/src/content/pages/guides/slack-status-page-subscriptions.mdx @@ -117,6 +117,50 @@ Because entitlement is managed in the dashboard, these changes do not require co Routing status updates into the Slack Connect channels you already share with enterprise customers turns customer notifications from an ongoing engineering task into a configuration workflow. No per-customer integration code, no new channels to create, no cleanup when people leave - just the same updates you already publish to your status page, delivered where your customers are already working with you. +## Frequently asked questions + +
+ +No. Updates arrive in the Slack Connect channel you already share with the customer. They never sign into openstatus and do not manage their own subscription. + +
+ +
+ +Slack Connect is Slack's native feature for sharing a channel between two separate workspaces. Both sides see the channel in their own Slack, with no guest accounts, no third-party apps, and no shared admin seats. + +
+ +
+ +No. If you already run a Slack Connect channel with a customer for support or account management, point the subscription at that channel. A new dedicated channel only makes sense if you want to separate status updates from other conversations. + +
+ +
+ +No. The page owner controls component scope. This keeps customers from seeing components they are not entitled to, and keeps entitlement decisions auditable on your side. + +
+ +
+ +Update their subscription from the dashboard. Add or remove components and the change takes effect on the next event - no code change or redeploy required. + +
+ +
+ +No. Slack Connect is free for both sides as long as at least one of the two workspaces is on a paid Slack plan. + +
+ +
+ +Openstatus supports both in addition to Slack. Pick the channel that matches how each customer prefers to receive incident updates. + +
+ --- Start free. No credit card required. Configure your first Slack subscription in under 5 minutes. diff --git a/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx b/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx index 25d939d4..3da64c9d 100644 --- a/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx +++ b/apps/web/src/content/pages/guides/soc-2-status-page-requirements.mdx @@ -162,6 +162,38 @@ Read the criteria before taking any vendor's mapping β€” including this one β€” - [Security incident response template](/guides/security-incident-response) β€” wording for the communication itself - [ISO 27001 incident communication](/guides/iso-27001-incident-communication) β€” if you are pursuing both +## Frequently asked questions + +
+ +No. No Trust Services Criterion names a status page. CC2.3 requires you to communicate relevant information to external parties, including how they can report failures and how you inform them of incidents. A status page is one way to evidence that control β€” email distribution lists and support portals are others. What the auditor tests is whether the process exists, is followed, and produces records. + +
+ +
+ +Primarily CC2.3 (communication with external parties) and CC7.4/CC7.5 (incident response and recovery), plus A1.1 if you carry the Availability category. It contributes evidence to those controls. It does not satisfy CC1 (control environment), CC3 (risk assessment), CC5 (control activities), CC6 (logical access), or CC8 (change management). + +
+ +
+ +A population of incidents for the audit period, and for a sample of those, timestamped proof of when each was detected, when customers were notified, what was said, and when it was resolved. They will compare your status page timeline against your internal ticket or alert record to confirm the two agree. + +
+ +
+ +A Type II observation window is typically 3 to 12 months. Your evidence must cover the entire window, which means retention matters more than most teams expect β€” if your monitoring data expires after 14 days, you cannot produce availability evidence for a 12-month period. + +
+ +
+ +No. Compliance automation platforms track your whole control set, collect evidence across dozens of systems, and manage the audit workflow. A status page produces evidence for one narrow slice of that β€” external incident communication. They are complementary, not alternatives. + +
+ --- Start your status page diff --git a/apps/web/src/content/pages/guides/top-five-atlassian-statuspage-alternatives.mdx b/apps/web/src/content/pages/guides/top-five-atlassian-statuspage-alternatives.mdx index 6c33715b..1d7ef84b 100644 --- a/apps/web/src/content/pages/guides/top-five-atlassian-statuspage-alternatives.mdx +++ b/apps/web/src/content/pages/guides/top-five-atlassian-statuspage-alternatives.mdx @@ -167,3 +167,29 @@ While Atlassian Statuspage pioneered the status page market, several alternative ## Need Help or Have Questions? If you need help along the way, feel free to join our [Discord community](https://www.openstatus.dev/discord), check our [documentation](https://www.openstatus.dev/docs) for more information or reach out to us via [email](mailto:ping@openstatus.dev) + +## Frequently asked questions + +
+ +openstatus offers a one-click importer that automatically transfers your components, component groups, incidents (with all updates), maintenances, and email subscribers from Atlassian Statuspage. Just paste your API key, preview what will be imported, and confirm. See our step-by-step migration guide for details. + +
+ +
+ +OpenStatus and Betterstack offer the most generous free tiers. OpenStatus provides unlimited team members at $30/month with monitoring included, while Betterstack has a powerful free tier for solo developers. Both are significantly more affordable than Atlassian Statuspage for small teams. + +
+ +
+ +Yes. Status.io focuses purely on status communication without monitoring. Other platforms like OpenStatus, Instatus, and Betterstack include monitoring but also allow manual incident updates, so you can use your existing monitoring tools if preferred. + +
+ +
+ +OpenStatus is the only open-source option on this list that supports self-hosting, giving you complete control over your data and infrastructure. The other alternatives are cloud-hosted SaaS solutions only. + +
diff --git a/apps/web/src/content/pages/guides/top-five-instatus-alternatives.mdx b/apps/web/src/content/pages/guides/top-five-instatus-alternatives.mdx index 6d31008c..23249db7 100644 --- a/apps/web/src/content/pages/guides/top-five-instatus-alternatives.mdx +++ b/apps/web/src/content/pages/guides/top-five-instatus-alternatives.mdx @@ -215,3 +215,35 @@ For the other alternatives, migration is typically a manual rebuild of component ## Need Help or Have Questions? If you need help along the way, feel free to join our [Discord community](https://www.openstatus.dev/discord), check our [documentation](https://www.openstatus.dev/docs) for more information, or reach out to us via [email](mailto:ping@openstatus.dev). + +## Frequently asked questions + +
+ +openstatus offers a one-click importer that automatically transfers your components, component groups, incidents (with all updates), maintenances, and email subscribers. Paste your Instatus API key, preview what will be imported, and confirm. See our step-by-step migration guide for details. + +
+ +
+ +openstatus and Betterstack are the most cost-effective for small teams. openstatus includes monitoring and unlimited team members from $30/month, while Betterstack has a generous free tier that works well for solo developers. Both are typically cheaper than scaling on Instatus once you outgrow its free plan. + +
+ +
+ +Yes. Status.io and Atlassian Statuspage focus purely on status communication. openstatus, Datadog, and Betterstack include monitoring but also accept manual incident updates and webhooks, so you can keep your existing monitoring tools if you prefer. + +
+ +
+ +openstatus is the only open-source option on this list that supports self-hosting, giving you full control over your data and infrastructure. Instatus, Atlassian Statuspage, Status.io, Datadog, and Betterstack are cloud-hosted SaaS only. + +
+ +
+ +The most common reasons are: needing built-in monitoring instead of stitching together third-party probes, wanting monitoring-as-code via Terraform, needing OpenTelemetry export, requiring private locations for internal services, or wanting an open-source solution for compliance and data residency. + +
diff --git a/apps/web/src/content/pages/guides/top-five-pingdom-alternatives.mdx b/apps/web/src/content/pages/guides/top-five-pingdom-alternatives.mdx index 9e7ef5e5..0b2d7a9f 100644 --- a/apps/web/src/content/pages/guides/top-five-pingdom-alternatives.mdx +++ b/apps/web/src/content/pages/guides/top-five-pingdom-alternatives.mdx @@ -133,6 +133,32 @@ The trade-off is that you're now operating the monitor: it runs from a single lo Join our [Discord community](https://www.openstatus.dev/discord), check the [documentation](https://www.openstatus.dev/docs), or reach out via [email](mailto:ping@openstatus.dev). +## Frequently asked questions + +
+ +The most common reasons are: Pingdom discontinued its free tier after the SolarWinds acquisition, so there's no way to start for free; pricing climbs once you add real user monitoring or transaction checks; it's closed-source with no self-hosting; and it has no built-in public status page, so you need a second tool for incident communication. + +
+ +
+ +UptimeRobot has the most generous free tier (50 monitors), but it's limited to non-commercial use since October 2024. openstatus offers a permanent free plan with multi-region monitoring and a status page, and Better Stack has a usable free tier for solo developers. For unlimited free monitors, the self-hosted Uptime Kuma is the cheapest option if you're willing to run it. + +
+ +
+ +openstatus, Better Stack, and Uptime Kuma include a status page. Pingdom itself does not offer a public status page, which is one of the more common reasons teams switch. UptimeRobot and Checkly are primarily monitoring tools. + +
+ +
+ +Yes. openstatus (AGPL-3.0) and Uptime Kuma (MIT) are both open-source. openstatus is open-source but also offers a managed, multi-region cloud, while Uptime Kuma is self-hosted only and runs from a single location. + +
+ --- Start monitoring from 28 regions today diff --git a/apps/web/src/content/pages/guides/what-is-a-good-response-time.mdx b/apps/web/src/content/pages/guides/what-is-a-good-response-time.mdx new file mode 100644 index 00000000..b736fb09 --- /dev/null +++ b/apps/web/src/content/pages/guides/what-is-a-good-response-time.mdx @@ -0,0 +1,165 @@ +--- +title: "What Is a Good Response Time?" +seo: + title: "What Is a Good Response Time? Load Time Benchmarks" +description: "Target numbers for server response time and browser load time, why you should judge them at the 75th percentile rather than the average, and which metric to fix first when a page feels slow." +author: "openstatus" +publishedAt: "2026-08-15" +category: "fundamentals" +faq: + - question: "What is a good server response time?" + answer: "Under 200ms is fast, 200-500ms is acceptable for a single-region origin answering a distant request, 500ms to 1s is slow enough that users notice, and over 1s needs attention. Judge it per region rather than on a global average - an endpoint answering in 80ms locally and 900ms from the other side of the world has a distribution problem, not a speed problem." + - question: "What is a good page load time?" + answer: "For the browser experience, Google's Core Web Vitals thresholds are the practical standard: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200ms, and Cumulative Layout Shift at or under 0.1. All three are assessed at the 75th percentile of real visits, so hitting them on your own laptop is not the same as passing." + - question: "Should I measure average or percentile response time?" + answer: "Percentiles, essentially always. Averages hide the slow tail that users actually complain about: a page averaging 400ms can still be failing one visitor in twenty at four seconds, and the average will never show it. Track P75 to match how Core Web Vitals are assessed, and P95 or P99 to see the worst experiences you are shipping." + - question: "Is response time the same as page load time?" + answer: "No. Response time measures how long your server takes to answer a request - it ends when the response arrives. Page load time measures what the browser then does with it: parsing HTML, fetching CSS, JavaScript, fonts, and images, and rendering the result. A fast server does not guarantee a fast page, but a slow server makes every browser metric worse, because nothing can start until the response arrives." + - question: "Why is my site fast for me but slow for users?" + answer: "Usually distance, devices, and caching. You are likely testing from close to the origin, on a fast machine, with a warm cache and no third-party scripts blocked. Real users are distributed, often on mobile, and frequently arriving cold. This is why the numbers that matter come from multiple regions and from the 75th percentile of real visits rather than from one test on your own machine." +--- + +"Fast enough" is not a number, which is why this question keeps getting asked. The +honest answer is that there are two different measurements involved and they have +different targets β€” so the first thing to establish is which one you are actually +looking at. + +## Two Different Numbers + +**Response time** is how long your server takes to answer. It ends the moment the +response arrives at the client. This is what an uptime monitor or a +[speed test](/play/checker) measures, and it is entirely your infrastructure's +responsibility. + +**Page load time** is what the browser does next: parse HTML, fetch CSS, JavaScript, +fonts and images, run scripts, and paint something a person can use. This is mostly +your frontend's responsibility, plus whatever third-party tags you have accumulated. + +They are related in one direction only. A fast server does not give you a fast page β€” +you can serve a 40ms response and still take six seconds to render. But a slow server +makes every browser metric worse, because nothing can begin until the response +arrives. If both are bad, fix the server first. + +The precise vocabulary matters more than it looks, and mixing the two up is the most +common reason a performance target never gets met β€” see +[latency vs response time](/docs/concept/latency-vs-response-time). + +## Good Server Response Times + +| Response time | Verdict | Typically means | +| --- | --- | --- | +| Under 200ms | Fast | Served from an edge, or an origin near the requester | +| 200–500ms | Acceptable | Normal for a single-region origin answering a distant request | +| 500ms–1s | Slow | Users perceive this. Origin round trip plus unoptimised per-request work | +| Over 1s | Needs attention | Cold starts, N+1 queries, or no caching anywhere in the path | + +The number that matters is not your best region or your average β€” it is the spread. +An API answering in 80ms from Frankfurt and 900ms from Sydney does not have a speed +problem, it has a distribution problem, and the fix is a CDN or an edge deployment +rather than a faster server. You cannot see that from one probe; +[measuring from multiple regions](/uptime-monitoring) is what makes it visible. + +Within a single response, it is worth knowing which phase is slow. DNS, connection, +and TLS are mostly distance and configuration; time to first byte is your application +actually working. A 40ms TTFB behind a 300ms connection phase is a fast application a +long way from the user. + +## Good Page Load Times + +For the browser half, Google's Core Web Vitals are the practical standard, because +they are what search ranking and most performance tooling actually assess: + +| Metric | Good | Needs improvement | Poor | +| --- | --- | --- | --- | +| **LCP** β€” Largest Contentful Paint | ≀ 2.5s | 2.5–4.0s | > 4.0s | +| **INP** β€” Interaction to Next Paint | ≀ 200ms | 200–500ms | > 500ms | +| **CLS** β€” Cumulative Layout Shift | ≀ 0.1 | 0.1–0.25 | > 0.25 | + +Two things people miss. + +**INP replaced First Input Delay.** If you are still tracking FID, you are tracking a +retired metric β€” INP measures the full latency of an interaction rather than just the +delay before processing starts, and it is considerably harder to pass. + +**These are assessed at the 75th percentile of real visits**, not on your machine. +Passing locally tells you almost nothing; a quarter of your users are allowed to be +slower than the threshold and you still pass, but if the 75th percentile misses, you +fail regardless of how good your median looks. + +## Judge Percentiles, Not Averages + +The average is the least useful summary of a latency distribution, because latency is +heavy-tailed β€” a small number of very slow requests barely move the mean. + +Two endpoints both averaging 400ms: + +- **A:** almost every request lands between 350ms and 450ms. +- **B:** most requests are 180ms, and one in twenty takes four seconds. + +Identical averages. B is generating your support tickets. Track **P75** to align with +how Core Web Vitals are assessed, and **P95** or **P99** to see the worst experience +you are actually shipping. This is the same reason +[uptime percentage alone is misleading](/guides/why-uptime-percentage-is-misleading): +one aggregate number hides the distribution that people experience. + +## What to Fix First + +1. **Measure from where users are.** A check from the same region as your origin will + report healthy numbers indefinitely while distant users time out. +2. **Fix the server before the frontend.** Everything downstream waits on the + response. +3. **Find the slow phase, not the slow page.** DNS, connect, TLS, TTFB, and transfer + fail for different reasons and have different fixes. +4. **Set the target as a percentile at a threshold**, not a vague goal β€” "P95 under + 500ms from every region we sell into" is testable. "The site should feel fast" is + not. +5. **Then watch it over time.** A single measurement is a snapshot; response times + move with traffic, deploys, and time of day. + +Once you have a number worth defending, it becomes an [SLI, then an +SLO](/guides/sla-vs-slo-vs-sli), and the room you have to miss it is your +[error budget](/guides/error-budgets-explained). + +## Measure Yours + +Run your URL through the [global speed test](/play/checker) to see the server-side +number and its phase breakdown from 28 regions, with no account required. For the +browser metrics, use Chrome's built-in Lighthouse panel or the Chrome User Experience +Report, which reports field data at the 75th percentile rather than lab conditions. + +To turn either into something you actually notice changing, +[uptime monitoring](/uptime-monitoring) re-runs the check on a schedule and keeps the +history β€” the difference between knowing your response time today and knowing it got +worse last Thursday. + +## Frequently asked questions + +
+ +Under 200ms is fast, 200–500ms is acceptable for a single-region origin answering a distant request, 500ms to 1s is slow enough that users notice, and over 1s needs attention. Judge it per region rather than on a global average β€” an endpoint answering in 80ms locally and 900ms from the other side of the world has a distribution problem, not a speed problem. + +
+ +
+ +For the browser experience, Google's Core Web Vitals thresholds are the practical standard: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200ms, and Cumulative Layout Shift at or under 0.1. All three are assessed at the 75th percentile of real visits, so hitting them on your own laptop is not the same as passing. + +
+ +
+ +Percentiles, essentially always. Averages hide the slow tail that users actually complain about: a page averaging 400ms can still be failing one visitor in twenty at four seconds, and the average will never show it. Track P75 to match how Core Web Vitals are assessed, and P95 or P99 to see the worst experiences you are shipping. + +
+ +
+ +No. Response time measures how long your server takes to answer a request β€” it ends when the response arrives. Page load time measures what the browser then does with it: parsing HTML, fetching CSS, JavaScript, fonts, and images, and rendering the result. A fast server does not guarantee a fast page, but a slow server makes every browser metric worse, because nothing can start until the response arrives. + +
+ +
+ +Usually distance, devices, and caching. You are likely testing from close to the origin, on a fast machine, with a warm cache and no third-party scripts blocked. Real users are distributed, often on mobile, and frequently arriving cold. This is why the numbers that matter come from multiple regions and from the 75th percentile of real visits rather than from one test on your own machine. + +
diff --git a/apps/web/src/content/pages/guides/what-is-a-status-page.mdx b/apps/web/src/content/pages/guides/what-is-a-status-page.mdx index f684a73c..b01e6e11 100644 --- a/apps/web/src/content/pages/guides/what-is-a-status-page.mdx +++ b/apps/web/src/content/pages/guides/what-is-a-status-page.mdx @@ -123,6 +123,56 @@ A status page is the simplest, highest-leverage trust-building tool you have dur If you don't have one, you're either too small to need one (rare) or losing trust during every outage without realizing it (common). +## Frequently asked questions + +
+ +A status page is a public-facing web page that displays the real-time operational health of a service. It shows current uptime, active incidents, scheduled maintenance, and historical reliability metrics. The point is to give users a single, trustworthy place to check whether a problem is on your end or theirs. + +
+ +
+ +Without a status page, every outage floods your support inbox with the same question: 'is it down?' A status page deflects that load, builds trust by being transparent during incidents, and signals operational maturity to enterprise buyers who often require one before signing a contract. + +
+ +
+ +A public status page is visible to anyone and shows curated, user-facing reliability data. A private status page is gated behind authentication and shows real-time operational metrics to internal teams or specific customers - typically more granular and used for SLO tracking, not customer communication. + +
+ +
+ +At minimum: current component statuses (API, dashboard, auth, etc.), active incidents with timestamps and updates, scheduled maintenance windows, and historical uptime for the last 30-90 days. Optional but valuable: subscription options (email, SMS, Slack, RSS), incident postmortems, and per-region status. + +
+ +
+ +Yes. Host it on a separate domain or subdomain (e.g., status.yourcompany.com) on independent infrastructure. If your main service is down and your status page is on the same servers, users see nothing - exactly when they need information most. + +
+ +
+ +Every 15-30 minutes during an active incident, even if there's nothing new to report. 'Still investigating, next update at 14:30' is more useful than silence. Silence makes users assume you've abandoned them. + +
+ +
+ +If you have paying customers, yes. It's not about scale - it's about trust. A simple status page with uptime history and an incident feed signals you take reliability seriously. It takes less than an hour to set up and pays for itself the first time something breaks. + +
+ +
+ +A monitoring tool checks whether your service is up and alerts your team. A status page communicates that information to users. They're connected - monitoring data often drives status page updates - but they serve different audiences. Monitoring is for engineers; status pages are for customers. + +
+ --- **OpenStatus is an open-source status page and monitoring platform.** Set up a public status page, configure monitors, and start communicating reliably during incidents - all from one place. diff --git a/apps/web/src/content/pages/guides/what-is-incident-management.mdx b/apps/web/src/content/pages/guides/what-is-incident-management.mdx index 5e2146cf..f451b989 100644 --- a/apps/web/src/content/pages/guides/what-is-incident-management.mdx +++ b/apps/web/src/content/pages/guides/what-is-incident-management.mdx @@ -12,7 +12,7 @@ faq: - question: "What's an incident commander?" answer: "The incident commander is the single person responsible for coordinating the response - making decisions, assigning tasks, and keeping the team focused. They are not necessarily the most technical person on the call. Their job is leadership during the incident: who's doing what, what we know, when we'll update customers, when to escalate." - question: "How do you define incident severity?" - answer: "Most teams use a 4-tier scale: SEV1 (critical, customer-facing, all hands), SEV2 (major impact, urgent), SEV3 (partial impact, business hours), SEV4 (minor, planned work). The exact thresholds depend on your product, but the key is having clear criteria so the team doesn't argue about severity in the middle of an outage." + answer: "Most teams use a 4-tier scale: SEV0 (critical, customer-facing, all hands), SEV1 (major impact, urgent), SEV2 (partial impact, business hours), SEV3 (minor, planned work). The exact thresholds depend on your product, but the key is having clear criteria so the team doesn't argue about severity in the middle of an outage." - question: "What's the difference between an incident and an outage?" answer: "An outage is one type of incident - your service is fully unreachable. An incident is any unplanned disruption: outages, degraded performance, data correctness issues, security events, third-party failures. All outages are incidents; not all incidents are outages." - question: "What goes in an incident postmortem?" @@ -97,14 +97,14 @@ A working severity model: | Severity | Criteria | Response | |----------|---------------------------------------------------------------------------|-----------------------------------| -| **SEV1** | Full outage or critical data loss affecting many customers | All-hands, page on-call immediately, public status update within 15m | -| **SEV2** | Major feature broken, significant customer impact, or revenue at risk | Page on-call, public status update within 30m | -| **SEV3** | Partial impact, workaround exists, no immediate revenue risk | Business hours response, status update if customer-facing | -| **SEV4** | Minor issue, internal-only, or planned/expected impact | Handle in normal work queue | +| **SEV0** | Full outage or critical data loss affecting many customers | All-hands, page on-call immediately, public status update within 15m | +| **SEV1** | Major feature broken, significant customer impact, or revenue at risk | Page on-call, public status update within 30m | +| **SEV2** | Partial impact, workaround exists, no immediate revenue risk | Business hours response, status update if customer-facing | +| **SEV3** | Minor issue, internal-only, or planned/expected impact | Handle in normal work queue | The exact thresholds depend on your business. The important thing is that they're defined ahead of time so the team isn't arguing about severity in the middle of an outage. -A common pitfall: severity inflation. If everything is SEV1, nothing is. Be honest. Reserve SEV1 for genuine "drop everything" events. +A common pitfall: severity inflation. If everything is SEV0, nothing is. Be honest. Reserve SEV0 for genuine "drop everything" events. See our [incident severity matrix](/guides/incident-severity-matrix) for a more detailed framework. @@ -137,7 +137,7 @@ A good postmortem has: **No formal declaration.** Engineers debug for an hour before someone says "wait, should we call this an incident?" By then, customers have been on Twitter for 45 minutes. -**Severity inflation.** Everything is SEV1, so on-call burns out and nothing is actually prioritized. +**Severity inflation.** Everything is SEV0, so on-call burns out and nothing is actually prioritized. **Fixing root cause during the incident.** Restore service first. The instinct to "really fix it" during an active incident usually extends the outage. Mitigate now, root-cause later. @@ -163,6 +163,62 @@ Incident management isn't about preventing incidents - they happen to everyone. Teams that get this right preserve customer trust through outages. Teams that don't lose it during the second one. +## Frequently asked questions + +
+ +Incident management is the process a team uses to detect, respond to, resolve, and learn from unplanned service disruptions. It covers the technical work of fixing the problem, the communication work of keeping customers informed, and the organizational work of running a postmortem so the same problem doesn't recur. + +
+ +
+ +Detection (something is wrong), declaration (someone calls it an incident), response (assemble a team and start mitigating), communication (update customers via the status page), resolution (the immediate problem is fixed), and postmortem (learn what happened and prevent recurrence). Each stage has a different cadence and a different audience. + +
+ +
+ +The incident commander is the single person responsible for coordinating the response - making decisions, assigning tasks, and keeping the team focused. They are not necessarily the most technical person on the call. Their job is leadership during the incident: who's doing what, what we know, when we'll update customers, when to escalate. + +
+ +
+ +Most teams use a 4-tier scale: SEV0 (critical, customer-facing, all hands), SEV1 (major impact, urgent), SEV2 (partial impact, business hours), SEV3 (minor, planned work). The exact thresholds depend on your product, but the key is having clear criteria so the team doesn't argue about severity in the middle of an outage. + +
+ +
+ +An outage is one type of incident - your service is fully unreachable. An incident is any unplanned disruption: outages, degraded performance, data correctness issues, security events, third-party failures. All outages are incidents; not all incidents are outages. + +
+ +
+ +A clear timeline of what happened, root cause analysis, customer impact (how many users, how long, what they experienced), what went well, what didn't, and action items with owners and due dates. The point is to learn - blameless framing, focus on systems and processes rather than individuals. + +
+ +
+ +Initial acknowledgment within 5-15 minutes of detection. Updates every 15-30 minutes during active incidents, even if there's nothing new to report - silence is worse than 'still investigating, next update at 14:30'. Resolution message when the immediate problem is fixed. Follow-up postmortem within a week. + +
+ +
+ +MTTR (Mean Time To Recovery) is the average time from incident detection to resolution. It's the headline metric for incident response maturity. Lower MTTR means faster recovery, less customer impact, and usually better tooling and process. See our guide on MTTR for the full breakdown. + +
+ +
+ +A postmortem that focuses on systems, processes, and contributing factors rather than individual mistakes. The premise: people don't show up wanting to cause incidents - if a system allowed a human error to cause customer impact, the system is the problem. Blameless framing produces honest postmortems; blame-heavy framing produces defensive ones. + +
+ --- **OpenStatus combines monitoring and status pages so detection and communication live in one place.** Open-source, with on-call alerting and incident management built in. diff --git a/apps/web/src/content/pages/guides/what-is-mttr.mdx b/apps/web/src/content/pages/guides/what-is-mttr.mdx index 61a6b5b2..ee2d870f 100644 --- a/apps/web/src/content/pages/guides/what-is-mttr.mdx +++ b/apps/web/src/content/pages/guides/what-is-mttr.mdx @@ -1,14 +1,18 @@ --- title: "What Is MTTR? (And the Other MTT-Whatevers)" -description: "MTTR is the average time it takes to recover from an incident. But there are four different MTT- metrics that get confused regularly. Here's what each one actually measures, how to calculate them, and how to actually move the numbers." +description: "MTTR is the average time it takes to recover from an incident. But there are five different MTT- metrics that get confused regularly - including MTBF, which pairs with MTTR to give you availability. Here's what each one measures and how to move the numbers." author: "openstatus" publishedAt: "2026-05-09" category: "fundamentals" faq: - question: "What is MTTR?" answer: "MTTR most commonly stands for Mean Time To Recovery (or Mean Time To Resolve) - the average time from when an incident is detected to when service is restored. It's calculated as total downtime across incidents divided by the number of incidents. Lower is better. It's the headline metric for incident response maturity." - - question: "What's the difference between MTTR, MTTD, MTTA, and MTTF?" - answer: "MTTD (Mean Time To Detect) - time from problem occurring to your team noticing. MTTA (Mean Time To Acknowledge) - time from alert firing to a human acknowledging. MTTR (Mean Time To Recovery) - time from detection to service restored. MTTF (Mean Time To Failure) - average time a system runs before failing. They're stages on a timeline; MTTR is usually the headline number." + - question: "What's the difference between MTTR, MTTD, MTTA, MTTF, and MTBF?" + answer: "MTTD (Mean Time To Detect) - time from problem occurring to your team noticing. MTTA (Mean Time To Acknowledge) - time from alert firing to a human acknowledging. MTTR (Mean Time To Recovery) - time from detection to service restored. MTTF (Mean Time To Failure) - average time a system runs before failing. MTBF (Mean Time Between Failures) - average time between one incident ending and the next starting. The first four are stages on a single incident's timeline; MTBF measures the gaps between incidents." + - question: "What is the difference between MTBF and MTTF?" + answer: "MTTF is for things you replace, MTBF is for things you repair. A hard drive has an MTTF because when it fails you discard it. A service has an MTBF because when it breaks you fix it and it keeps running. For software systems MTBF is almost always the metric you actually want, and MTTF is a hardware inheritance that gets misapplied." + - question: "How do MTBF and MTTR relate to availability?" + answer: "Availability = MTBF / (MTBF + MTTR). If your service runs 200 hours between incidents and takes 1 hour to recover, availability is 200/201 = 99.5%. The formula shows the trade-off directly: you can raise availability by breaking less often or by recovering faster. Halving MTTR to 30 minutes and doubling MTBF to 400 hours both land at 99.75%, so pick whichever is cheaper for your team." - question: "How do you calculate MTTR?" answer: "Sum the total downtime across all incidents in a period, then divide by the number of incidents. Example: 3 incidents totaling 90 minutes of downtime = MTTR of 30 minutes. Some teams measure from detection to resolution; others from start of impact to resolution. Be explicit about which definition you use." - question: "What's a good MTTR?" @@ -27,13 +31,13 @@ faq: answer: "MTTR feeds directly into your error budget. Every minute of downtime burns budget. A team with MTTR of 4 hours has very different error budget math than one with MTTR of 20 minutes. Improving MTTR effectively lets you take more deployment risk because each incident costs less of your budget." --- -There are four different "MTT-" acronyms in incident management. They all sound similar, get used interchangeably, and measure completely different things. The result is engineering org-charts arguing about whose number is better when they aren't even measuring the same phenomenon. +There are five different "MTT-" acronyms in incident management. They all sound similar, get used interchangeably, and measure completely different things. The result is engineering org-charts arguing about whose number is better when they aren't even measuring the same phenomenon. -MTTR is the headline one - the average time from incident detection to service restored. It's the standard benchmark for how good a team is at handling outages. Here's what it actually measures, how it relates to the other three MTT-metrics, and how to actually move the number. +MTTR is the headline one - the average time from incident detection to service restored. It's the standard benchmark for how good a team is at handling outages. Here's what it actually measures, how it relates to the other four MTT-metrics, and how to actually move the number. -## The Four MTT-Metrics +## The Five MTT-Metrics -Most incident timelines have four phases. Each has its own metric. +Four of them are phases of a single incident's timeline. The fifth, MTBF, measures the quiet stretches in between. ``` Problem starts ──── Detection ──── Acknowledgment ──── Resolution @@ -75,6 +79,35 @@ Driven by: overall reliability, change management, system design. Less commonly tracked. Requires a long incident history to be meaningful. Often used for hardware originally; less precise for software systems. +### MTBF - Mean Time Between Failures + +Average time between one incident ending and the next one starting. + +Driven by: change quality, test coverage, architectural resilience, dependency stability. + +MTBF and MTTF get confused constantly, and the distinction is genuinely simple: **MTTF is for things you replace, MTBF is for things you repair.** A hard drive has an MTTF because when it dies you throw it away. A service has an MTBF because when it breaks you fix it and it keeps running. For software, MTBF is almost always the metric you actually want. + +Unlike the other four, MTBF is not a phase of an incident β€” it measures the gaps *between* incidents. That makes it the frequency metric to MTTR's duration metric, which is why the two belong together: + +``` +─── incident ─── uptime ─── incident ─── uptime ─── incident ─── + MTTR MTBF MTTR MTBF MTTR +``` + +## MTBF and MTTR Together: Availability + +The reason to track both is that availability falls straight out of them: + +``` +Availability = MTBF / (MTBF + MTTR) +``` + +**Example:** your service runs 200 hours between incidents and takes 1 hour to recover. Availability = 200 / 201 = **99.5%**. + +This is the formula that makes the trade-off concrete. You can raise availability by breaking less often (higher MTBF) or by recovering faster (lower MTTR), and the arithmetic tells you which is cheaper for you. Halving MTTR from 1 hour to 30 minutes takes that example to 99.75%. Doubling MTBF to 400 hours gets you the same place. Most teams find recovery speed easier to buy than reliability. + +It also explains why an availability target is not really one number. 99.9% is reachable with frequent tiny incidents or with rare long ones, and those are very different engineering problems behind an identical SLO. See [error budgets explained](/guides/error-budgets-explained) for what that permitted downtime actually buys you, and [why uptime percentage alone is misleading](/guides/why-uptime-percentage-is-misleading) for what the single number hides. + ## How to Calculate MTTR The basic math: @@ -88,7 +121,7 @@ MTTR = Total downtime across incidents / Number of incidents The catch is defining "downtime." Two definitions in common use: - **Detection to resolution** - measures response speed. Excludes the time the system was broken before you knew. -- **Impact start to resolution** - measures total customer-visible downtime. Includes [MTTD](/guides/what-is-mttr#mttd) inside it. +- **Impact start to resolution** - measures total customer-visible downtime. Includes [MTTD](#mttd-mean-time-to-detect) inside it. Pick one. Be explicit about which. Don't switch between them. @@ -185,9 +218,83 @@ Track it by severity. Look at percentiles, not just the mean. Optimize the three The teams with the best MTTR aren't the ones who never have incidents. They're the ones who've practiced handling them. +## Frequently asked questions + +
+ +MTTR most commonly stands for Mean Time To Recovery (or Mean Time To Resolve) - the average time from when an incident is detected to when service is restored. It's calculated as total downtime across incidents divided by the number of incidents. Lower is better. It's the headline metric for incident response maturity. + +
+ +
+ +MTTD (Mean Time To Detect) - time from problem occurring to your team noticing. MTTA (Mean Time To Acknowledge) - time from alert firing to a human acknowledging. MTTR (Mean Time To Recovery) - time from detection to service restored. MTTF (Mean Time To Failure) - average time a system runs before failing. MTBF (Mean Time Between Failures) - average time between one incident ending and the next starting. The first four are stages on a single incident's timeline; MTBF measures the gaps between incidents. + +
+ +
+ +MTTF is for things you replace, MTBF is for things you repair. A hard drive has an MTTF because when it fails you discard it. A service has an MTBF because when it breaks you fix it and it keeps running. For software systems MTBF is almost always the metric you actually want, and MTTF is a hardware inheritance that gets misapplied. + +
+ +
+ +Availability = MTBF / (MTBF + MTTR). If your service runs 200 hours between incidents and takes 1 hour to recover, availability is 200/201 = 99.5%. The formula shows the trade-off directly: you can raise availability by breaking less often or by recovering faster. Halving MTTR to 30 minutes and doubling MTBF to 400 hours both land at 99.75%, so pick whichever is cheaper for your team. + +
+ +
+ +Sum the total downtime across all incidents in a period, then divide by the number of incidents. Example: 3 incidents totaling 90 minutes of downtime = MTTR of 30 minutes. Some teams measure from detection to resolution; others from start of impact to resolution. Be explicit about which definition you use. + +
+ +
+ +Depends entirely on your service criticality and severity tier. Rough benchmarks for SaaS: SEV1 incidents, under 30 minutes is excellent, 1-2 hours is typical. SEV2, under 2 hours is good. The trend matters more than the absolute number - a team whose MTTR is dropping quarter over quarter is improving; a team with low MTTR that's flat may just be in a quiet period. + +
+ +
+ +MTTR averages can hide outliers. Ten 5-minute incidents and one 8-hour outage average out to about 48 minutes - which looks fine, but the 8-hour outage is what customers remember. Track percentiles (P50, P95, P99) and look at the distribution, not just the mean. Also be wary of teams who 'lower MTTR' by silently downgrading incident severity. + +
+ +
+ +Three levers: detection (better monitoring lowers MTTD), response (runbooks, on-call rotations, and clear roles lower MTTA and active response time), and recovery (good rollback tooling, feature flags, and automated mitigations lower the time to actually fix things). Each one shaves minutes off the total. + +
+ +
+ +MTTF is Mean Time To Failure - the average uptime between failures. For SaaS, it's the inverse of how often you have incidents. High MTTF means rare incidents. It's usually a hardware reliability metric originally but applies to software systems too. Less commonly tracked than MTTR because it requires a long history of incident data to be meaningful. + +
+ +
+ +Often used interchangeably, but technically: 'recovery' is when service is back to normal for users, 'resolve' is when the underlying issue is fully fixed (which may include follow-up work after service is restored). Pick one definition for your team and use it consistently. Mixing them produces meaningless trends. + +
+ +
+ +Yes. A 4-hour MTTR for SEV3 incidents is fine. A 4-hour MTTR for SEV1 incidents is a problem. Aggregating across severities hides important information. Most teams report MTTR separately for SEV1, SEV2, and SEV3. + +
+ +
+ +MTTR feeds directly into your error budget. Every minute of downtime burns budget. A team with MTTR of 4 hours has very different error budget math than one with MTTR of 20 minutes. Improving MTTR effectively lets you take more deployment risk because each incident costs less of your budget. + +
+ --- -**OpenStatus combines monitoring (lower MTTD) with status pages and alerting (lower MTTA) in one platform** - tightening the whole incident timeline. +**openstatus combines monitoring (lower MTTD) with status pages and alerting (lower MTTA) in one platform** - tightening the whole incident timeline. [Uptime monitoring](/uptime-monitoring) runs the checks that set your MTTD floor, and [latency vs response time](/docs/concept/latency-vs-response-time) covers what those checks actually measure. Try openstatus free diff --git a/apps/web/src/content/pages/guides/what-is-synthetic-monitoring.mdx b/apps/web/src/content/pages/guides/what-is-synthetic-monitoring.mdx index 2e65e63e..dc4fb789 100644 --- a/apps/web/src/content/pages/guides/what-is-synthetic-monitoring.mdx +++ b/apps/web/src/content/pages/guides/what-is-synthetic-monitoring.mdx @@ -157,6 +157,62 @@ Synthetic monitoring is how you find out something is broken before your custome Start with HTTP checks on critical endpoints. Add browser checks for user flows that matter. Run from multiple regions. Push results to your [status page](/guides/what-is-a-status-page) so users have an authoritative source when things break. +## Frequently asked questions + +
+ +Synthetic monitoring uses scripted, automated checks to simulate user actions against your service - hitting an API endpoint, loading a page, completing a checkout - from external locations on a fixed schedule. It catches problems before real users hit them, and it works even when you have zero traffic. + +
+ +
+ +Synthetic monitoring runs scripted, fake traffic on a schedule from your monitoring provider's infrastructure. RUM captures data from actual user sessions in real time. Synthetic is proactive and deterministic; RUM is reactive and reflects real-world conditions. Most mature teams use both: synthetic for catching regressions early, RUM for understanding what real users experience. + +
+ +
+ +API availability and response time, full page loads (with JavaScript execution), multi-step user flows (login, signup, checkout), SSL certificate validity, DNS resolution, third-party integrations, and end-to-end transactions that span multiple services. Anything you can script can be monitored. + +
+ +
+ +Use synthetic monitoring (beyond simple uptime checks) when failure modes can't be detected by a single HTTP request. If your login flow depends on three services and any one of them being broken makes signups fail, a synthetic browser check that completes the full login is the only way to know it works end-to-end. + +
+ +
+ +Yes - that's one of its main advantages. Synthetic checks run on a schedule regardless of whether real users are hitting your service. This makes it ideal for pre-launch validation, low-traffic services, off-hours coverage, and detecting regressions in features that aren't used often. + +
+ +
+ +A browser check loads your page in a real headless browser (typically Chromium), executes JavaScript, and can click buttons, fill forms, and navigate multiple steps. It catches problems pure HTTP checks miss - broken JavaScript, third-party script failures, layout breaks, slow rendering - at the cost of running slower and using more resources. + +
+ +
+ +Simple HTTP checks: every 30 seconds to 1 minute. Browser checks: every 5-15 minutes (they're slow and expensive). Multi-step transaction checks: every 5-15 minutes. The more complex the check, the less frequent it makes sense to run - and the higher the value of each successful run. + +
+ +
+ +A transaction monitor (also called a multi-step API check) runs a sequence of requests that depend on each other - log in, capture a token, use that token to make an authenticated request, validate the response, log out. It tests the whole flow as a unit, the way real users actually interact with your service. + +
+ +
+ +No. Synthetic monitoring tells you whether a controlled, scripted scenario works. RUM tells you what your actual users experience - including problems specific to their devices, browsers, regions, and ISPs. They answer different questions and complement each other. + +
+ --- **OpenStatus runs synthetic monitors - HTTP, TCP, DNS, and full browser checks - from multiple regions worldwide.** Open-source, with built-in status page integration. diff --git a/apps/web/src/content/pages/guides/what-is-uptime-monitoring.mdx b/apps/web/src/content/pages/guides/what-is-uptime-monitoring.mdx index 49c9a5fc..6a6cabc6 100644 --- a/apps/web/src/content/pages/guides/what-is-uptime-monitoring.mdx +++ b/apps/web/src/content/pages/guides/what-is-uptime-monitoring.mdx @@ -142,6 +142,62 @@ Uptime monitoring exists because you cannot trust your own infrastructure to tel Set it up. Monitor the things customers actually depend on. Use multiple regions. Tune the check frequency for the criticality. Push results into a [status page](/guides/what-is-a-status-page) so users can self-serve when things break. +## Frequently asked questions + +
+ +Uptime monitoring is the practice of regularly checking - usually every 30 seconds to 5 minutes - whether your service is reachable and returning the expected response. The checks run from external locations so they catch problems your internal infrastructure can't see, like DNS failures, certificate expirations, or regional outages. + +
+ +
+ +A monitoring service sends synthetic requests (HTTP, TCP, ping, or full browser sessions) to your endpoints from probe locations around the world on a fixed interval. If a request fails or times out, the monitor flags it. Most systems require multiple consecutive failures from different regions before alerting, to avoid noise from transient network blips. + +
+ +
+ +99.9% uptime means roughly 8.76 hours of allowed downtime per year, or about 43 minutes per month. 99.99% drops that to 52 minutes per year. 99.999% ('five nines') is about 5 minutes per year - a target that's expensive to hit and usually only meaningful for infrastructure providers. + +
+ +
+ +For customer-facing services, every 30-60 seconds is standard. Less frequent (5-15 minutes) is fine for internal tools or batch systems. More frequent than 30 seconds rarely helps - you start measuring network jitter rather than real availability, and your costs climb fast. + +
+ +
+ +An outage that only affects one region is invisible to a single-region monitor. CDN issues, DNS propagation failures, and regional ISP problems are common. Running checks from at least 3 geographically distributed locations and requiring a majority to fail before alerting catches real outages while ignoring isolated network blips. + +
+ +
+ +Uptime monitoring is the simplest form of synthetic monitoring - a periodic check that an endpoint responds. Synthetic monitoring is the broader category that includes multi-step browser flows, transaction monitoring, and API sequences. All uptime monitoring is synthetic monitoring; not all synthetic monitoring is uptime monitoring. + +
+ +
+ +Both, separately. A working homepage doesn't mean your API is up - they often run on different infrastructure. Monitor the critical user paths: login, the main API endpoints your customers integrate with, payment processing. Each gets its own monitor so you know precisely what's failing. + +
+ +
+ +An alert that fires when nothing was actually wrong - usually because the probe location had a transient network problem, hit a rate limit, or got caught by a bot detection rule. Good monitoring tools reduce false positives by requiring multi-region confirmation and ignoring single-probe failures. + +
+ +
+ +Uptime percentage is (total time minus downtime) divided by total time, expressed as a percent. The catch is defining 'downtime'. Some teams count only full outages; others include degraded performance. Be explicit: '99.9% uptime measured as HTTP 200 response in under 2 seconds from 3 of 5 regions' is meaningful. '99.9% uptime' alone is marketing. + +
+ --- **OpenStatus runs uptime monitors from multiple regions worldwide** and pushes results directly to your status page. Open-source, with sub-minute check frequency and no vendor lock-in. diff --git a/apps/web/src/content/pages/guides/why-every-saas-needs-a-status-page.mdx b/apps/web/src/content/pages/guides/why-every-saas-needs-a-status-page.mdx index 4a2a34ce..ae6ae6d6 100644 --- a/apps/web/src/content/pages/guides/why-every-saas-needs-a-status-page.mdx +++ b/apps/web/src/content/pages/guides/why-every-saas-needs-a-status-page.mdx @@ -172,14 +172,18 @@ You don't need perfection. You need *something*. **Ship a basic status page toda Start with: 1. A simple page showing current status (operational, degraded, down) -2. Automated monitoring that updates status in real-time +2. [Automated monitoring](/uptime-monitoring) that updates status in real-time 3. Subscriber notifications (email at minimum) -4. A process for posting incident updates immediately - not after root cause analysis +4. A process for posting incident updates immediately - not after root cause analysis. The [incident communication guide](/guides/incident-communication) covers cadence by severity and gives you copy-paste templates, so nobody is drafting prose mid-outage 5. Historical uptime data That's it. You can add metrics, regional breakdowns, and advanced features later. The important part is having *a page* before you need it. -**Open-source options exist** - OpenStatus, Uptime Kuma, Cachet. **Hosted platforms exist.** Pick one and ship it this week. Waiting for the "right" solution means you won't have one when it matters. +Concretely: the [create your first status page](/docs/tutorial/create-your-first-status-page) tutorial takes about five minutes end to end, and [openstatus status pages](/status-page) include monitoring rather than selling it separately. + +**Open-source options exist** - openstatus, Uptime Kuma, Cachet. **Hosted platforms exist.** Pick one and ship it this week. Waiting for the "right" solution means you won't have one when it matters. + +If your situation is more specific than "a SaaS", there is probably a closer fit: [startups](/use-case/startups), [API infrastructure](/use-case/api-providers), [enterprise sales](/use-case/enterprise-sales), [reducing support tickets](/use-case/reduce-support-tickets), [compliance](/use-case/compliance), or [open-source projects](/use-case/open-source). ## The Bottom Line @@ -200,6 +204,44 @@ Use a dedicated service or open-source solution designed to stay up when your in Start today. Not after your first major incident. +## Frequently asked questions + +
+ +Yes. Users expect transparency from every SaaS product now. Not having a status page signals you're either hiding problems or haven't thought about reliability. Both destroy trust with technical buyers and enterprise customers. + +
+ +
+ +The opposite. Hiding incidents makes you look unreliable. A status page with honest incident history proves you take reliability seriously and communicate transparently. Companies like Stripe and Vercel publish detailed postmortems - it builds trust, not doubt. + +
+ +
+ +No. Start simple now. A basic status page takes 5 minutes to set up and establishes good habits early. Waiting until after your first major incident means angry customers watching you scramble to set up infrastructure you should have had from day one. + +
+ +
+ +During incidents, hundreds of customers ask 'is it down?' Instead of flooding support with tickets, they check your status page and get an immediate answer. Your support team can focus on helping users affected by the incident rather than repeating the same status update. + +
+ +
+ +Direct ROI: massive reduction in support tickets during incidents, lower customer churn from bad experiences, faster enterprise sales cycles. Indirect ROI: SEO traffic from '[your-product] status' searches, trust building that leads to word-of-mouth, and competitive differentiation against companies that hide their incidents. + +
+ +
+ +No. When your main site goes down, your homegrown status page hosted on the same infrastructure goes down with it. Building reliable status infrastructure means separate hosting, static generation, minimal dependencies, and monitoring for the status page itself. Use a dedicated service or open-source solution designed to stay up when everything else is broken. + +
+ --- **Openstatus makes this easy.** Set up a public or private status page in under 5 minutes. Automated monitoring. Real-time updates. Subscriber notifications. Open-source and transparent - so you can trust it won't fail when everything else does. diff --git a/apps/web/src/content/pages/guides/why-is-my-monitor-failing.mdx b/apps/web/src/content/pages/guides/why-is-my-monitor-failing.mdx index f8881072..bf1b1c45 100644 --- a/apps/web/src/content/pages/guides/why-is-my-monitor-failing.mdx +++ b/apps/web/src/content/pages/guides/why-is-my-monitor-failing.mdx @@ -99,6 +99,38 @@ A monitor that cries wolf gets muted, and a muted monitor is worse than no monit - [HTTP Headers for Monitoring](/guides/http-headers) - [What Is Synthetic Monitoring?](/guides/what-is-synthetic-monitoring) +## Frequently asked questions + +
+ +Almost always one of three things: the check is failing from a region you can't see from your browser, your firewall or bot-protection is blocking the probe's IP, or a single probe location had a transient network blip. Load the site from a different network and region, then check whether the failure is reported from one region or several β€” a single-region failure is usually a false positive. + +
+ +
+ +A false positive is an alert that fires when nothing was actually wrong β€” typically because a single probe location hit a transient network issue, a rate limit, or a bot-detection rule. The fix is to require multiple regions to fail before alerting, so isolated probe-side problems are ignored. + +
+ +
+ +Require multi-region confirmation before alerting, set a realistic timeout (network round-trips from distant regions take longer than local requests), allowlist your monitor's probe IPs in your WAF and rate limiter, and make sure your assertions aren't too strict. openstatus retries a failing check before counting it as down, and only alerts once more than 50% of a monitor's regions agree the check has failed. + +
+ +
+ +Intermittent failures usually point to rate limiting, an overloaded origin under certain traffic, bot-protection challenges that fire occasionally, DNS issues, or a timeout set too aggressively. Look at which regions fail and whether failures cluster at specific times or request volumes. + +
+ +
+ +Yes. An expired, misconfigured, or incomplete certificate chain causes checks to fail even when the server responds β€” browsers and probes both reject invalid certificates. If the failure started abruptly on a specific date, an expired certificate is a prime suspect. + +
+ --- **openstatus checks from up to 28 regions and only alerts when they agree** β€” fewer false positives, real outages caught fast. Open-source, free to start. diff --git a/apps/web/src/content/pages/guides/why-uptime-percentage-is-misleading.mdx b/apps/web/src/content/pages/guides/why-uptime-percentage-is-misleading.mdx index 9a459dbb..0da37209 100644 --- a/apps/web/src/content/pages/guides/why-uptime-percentage-is-misleading.mdx +++ b/apps/web/src/content/pages/guides/why-uptime-percentage-is-misleading.mdx @@ -1,9 +1,18 @@ --- title: "Why Uptime Percentage Alone is Misleading" -description: "99.9% uptime sounds impressive until you realize it tells you nothing about user experience. Learn why availability percentages hide the real story and what to measure instead." +description: "99.9% uptime sounds impressive until you realize it tells you nothing about user experience. What uptime and availability actually mean, why the percentage hides the real story, and what to measure instead." author: "openstatus" publishedAt: "2026-02-13" category: "education" +faq: + - question: "What is the difference between uptime and availability?" + answer: "In practice they are used interchangeably, and most SLAs treat them as synonyms. Where a distinction exists: uptime asks whether the system is running and reachable, while availability asks whether users can successfully do what they came for - usually measured as successful requests divided by total requests. A server that is powered on and returning 500 errors to every request has 100% uptime and 0% availability." + - question: "Is 99.9% uptime good?" + answer: "It depends entirely on how the 43 minutes of monthly downtime is distributed. Forty-three separate one-minute blips are barely noticed; a single 43-minute outage on a Tuesday afternoon is a crisis. Both are 99.9%. The percentage alone cannot tell you which one you had, which is why it is a reporting metric rather than an operational one." + - question: "What should I measure instead of uptime percentage?" + answer: "Latency percentiles (P50, P95, P99), error rates broken down by endpoint and region, user journey success for flows like login and checkout, regional availability rather than a global aggregate, and error budget burn rate. Those five tell you what users actually experienced; a single percentage does not." + - question: "Can you have high uptime and unhappy users?" + answer: "Yes, and it is common. A health check returning 200 OK in 50ms while real requests take eight seconds gives you excellent uptime and a service users consider broken. Uptime measures whether the service responds. It does not measure whether the response was fast enough or correct." --- 99.9% uptime sounds great in sales decks. It makes executives nod approvingly and looks impressive on your status page. @@ -52,6 +61,23 @@ You can have 99.9% uptime with P99 latency at 30 seconds. Technically available. **Availability measures if it responds. Reliability measures if it works.** +## Uptime vs Availability: Is There a Difference? + +Most of the time, no β€” and anyone telling you the two words mean sharply different things is usually selling something. They are used interchangeably across the industry, both expressed as a percentage of a time window, and your SLA almost certainly treats them as synonyms. + +Where a distinction does exist, it is this: + +| | Uptime | Availability | +| --- | --- | --- | +| **Question it answers** | Is the system running? | Can users successfully do what they came for? | +| **Typical measurement** | The process is up and the endpoint is reachable | Successful requests Γ· total requests | +| **A server returning 500s** | Counted as **up** | Counted as **unavailable** | +| **Origin** | Infrastructure and hardware monitoring | Service-level and user-facing measurement | + +The practical consequence: uptime is a property of your *infrastructure*, availability is a property of your *service*. A machine that is powered on, reachable, and returning `500 Internal Server Error` to every request has 100% uptime and 0% availability. That gap is exactly where "our monitoring was green" incidents live. + +Which is why the argument on this page is not really about vocabulary. Whichever word you use, a single percentage over a whole window hides *when* the failures happened, *what* broke, and *who* it hit. Renaming the metric fixes none of that. Measuring the things below does. + ## The Five Nines Trap Teams obsess over pushing 99.9% to 99.99%. The cost grows exponentially in engineering time, infrastructure, and complexity. @@ -66,7 +92,7 @@ You hit your uptime target. Users churn anyway. Stop obsessing over a single percentage. Start measuring what users actually experience: -**Latency percentiles:** P50, P95, P99. How long do real requests take? A P99 of 10 seconds means 1 in 100 users have a terrible experience, even with perfect uptime. +**Latency percentiles:** P50, P95, P99. How long do real requests take? A P99 of 10 seconds means 1 in 100 users have a terrible experience, even with perfect uptime. Be precise about which number you are tracking β€” [latency and response time](/docs/concept/latency-vs-response-time) are different measurements, and a threshold set against one while your monitoring reports the other is a threshold that never fires. **Error rates:** Break them down by endpoint, status code, and region. A 0.1% global error rate could be a 5% error rate for your checkout endpoint. @@ -74,7 +100,9 @@ Stop obsessing over a single percentage. Start measuring what users actually exp **Regional availability:** Don't aggregate global uptime into one number. Your service down in Asia won't show up if North America is fine. -**Error budget burn rate:** Are you on track to blow your SLO? This metric is actionable. A percentage alone tells you nothing about trajectory. +**Error budget burn rate:** Are you on track to blow your SLO? This metric is actionable. A percentage alone tells you nothing about trajectory. [Error budgets explained](/guides/error-budgets-explained) covers how to calculate the budget and what burn rates are worth alerting on. + +**Regional detail, not a regional average.** [Uptime monitoring](/uptime-monitoring) from 28 regions is what makes the fourth point above measurable β€” a single-probe check cannot distinguish "our service is down" from "our service is down in Asia". ## Bottom Line @@ -84,6 +112,32 @@ Measure what users feel: latency, errors by feature, regional failures. If your Stop optimizing for a number that looks good in reports. Start optimizing for the experience your users actually have. +## Frequently asked questions + +
+ +In practice they are used interchangeably, and most SLAs treat them as synonyms. Where a distinction exists: uptime asks whether the system is running and reachable, while availability asks whether users can successfully do what they came for - usually measured as successful requests divided by total requests. A server that is powered on and returning 500 errors to every request has 100% uptime and 0% availability. + +
+ +
+ +It depends entirely on how the 43 minutes of monthly downtime is distributed. Forty-three separate one-minute blips are barely noticed; a single 43-minute outage on a Tuesday afternoon is a crisis. Both are 99.9%. The percentage alone cannot tell you which one you had, which is why it is a reporting metric rather than an operational one. + +
+ +
+ +Latency percentiles (P50, P95, P99), error rates broken down by endpoint and region, user journey success for flows like login and checkout, regional availability rather than a global aggregate, and error budget burn rate. Those five tell you what users actually experienced; a single percentage does not. + +
+ +
+ +Yes, and it is common. A health check returning 200 OK in 50ms while real requests take eight seconds gives you excellent uptime and a service users consider broken. Uptime measures whether the service responds. It does not measure whether the response was fast enough or correct. + +
+ --- Start free. No credit card required. Set up your first status page in under 5 minutes. diff --git a/apps/web/src/content/pages/home.mdx b/apps/web/src/content/pages/home.mdx index 53df62c6..3879315c 100644 --- a/apps/web/src/content/pages/home.mdx +++ b/apps/web/src/content/pages/home.mdx @@ -24,7 +24,7 @@ faq: - question: "Does openstatus have an API?" answer: "Yes. Openstatus exposes a typed JSON-over-HTTP API powered by ConnectRPC, with a published OpenAPI spec at api.openstatus.dev/openapi. Every action in the dashboard β€” managing monitors, status pages, status reports, maintenance windows, and notification channels β€” is reachable from the API. The same API key works across the API, CLI, Node SDK, Terraform provider, and MCP server, and every mutation lands in the audit log." - question: "Can I manage openstatus from Claude or ChatGPT?" - answer: "Yes. Openstatus ships a remote MCP (Model Context Protocol) server at api.openstatus.dev/mcp that connects Claude Desktop, ChatGPT, Cursor, and any MCP-compatible client to your workspace. The assistant can list status pages, create and resolve status reports, and schedule maintenance windows. Every mutation tool requires the assistant to explicitly choose whether to notify subscribers, and every call is recorded in the audit log." + answer: "Yes. Openstatus ships a remote MCP (Model Context Protocol) server at api.openstatus.dev/mcp that connects Claude Desktop, ChatGPT, Cursor, and any MCP-compatible client to your workspace. The assistant can list status pages, create and resolve status reports, and schedule maintenance windows. Every publishing tool requires the assistant to explicitly choose whether to notify subscribers, and every call is recorded in the audit log." - question: "Can I manage monitors as code?" answer: "Yes. Openstatus offers two ways to treat monitoring as code: a CLI with YAML config that lives in your repo (`openstatus monitors apply`), and a Terraform provider for HCL-managed infrastructure. Run `openstatus terraform generate` from the CLI to bootstrap an HCL file from an existing workspace." --- @@ -245,7 +245,7 @@ Every action in the dashboard β€” managing monitors, status pages, status report Yes. Openstatus ships a remote [MCP server](/tooling/mcp-server) at `api.openstatus.dev/mcp` that connects **Claude Desktop**, **ChatGPT**, **Cursor**, and any [Model Context Protocol](https://modelcontextprotocol.io) client to your workspace. -The assistant can list status pages, create and resolve status reports, and schedule maintenance windows. Every mutation tool requires the assistant to explicitly choose whether to notify subscribers β€” models can't quietly fan out an alert β€” and every call is recorded in the audit log under `actor_type = 'mcp'`. +The assistant can list status pages, create and resolve status reports, and schedule maintenance windows. Every publishing tool requires the assistant to explicitly choose whether to notify subscribers β€” models can't quietly fan out an alert β€” and every call is recorded in the audit log under `actor_type = 'mcp'`. diff --git a/apps/web/src/content/pages/product/status-page.mdx b/apps/web/src/content/pages/product/status-page.mdx index ed81b987..de9e9b46 100644 --- a/apps/web/src/content/pages/product/status-page.mdx +++ b/apps/web/src/content/pages/product/status-page.mdx @@ -15,7 +15,7 @@ faq: - question: "What's the difference between monitors and external services in page components?" answer: "Monitors are automatically synced with your OpenStatus uptime monitoring data and update in real-time. External services are manually managed components for third-party dependencies or systems you don't directly monitor but want to report status for." - question: "Can I translate my status page into other languages?" - answer: "Yes, status pages support multiple languages (currently English, French, and German). You can set a default locale and enable a locale switcher so visitors choose their preferred language. Translations are open source β€” you can contribute new languages by adding a locale to the shared registry and running the dev server to generate the translation file." + answer: "Yes, status pages support multiple languages (currently English, French, German, Turkish, Hindi, and Korean). You can set a default locale and enable a locale switcher so visitors choose their preferred language. Translations are open source β€” you can contribute new languages by adding a locale to the shared registry and running the dev server to generate the translation file." - question: "Can I use my own domain for the status page?" answer: "Yes, you can configure custom domains to host your status page on your own domain (e.g., status.yourcompany.com) instead of the default OpenStatus subdomain. This keeps the experience consistent with your brand." - question: "How do status page subscriptions work?" @@ -106,7 +106,7 @@ We support following communication channels: ### Translations -Offer your status page in **multiple languages**. Set a default locale and enable a **locale switcher** so visitors can read updates in their preferred language. Currently supports English, French, and German β€” with more languages coming from community contributions. +Offer your status page in **multiple languages**. Set a default locale and enable a **locale switcher** so visitors can read updates in their preferred language. Currently supports English, French, German, Turkish, Hindi, and Korean β€” with more languages coming from community contributions. ### Audience @@ -128,3 +128,65 @@ The agent is **thread-aware**: when you follow up in the same thread (_"we found Already using Atlassian Statuspage, Better Stack, or Instatus? Import your entire setup -- components, component groups, incidents, maintenances, subscribers, and monitors -- in minutes. Open a status page, go to the **Components** tab, scroll down to the **Import** section, paste your API key, preview what will be imported, and confirm. Read the [migration guides](/blog/import-from-statuspage-betterstack-instatus) for details on each provider. + +## Frequently asked questions + +
+ +A status page is a dedicated webpage where companies communicate the real-time health of their services to users. It shows which systems are operational, degraded, or experiencing outages, and provides timestamped incident updates. Status pages reduce support tickets during incidents, build user trust through transparency, and satisfy compliance requirements like SOC 2. + +
+ +
+ +Use public status pages for customer-facing services where transparency builds trust. Use private status pages (password-protected, magic link, or IP-restricted) for internal tools, client-specific deployments, or when you need to control who receives status updates. + +
+ +
+ +Monitors are automatically synced with your OpenStatus uptime monitoring data and update in real-time. External services are manually managed components for third-party dependencies or systems you don't directly monitor but want to report status for. + +
+ +
+ +Yes, status pages support multiple languages (currently English, French, German, Turkish, Hindi, and Korean). You can set a default locale and enable a locale switcher so visitors choose their preferred language. Translations are open source β€” you can contribute new languages by adding a locale to the shared registry and running the dev server to generate the translation file. + +
+ +
+ +Yes, you can configure custom domains to host your status page on your own domain (e.g., status.yourcompany.com) instead of the default OpenStatus subdomain. This keeps the experience consistent with your brand. + +
+ +
+ +Users can subscribe to receive updates when you post status reports or maintenance notices. We support email notifications, RSS/Atom feeds for feed readers, and JSON feeds for programmatic consumption. Subscribers are automatically notified when you publish updates. + +
+ +
+ +Yes, use the Theme Store to apply community themes or create your own. Themes control colors, fonts, and layout. For private custom themes, contact us. You can also define which data to share (uptime percentages, response times, or manual reports only). + +
+ +
+ +The Slack agent lets you manage your status page directly from Slack using natural language. @mention @openstatus in any channel or thread to create incidents, post updates, and resolve reports β€” without leaving Slack. No slash commands required. + +
+ +
+ +No. The agent always shows a confirmation card before publishing anything. You can review the drafted title, status, and message, then choose to Approve, Approve & Notify (sends notifications to all subscribers), or Cancel. Nothing goes public without your explicit approval. + +
+ +
+ +The Slack agent is available on paid plans. Install it from your dashboard under Settings > Integrations. + +
diff --git a/apps/web/src/content/pages/product/tooling/api.mdx b/apps/web/src/content/pages/product/tooling/api.mdx index c1909cdb..09457cf9 100644 --- a/apps/web/src/content/pages/product/tooling/api.mdx +++ b/apps/web/src/content/pages/product/tooling/api.mdx @@ -69,3 +69,29 @@ Every mutation lands in the audit log under `actor_type = 'api'`, so you can tra ## Reference Full schema and methods in the [API reference](https://api.openstatus.dev/openapi). SDK docs at [jsr.io/@openstatus/sdk-node](https://jsr.io/@openstatus/sdk-node). + +## Frequently asked questions + +
+ +Use the Node SDK if you're writing TypeScript or JavaScript β€” it handles auth, retries, and types for every endpoint. Call the API directly via curl or your language's HTTP client if you're outside the JS ecosystem; ConnectRPC means responses are plain JSON over HTTP. + +
+ +
+ +It's ConnectRPC β€” JSON over HTTP, but with a typed RPC contract instead of REST conventions. Every method is a POST to `/rpc/openstatus.v1./`. You can call it from curl exactly like you'd call a REST endpoint. + +
+ +
+ +Pass the x-openstatus-key header on every request. Generate a key from Settings β†’ API Tokens β€” the same key works for the CLI, Terraform provider, and MCP server. + +
+ +
+ +Yes. The full schema is browsable at api.openstatus.dev/openapi and is the source of truth for the Node SDK and any generated clients. + +
diff --git a/apps/web/src/content/pages/product/tooling/cli.mdx b/apps/web/src/content/pages/product/tooling/cli.mdx index 5572d504..0355647d 100644 --- a/apps/web/src/content/pages/product/tooling/cli.mdx +++ b/apps/web/src/content/pages/product/tooling/cli.mdx @@ -71,3 +71,29 @@ Every mutation lands in the audit log under `actor_type = 'cli'`, so you can tra ## Reference Full command list and flags in the [CLI reference](https://www.openstatus.dev/docs/reference/cli-reference/). + +## Frequently asked questions + +
+ +Yes. Every command supports --json output and structured errors, and required flags fail with a clear list of what's missing instead of hanging in a wizard. Combined with our agent skills, the CLI is the recommended way to give AI agents scriptable control over openstatus. + +
+ +
+ +Yes. Set `OPENSTATUS_API_TOKEN`, use the `--json` flag for parseable output, and run `openstatus monitors apply` to sync your YAML config. We also publish a GitHub Action that wraps the CLI for synthetic tests. + +
+ +
+ +Both treat monitoring as code. The YAML config is lighter to adopt and lives next to your repo. Terraform is the right choice when monitors are part of a larger HCL-managed infrastructure. Run `openstatus terraform generate` to bootstrap an HCL file from your existing workspace if you want to migrate. + +
+ +
+ +Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows. + +
diff --git a/apps/web/src/content/pages/product/tooling/mcp-server.mdx b/apps/web/src/content/pages/product/tooling/mcp-server.mdx index 6ef68718..9126c238 100644 --- a/apps/web/src/content/pages/product/tooling/mcp-server.mdx +++ b/apps/web/src/content/pages/product/tooling/mcp-server.mdx @@ -6,7 +6,7 @@ description: "Connect Claude, ChatGPT, Cursor, and any other Model Context Proto category: "Product" faq: - question: "What does the MCP server let an assistant do?" - answer: "The MCP server exposes 17 read and write tools scoped to your workspace: list status pages, monitors, response logs, notifications, and audit logs; inspect a single monitor or response log; create, update, and resolve status reports; schedule maintenance windows. Every mutation writes to the audit log, and publishing tools require an explicit notify decision." + answer: "The MCP server exposes 19 read and write tools scoped to your workspace: list status pages, monitors, response logs, notifications, private locations, and audit logs; inspect a single monitor or response log; create, update, and resolve status reports; schedule maintenance windows. Every mutation writes to the audit log, and publishing tools require an explicit notify decision." - question: "Are skills different from the MCP server?" answer: "Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows." - question: "Do I need a separate MCP credential?" @@ -37,7 +37,7 @@ Drop the snippet into your client's MCP config (`claude_desktop_config.json`, Cu ## What you can do -The server exposes **18 tools** scoped to your workspace, grouped by entity: +The server exposes **19 tools** scoped to your workspace, grouped by entity: - **Status pages** β€” `list_status_pages` Β· `list_page_components` - **Status reports** β€” `list_status_reports` Β· `create_status_report` Β· `add_status_report_update` Β· `update_status_report` Β· `resolve_status_report` @@ -45,6 +45,7 @@ The server exposes **18 tools** scoped to your workspace, grouped by entity: - **Monitors** β€” `list_monitors` Β· `get_monitor` Β· `get_monitor_status` Β· `get_monitor_summary` - **Response logs** β€” `list_response_logs` Β· `get_response_log` - **Notifications** β€” `list_notifications` +- **Private locations** β€” `list_private_locations` - **Audit log** *(workspaces on the audit-log plan only)* β€” `list_audit_logs` Β· `get_audit_log` The four **publishing** tools (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`) require `notify: true | false` β€” the assistant must explicitly choose whether to notify subscribers, so an LLM cannot quietly fan out an alert. `update_status_report` is metadata-only and cannot notify. @@ -69,3 +70,29 @@ Every mutation lands in the audit log under `actor_type = 'mcp'`, so you can tra ## Reference Full tool schema, error codes, and per-client config in the [MCP reference](https://www.openstatus.dev/docs/reference/mcp-server/). + +## Frequently asked questions + +
+ +The MCP server exposes 19 read and write tools scoped to your workspace: list status pages, monitors, response logs, notifications, private locations, and audit logs; inspect a single monitor or response log; create, update, and resolve status reports; schedule maintenance windows. Every mutation writes to the audit log, and publishing tools require an explicit notify decision. + +
+ +
+ +Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows. + +
+ +
+ +No. We don't implement the MCP OAuth flow β€” there's no consent screen and no extra credential to manage. Authentication is the x-openstatus-key header, the same key the CLI, API, and Terraform use. + +
+ +
+ +No. Every publishing tool requires the assistant to set notify: true | false explicitly β€” there's no default. Metadata-only edits like update_status_report can't notify at all. Every call lands in the audit log under actor_type = 'mcp', so you can see exactly what happened. + +
diff --git a/apps/web/src/content/pages/product/tooling/terraform.mdx b/apps/web/src/content/pages/product/tooling/terraform.mdx index 17a23c6d..410a8dcf 100644 --- a/apps/web/src/content/pages/product/tooling/terraform.mdx +++ b/apps/web/src/content/pages/product/tooling/terraform.mdx @@ -75,3 +75,29 @@ Every mutation through the provider lands in the audit log under `actor_type = ' ## Reference Full resource list and schema in the [Terraform reference](https://www.openstatus.dev/docs/reference/terraform/). + +## Frequently asked questions + +
+ +The Terraform provider is the right choice if monitoring is part of a larger HCL-managed infrastructure. The CLI's YAML config is lighter to adopt and ships with openstatus terraform generate to bootstrap an HCL file from your existing workspace if you want to migrate. + +
+ +
+ +Monitors, notification channels, status pages, status page subscribers, and maintenance windows β€” every primary entity in the dashboard. See the Terraform reference for the full list and schema. + +
+ +
+ +Run openstatus terraform generate from the CLI. It fetches your full configuration and produces valid HCL with cross-references and import blocks β€” no hand-writing required. + +
+ +
+ +Generate one from Settings β†’ API Tokens, then set `OPENSTATUS_API_TOKEN` before running terraform plan. The same token works across the CLI, API, and MCP server. + +
diff --git a/apps/web/src/content/pages/product/uptime-monitoring.mdx b/apps/web/src/content/pages/product/uptime-monitoring.mdx index d034df78..3c9b5980 100644 --- a/apps/web/src/content/pages/product/uptime-monitoring.mdx +++ b/apps/web/src/content/pages/product/uptime-monitoring.mdx @@ -203,6 +203,56 @@ You can read more here: +## Frequently asked questions + +
+ +Start with 3-5 regions covering your main user geographies. More regions provide better global coverage but use more check quota. For critical services, monitor from all major regions (North America, Europe, Asia) to catch regional issues quickly. + +
+ +
+ +If your service runs on AWS and your monitoring also runs on AWS, you won't detect AWS-wide outages or network issues affecting AWS connectivity. Using Fly.io, Koyeb, and Railway ensures monitoring independence from your infrastructure provider. + +
+ +
+ +Frequency determines how often we check your service (e.g., every 30 seconds, 1 minute, 5 minutes, 10 minutes). Higher frequency (30s) catches issues faster but uses more checks. Lower frequency (10m) is sufficient for non-critical services and conserves quota. + +
+ +
+ +Yes, you can configure monitors to automatically update your status page based on monitoring results. When assertions fail or thresholds are exceeded, the status page can reflect degraded or down status without manual intervention. + +
+ +
+ +Assertions validate response correctness (status code, headers, body content) while thresholds define performance boundaries (degraded latency, timeout). Both can trigger alerts - assertions catch functional failures, thresholds catch performance degradation. + +
+ +
+ +You can monitor any HTTP/HTTPS endpoint including REST APIs, GraphQL APIs, webhooks, and third-party service endpoints. Openstatus supports all HTTP methods (GET, POST, PUT, DELETE, etc.) and custom headers for authentication. + +
+ +
+ +Use YAML + CLI for simplicity and if you're not already using Terraform. It's lightweight and easy to get started. Choose Terraform if you're managing infrastructure as code and want to integrate monitoring into your existing Terraform workflows for unified state management. + +
+ +
+ +Yes, you can deploy as many private location probes as needed across different networks, VPCs, or regions. Each gets its own API key and appears as a separate monitoring region in your dashboard. The Docker image is only 8.5MB and supports ARM64 and AMD64. + +
+ --- Check your website's latency diff --git a/apps/web/src/content/pages/tools/cdn-checker.mdx b/apps/web/src/content/pages/tools/cdn-checker.mdx index daf70124..28dc2480 100644 --- a/apps/web/src/content/pages/tools/cdn-checker.mdx +++ b/apps/web/src/content/pages/tools/cdn-checker.mdx @@ -97,3 +97,29 @@ With OpenStatus, you can: - Monitor cache status continuously with header assertions and get alerted when caching breaks. If you'd like to request additional test regions or providers, feel free to contact us at [ping@openstatus.dev](mailto:ping@openstatus.dev). + +## Frequently asked questions + +
+ +A CDN cache checker tests whether your CDN is serving content from its edge cache instead of your origin server. OpenStatus requests your URL from 28 regions worldwide and reads the cache headers (cf-cache-status, x-cache, x-vercel-cache, age) to report HIT, MISS, EXPIRED, STALE, BYPASS or DYNAMIC per region. + +
+ +
+ +CDN caches are regional: each edge location keeps its own copy. A MISS in a region usually means no user has requested the asset from that edge recently, the TTL expired, or your cache rules exclude it. The first request from a region is always a MISS β€” run the check again to confirm whether the edge cached the response. + +
+ +
+ +CDNs add identifying response headers. Cloudflare adds cf-ray and cf-cache-status, Amazon CloudFront adds x-amz-cf-id and x-amz-cf-pop, Fastly adds x-served-by, Vercel adds x-vercel-id. The CDN Cache Checker fingerprints these headers automatically and shows the detected provider. + +
+ +
+ +With anycast, every edge location announces the same IP address and the network routes users to the nearest one. With unicast or GeoDNS, DNS hands out different IP addresses per region. Anycast typically fails over faster; GeoDNS gives the provider more routing control. The checker infers the topology from the responses. + +
diff --git a/apps/web/src/content/pages/tools/checker-slug.mdx b/apps/web/src/content/pages/tools/checker-slug.mdx index b0f8fccd..31765b12 100644 --- a/apps/web/src/content/pages/tools/checker-slug.mdx +++ b/apps/web/src/content/pages/tools/checker-slug.mdx @@ -14,3 +14,11 @@ The data is getting stored for **7 days**. If you want to keep it longer, consid --- > **We have reworked the checker experience ([go back to v1](https://v1.openstatus.dev/play/checker))**. Please let us know if you are missing a feature from the older version. Contact us directly or send us a message to [ping@openstatus.dev](mailto:ping@openstatus.dev). Happy to bring stuff back! + +## Frequently asked questions + +
+ +The data is stored for 7 days. If you want to keep it longer, consider creating an account at https://app.openstatus.dev and use the cloud solution. + +
diff --git a/apps/web/src/content/pages/tools/checker.mdx b/apps/web/src/content/pages/tools/checker.mdx index 161f0965..ce24e296 100644 --- a/apps/web/src/content/pages/tools/checker.mdx +++ b/apps/web/src/content/pages/tools/checker.mdx @@ -2,18 +2,39 @@ title: "Global Speed Checker" publishedAt: "2025-11-10" author: "Thibault Le Ouay Ducasse" -description: "Free website speed checker. Test your site's load time and latency from multiple regions across the globe in seconds - no signup required." +description: "Free website speed test. Check your site's load time and response time from 28 regions worldwide in seconds - no signup, no install required." category: "Product" hero: Website Speed Test - Check Load Time Worldwide -seo: - title: Website Speed Test - Check Load Time Worldwide +seo: + title: "Website Speed Test - Check Load Time from 28 Global Regions" +howto: + totalTime: "PT20S" + steps: + - name: "Enter your URL" + text: "Paste the full URL you want to test, including the scheme - https://example.com. Any public HTTP endpoint works, whether it serves a web page or a JSON API." + url: "#how-to-test-your-website-speed" + - name: "Run the speed test" + text: "openstatus sends one request from each of its 28 regions in parallel. The whole run takes about 20 seconds, bounded by the slowest region rather than the sum of all of them." + url: "#how-to-test-your-website-speed" + - name: "Read the per-region results" + text: "Each row is one region, sorted by total response time. Click a row to expand the timing phases - DNS, TCP connection, TLS handshake, TTFB, and transfer - plus the response headers and status code." + url: "#how-to-test-your-website-speed" + - name: "Compare regions and share" + text: "Look for regions several times slower than your fastest, which usually points at missing CDN coverage or a single-region origin. Share the result with a link that expires after 7 days." + url: "#how-to-test-your-website-speed" faq: - question: "What Is a Website Speed Checker?" answer: "A Website Speed Checker is an online tool that measures how fast your website or API responds when someone visits it. It analyzes various website performance metrics including client-side performance (FCP, LCP, CLS) and server-side performance (DNS lookup, TCP connection, TLS handshake, server response time)." - question: "What Is a Global Speed Checker?" - answer: "A Global Speed Checker measures your website or API's latency and response time from multiple locations around the world. OpenStatus runs checks from 28 global regions across 3 cloud providers, giving you a complete picture of your site's real-world performance." + answer: "A Global Speed Checker measures your website or API's latency and response time from multiple locations around the world. openstatus runs checks from 28 global regions across 3 cloud providers, giving you a complete picture of your site's real-world performance." - question: "What can I do with openstatus Global Speed Checker?" answer: "You can test how fast your API or website responds worldwide, compare latency across different regions, identify network bottlenecks, and monitor uptime and availability in real time from distributed locations across Europe, Asia, North America, and beyond." + - question: "What is a good website load time?" + answer: "For the server-side response this tool measures, under 200ms is fast, 200-500ms is acceptable, 500ms-1s is slow enough that users notice, and over 1s needs attention. Judge it per region rather than on the average - a site that answers in 80ms from Frankfurt and 900ms from Sydney has a distribution problem, not a speed problem." + - question: "How many regions does the speed test run from?" + answer: "28 regions across 3 cloud providers - 18 on Fly, 6 on Koyeb, and 4 on Railway - spanning Europe, North America, Asia, South America, Africa, and Oceania. Every region runs on each test, so you get the full spread rather than a sample." + - question: "Why is my website fast in one region and slow in another?" + answer: "Almost always because the request is travelling to a single origin. A visitor in Sydney hitting a server in Virginia pays roughly 200ms in round-trip time before your application does any work. Large gaps between your fastest and slowest region point at missing CDN coverage, no edge caching, or a single-region database." --- ## Start monitoring your services @@ -56,9 +77,62 @@ Understanding both sides helps you identify whether slowdowns are caused by your A Global Speed Checker measures your website or API's latency and response time from multiple locations around the world. Instead of testing from just one data center, it runs checks from 28 global regions across 3 cloud providers, giving you a complete picture of your site's real-world performance. +## How to Test Your Website Speed + +1. **Enter your URL.** Paste the full address including the scheme β€” `https://example.com`. Any public HTTP endpoint works, whether it serves a web page or a JSON API. +2. **Run the speed test.** openstatus sends one request from each of its 28 regions in parallel. The run takes about 20 seconds, bounded by the slowest region rather than the sum of all of them. +3. **Read the per-region results.** Each row is one region, sorted by total response time. Click a row to expand the timing phases β€” DNS, TCP connection, TLS handshake, TTFB, and transfer β€” along with the response headers and status code. +4. **Compare regions and share.** Look for regions several times slower than your fastest. Share the result with a link that expires after 7 days. + +No account, no install, and nothing to configure. If you want the same check to keep running after you close the tab, that is [uptime monitoring](/uptime-monitoring) rather than a one-off test. + +## What a Good Website Load Time Looks Like + +This tool measures **server-side** load time β€” how long your infrastructure takes to answer, not how long a browser takes to paint the page. Read your result against these bands: + +| Response time | Verdict | What it usually means | +| --- | --- | --- | +| Under 200ms | Fast | Served from an edge or a nearby origin. Nothing to fix. | +| 200–500ms | Acceptable | Normal for a single-region origin answering a distant request. | +| 500ms–1s | Slow | Users notice this. Usually an origin round trip plus unoptimised work per request. | +| Over 1s | Needs attention | Something is wrong β€” cold starts, an N+1 query, or no caching anywhere in the path. | + +The important number is not the average β€” it is the **spread**. A site answering in 80ms from Frankfurt and 900ms from Sydney does not have a speed problem, it has a distribution problem, and the fix is a CDN or an edge deployment rather than a faster server. + +Browser metrics like LCP, INP, and CLS are a separate question. They measure rendering, and they sit downstream of the numbers here β€” a slow server makes every one of them worse, but a fast server does not guarantee they are good. + +For the target numbers on both halves β€” server response bands, Core Web Vitals thresholds, and why to judge them at the 75th percentile rather than the average β€” see [what is a good response time](/guides/what-is-a-good-response-time). + +## Where the Speed Test Runs From + +All 28 regions run on every test, so you see the full spread rather than a sample: + +| Continent | Regions | Locations | +| --- | --- | --- | +| North America | 11 | Ashburn, Chicago, Dallas, Los Angeles, San Francisco, San Jose, Secaucus, Toronto, Washington, California, Virginia | +| Europe | 8 | Amsterdam Γ—2, Frankfurt Γ—2, Paris Γ—2, London, Stockholm | +| Asia | 6 | Singapore Γ—3, Tokyo Γ—2, Mumbai | +| South America | 1 | SΓ£o Paulo | +| Africa | 1 | Johannesburg | +| Oceania | 1 | Sydney | + +Several cities appear more than once because they are covered by different cloud providers β€” 18 regions run on Fly, 6 on Koyeb, and 4 on Railway. Testing the same city across providers is often how you tell a network problem apart from a provider problem. + +## How We Measure + +Each region opens its own connection and records the request in phases rather than as a single number: + +- **DNS** β€” resolving the hostname. A slow figure here is a nameserver or TTL problem, not an application one. +- **TCP connect** β€” the round trip to open the socket. This is mostly distance, and it is the number a CDN improves. +- **TLS handshake** β€” negotiating HTTPS. Usually one extra round trip, more if the certificate chain is long. +- **TTFB** β€” time to first byte, from request sent to the first byte back. This is where your application's own work shows up. +- **Transfer** β€” streaming the rest of the response body. + +Two caveats worth knowing. Connections are not reused between runs, so every test pays full DNS, TCP, and TLS cost β€” closer to a first-time visitor than a returning one. And each region contributes a single sample, which is enough to compare regions against each other but not enough to establish a baseline. Latency moves with traffic, deploys, and time of day, so one number from one moment is a snapshot, not a trend. + --- -With OpenStatus, you can: +With openstatus, you can: - Test how fast your API or website responds worldwide. - Compare latency across different regions. @@ -67,4 +141,53 @@ With OpenStatus, you can: Whether you want to test your website speed from Europe, Asia, North America, or beyond, our Global Speed Checker gives accurate, consistent data from distributed locations. +### Keep testing after the tab closes + +This page runs one test, right now. A single sample tells you very little about a +slow endpoint β€” latency moves with traffic, deploys, and time of day. +[openstatus uptime monitoring](/uptime-monitoring) re-runs this exact check on a +schedule from the same 28 regions, keeps the history, and alerts you when response +time degrades rather than when the site is already down. + +For the vocabulary behind the numbers above, see +[latency vs response time](/docs/concept/latency-vs-response-time). + If you'd like to request additional test regions or providers, feel free to contact us at [ping@openstatus.dev](mailto:ping@openstatus.dev). + +## Frequently asked questions + +
+ +A Website Speed Checker is an online tool that measures how fast your website or API responds when someone visits it. It analyzes various website performance metrics including client-side performance (FCP, LCP, CLS) and server-side performance (DNS lookup, TCP connection, TLS handshake, server response time). + +
+ +
+ +A Global Speed Checker measures your website or API's latency and response time from multiple locations around the world. openstatus runs checks from 28 global regions across 3 cloud providers, giving you a complete picture of your site's real-world performance. + +
+ +
+ +You can test how fast your API or website responds worldwide, compare latency across different regions, identify network bottlenecks, and monitor uptime and availability in real time from distributed locations across Europe, Asia, North America, and beyond. + +
+ +
+ +For the server-side response this tool measures, under 200ms is fast, 200-500ms is acceptable, 500ms-1s is slow enough that users notice, and over 1s needs attention. Judge it per region rather than on the average - a site that answers in 80ms from Frankfurt and 900ms from Sydney has a distribution problem, not a speed problem. + +
+ +
+ +28 regions across 3 cloud providers - 18 on Fly, 6 on Koyeb, and 4 on Railway - spanning Europe, North America, Asia, South America, Africa, and Oceania. Every region runs on each test, so you get the full spread rather than a sample. + +
+ +
+ +Almost always because the request is travelling to a single origin. A visitor in Sydney hitting a server in Virginia pays roughly 200ms in round-trip time before your application does any work. Large gaps between your fastest and slowest region point at missing CDN coverage, no edge caching, or a single-region database. + +
diff --git a/apps/web/src/content/pages/tools/curl.mdx b/apps/web/src/content/pages/tools/curl.mdx index ea814ce5..70717d78 100644 --- a/apps/web/src/content/pages/tools/curl.mdx +++ b/apps/web/src/content/pages/tools/curl.mdx @@ -17,3 +17,15 @@ faq: cURL (Client URL) is a command-line tool and library for transferring data with URLs. It supports various protocols like HTTP, HTTPS, FTP, and more, making it a versatile choice for testing APIs, downloading files, or performing network tasks. Its simplicity and power come from the ability to execute complex operations through straightforward commands. cURL is available on most operating systems, including Linux, macOS, and Windows. + +## From a one-off request to continuous monitoring + +A curl command tells you what an endpoint did once, from wherever you happen to be +sitting. If you need to know it keeps working β€” and to hear about it the moment it +stops β€” [openstatus uptime monitoring](/uptime-monitoring) runs the same request on +a schedule from 28 regions and alerts you when the status code, response body, or +latency drifts. + +Want the timing breakdown rather than the command? Drop the same URL into the +[Global Speed Checker](/play/checker) to see DNS, TCP, TLS, and TTFB split out per +region. diff --git a/apps/web/src/content/pages/tools/mcp-health.mdx b/apps/web/src/content/pages/tools/mcp-health.mdx index 467d599b..ac61af3e 100644 --- a/apps/web/src/content/pages/tools/mcp-health.mdx +++ b/apps/web/src/content/pages/tools/mcp-health.mdx @@ -73,6 +73,8 @@ A status-code pinger checks one thing: did the URL return 200? An MCP server can The handshake also captures the negotiated protocol version, which is the only reliable signal that an MCP server upgrade hasn't silently changed behaviour. If your server claims `2025-06-18` today and `2025-09-01` next week, you want to know before your users do. +Which is the argument for not running this by hand. [openstatus uptime monitoring](/uptime-monitoring) runs the same JSON-RPC handshake on a schedule from 28 regions and alerts you when `initialize` starts failing, `tools/list` comes back empty, or the protocol version shifts under you β€” the failures your AI clients hit first and report last. + ## Common failure modes - **Connection refused / DNS** β€” the URL is wrong, the server is down, or your firewall is in the way. diff --git a/apps/web/src/content/pages/tools/severity-matrix.mdx b/apps/web/src/content/pages/tools/severity-matrix.mdx index 27859074..88e4a735 100644 --- a/apps/web/src/content/pages/tools/severity-matrix.mdx +++ b/apps/web/src/content/pages/tools/severity-matrix.mdx @@ -78,3 +78,47 @@ Partial degradation with limited user impact. Standard incident process applies. Minor bug or cosmetic issue affecting a small percentage of users. Non-urgent resolution on a 1 business day timeline. Typically no public status page update is needed. Postmortem is optional. See the [Incident Severity Matrix Template](/guides/incident-severity-matrix) for per-severity status page message templates, postmortem requirements, real-world examples, and tips. + +## Frequently asked questions + +
+ +SEV0 indicates a critical incident β€” typically a complete service outage or confirmed security breach that requires immediate response from senior engineering leadership. It's the highest severity level and triggers the most aggressive communication and escalation protocols. + +
+ +
+ +Most teams use 3 or 4 levels. Four levels (SEV0 through SEV3) provide enough granularity to distinguish between a full outage and a minor cosmetic bug without overcomplicating triage during a live incident. If you're a small team, 3 levels can work fine β€” you can always add granularity later. + +
+ +
+ +Severity measures the impact of an incident β€” how many users are affected and how badly. Priority reflects business urgency and resource allocation. A typo on your pricing page might be low severity but high priority if it's costing you conversions. Your severity matrix should classify based on impact alone; priority is a triage decision. + +
+ +
+ +In most cases, yes. Security incidents carry outsized risk even when few users are immediately affected β€” the blast radius can expand quickly and the reputational impact is disproportionate. Treating all confirmed security incidents as SEV0 ensures you mobilize the right resources immediately. + +
+ +
+ +Review it quarterly, or after any major incident where the classification felt wrong. If your team consistently debates whether something is a SEV1 or SEV2, your thresholds probably need adjustment. The builder lets you customize thresholds so your matrix reflects your team's actual operational patterns. + +
+ +
+ +Not by name, but functionally yes. SOC 2 criterion CC7.4 explicitly requires understanding the 'nature and severity' of an incident to determine the appropriate response time frame. Auditors doing a Type II audit will sample real incidents and check whether your severity classification was applied consistently. Without a documented matrix, that evidence trail doesn't exist. ISO 27001 Annex A 5.25 is even more explicit β€” it directly mandates categorisation and prioritisation of security events. + +
+ +
+ +Your severity levels determine how quickly you respond to incidents, which directly affects your cumulative downtime. If your SLA promises 99.9% uptime, you have roughly 8 hours and 46 minutes of allowed downtime per year. A single misclassified SEV0 treated as SEV2 could burn through that budget. + +
diff --git a/apps/web/src/content/pages/tools/uptime-sla.mdx b/apps/web/src/content/pages/tools/uptime-sla.mdx index 15650afc..75778345 100644 --- a/apps/web/src/content/pages/tools/uptime-sla.mdx +++ b/apps/web/src/content/pages/tools/uptime-sla.mdx @@ -16,8 +16,12 @@ faq: answer: "99.9% uptime (three nines) allows approximately 8 hours and 45 minutes of downtime per year, 43 minutes per month, 10 minutes per week, or 1 minute and 26 seconds per day." - question: "What is the difference between 99.9% and 99.99% uptime?" answer: "The difference is significant: 99.9% uptime allows about 8 hours 45 minutes of downtime per year, while 99.99% allows only about 52 minutes per year. That extra 9 reduces your allowed downtime by roughly 10x and typically requires redundant infrastructure and automated failover." - - question: "How do I calculate uptime from downtime?" - answer: "To calculate uptime percentage from downtime, use this formula: Uptime % = ((Total time - Downtime) / Total time) Γ— 100. For example, if your service was down for 1 hour in a 30-day month (720 hours), your uptime is ((720 - 1) / 720) Γ— 100 = 99.86%." + - question: "How is SLA uptime calculated?" + answer: "Uptime % = ((Total time βˆ’ Downtime) / Total time) Γ— 100. For example, if your service was down for 1 hour in a 30-day month (720 hours), your uptime is ((720 βˆ’ 1) / 720) Γ— 100 = 99.86%. The subtlety is what counts as downtime in the first place - partial degradation, a single failing region, or a slow-but-responding endpoint may or may not be chargeable depending on how your agreement defines availability." + - question: "What is a good SLA?" + answer: "For most SaaS products, 99.9% is the right public commitment - it allows 43 minutes of downtime a month, which is enough room to deploy, patch, and recover from an incident without writing refund cheques. 99.99% is a commitment to redundant infrastructure and automated failover, not just a bigger number, and you should only publish it once you can prove you already hit it. The best SLA is the one slightly below what you consistently achieve." + - question: "Is uptime measured monthly or yearly?" + answer: "Almost always monthly, because that is the billing period service credits attach to. The distinction matters: a single 5-hour outage is 99.94% over a year but only 99.3% over the month it happened in, so a yearly window can hide an outage that a monthly window turns into a breach. Check which window your agreement specifies before committing to a tier." --- _All calculations assume continuous 24/7 availability requirements._ @@ -31,3 +35,61 @@ Common SLA tiers include 99.9% (three nines), 99.99% (four nines), and 99.999% ( This calculator helps you understand the real-world impact of your SLA commitments and plan for capacity, incident response, and stakeholder expectations. + +## From an SLA target to a measured number + +A target is only half of it β€” the other half is measuring whether you hit it. Once +you have picked a tier, [openstatus uptime monitoring](/uptime-monitoring) tracks +the actual figure from 28 regions, and a [public status page](/status-page) reports +it back to the customers the SLA was written for. + +Not sure which number you are agreeing to? [SLA vs SLO vs SLI](/guides/sla-vs-slo-vs-sli) +covers why your internal target should be stricter than the promise you publish. + +## Frequently asked questions + +
+ +An uptime SLA (Service Level Agreement) is a commitment between a service provider and a customer that guarantees a specific percentage of uptime over a given period. For example, a 99.9% SLA means the service can be down for no more than 8 hours and 45 minutes per year. + +
+ +
+ +99.9% uptime (three nines) allows approximately 8 hours and 45 minutes of downtime per year, 43 minutes per month, 10 minutes per week, or 1 minute and 26 seconds per day. + +
+ +
+ +Uptime % = ((Total time βˆ’ Downtime) / Total time) Γ— 100. + +For example, if your service was down for 1 hour in a 30-day month (720 hours), your uptime is ((720 βˆ’ 1) / 720) Γ— 100 = 99.86%. The subtlety is what counts as downtime in the first place β€” partial degradation, a single failing region, or a slow-but-responding endpoint may or may not be chargeable depending on how your agreement defines availability. + +
+ +
+ +Common tiers are 99.9% (three nines) allowing 8h 45m of downtime a year, 99.99% (four nines) allowing 52m 35s a year, and 99.999% (five nines) allowing only 5m 15s a year. Most cloud providers publish between 99.9% and 99.99%. + +
+ +
+ +The difference is larger than one digit suggests: 99.9% allows about 8 hours 45 minutes of downtime per year, while 99.99% allows only about 52 minutes. That extra nine cuts your allowed downtime by roughly 10Γ—, and it usually requires redundant infrastructure and automated failover rather than simply more careful operations. + +
+ +
+ +For most SaaS products, 99.9% is the right public commitment. It allows 43 minutes of downtime a month β€” enough room to deploy, patch, and recover from an incident without writing refund cheques. 99.99% is a commitment to redundant infrastructure and automated failover, not just a bigger number, and you should only publish it once you can prove you already hit it. + +The best SLA is the one slightly below what you consistently achieve. See [SLA vs SLO vs SLI](/guides/sla-vs-slo-vs-sli) for how to set the internal target that gives you that margin. + +
+ +
+ +Almost always monthly, because that is the billing period service credits attach to. The distinction matters more than it looks: a single 5-hour outage is 99.94% measured over a year, but 99.3% measured over the month it happened in. A yearly window can hide an outage that a monthly window turns into a breach β€” check which one your agreement specifies before committing to a tier. + +
diff --git a/apps/web/src/content/pages/unrelated/about.mdx b/apps/web/src/content/pages/unrelated/about.mdx index 7b2a58c0..112063f4 100644 --- a/apps/web/src/content/pages/unrelated/about.mdx +++ b/apps/web/src/content/pages/unrelated/about.mdx @@ -56,3 +56,17 @@ We're **profitable and self-funded**. No VC pressure, no growth-at-all-costs. Th ## Our mission We're building the best open-source status page β€” connecting monitoring, incident communication, and compliance into a single platform. **Transparent by default**, for teams who believe their users deserve to know what's happening. + +## Frequently asked questions + +
+ +Openstatus is an open-source status page and uptime monitoring platform founded in 2023 by Thibault Le Ouay Ducasse and Maximilian Kaske. It monitors websites, APIs, and services from 28 regions globally across multiple cloud providers. Openstatus is bootstrapped, profitable, and available both as a managed SaaS and for self-hosting. + +
+ +
+ +We're self-funded because it keeps us aligned with our customers, not investors. No VC pressure means we build features that matter to you, not features that look good on a pitch deck. We'll be here when your next SOC 2 audit comes around. + +
diff --git a/apps/web/src/content/pages/use-case/agent.mdx b/apps/web/src/content/pages/use-case/agent.mdx index ae7f65cd..7150c5b2 100644 --- a/apps/web/src/content/pages/use-case/agent.mdx +++ b/apps/web/src/content/pages/use-case/agent.mdx @@ -158,6 +158,38 @@ Every status-report mutation requires the agent to choose whether to notify subs 5. **Review a week of proposed reports.** If they're good, upgrade the key to `write` and let it publish β€” starting with `notify_subscribers: false` 6. **Graduate to subscriber notifications** once you trust the diagnosis quality +## Frequently asked questions + +
+ +Openstatus ships a remote MCP (Model Context Protocol) server at api.openstatus.dev/mcp. It exposes typed tools for every workspace entity β€” monitors, response logs, status pages, page components, status reports, maintenance windows, notification channels, and audit logs. Any MCP-compatible client (Claude Desktop, ChatGPT, Cursor) or any agent built with the MCP SDK can connect with an openstatus API key. + +
+ +
+ +Configure a webhook notification channel on the monitor. When openstatus detects a failure, it posts a payload to your endpoint. Your agent runtime receives it, opens an MCP session against api.openstatus.dev/mcp using your workspace API key, and starts investigating with the tools below. + +
+ +
+ +The diagnostic loop uses get_monitor, get_monitor_status, get_monitor_summary, list_response_logs, and get_response_log. The communication loop uses list_status_pages, list_page_components, create_status_report, add_status_report_update, and resolve_status_report. The agent can also call list_audit_logs to see what humans or other agents already did. + +
+ +
+ +Yes β€” but every mutation tool requires the agent to explicitly decide whether to notify subscribers, and every call is recorded in the audit log with the agent's API key as the actor. Read-only keys can investigate but cannot publish. Most teams start with notify_subscribers set to false and a human approving the first version, then graduate to fully autonomous reports once the agent has a track record. + +
+ +
+ +Openstatus API keys carry scopes β€” read for investigation-only, write for mutations. Issue a read-only key for an agent that only diagnoses, or a write-scoped key for an agent that also files status reports. Scope enforcement happens before any DB lookup, so a read-only key never sees the write tools. + +
+ --- Stop writing status reports by hand. Let an agent run your status page. diff --git a/apps/web/src/content/pages/use-case/api-providers.mdx b/apps/web/src/content/pages/use-case/api-providers.mdx index ae6174d2..ddaf2008 100644 --- a/apps/web/src/content/pages/use-case/api-providers.mdx +++ b/apps/web/src/content/pages/use-case/api-providers.mdx @@ -57,6 +57,32 @@ Let your API consumers subscribe via **email**, **RSS/Atom**, or **JSON** feeds. Host on `status.yourapi.com`. Your consumers expect it. +## Frequently asked questions + +
+ +Your API consumers build their products on top of your infrastructure. When your API is down, their products are down. A public status page reduces support tickets, builds trust, and shows enterprise customers you take reliability seriously. + +
+ +
+ +Yes. You can create separate page components for each API endpoint or service. Group them by product area, region, or any logical structure. Each component shows its own uptime data independently. + +
+ +
+ +Yes. Define your monitors as YAML configuration and manage them with the openstatus CLI or Terraform provider. Version control your monitoring setup alongside your API code. + +
+ +
+ +Your consumers can subscribe via email, RSS/Atom feeds, or JSON feeds. Many API providers embed the JSON feed into their own dashboards to show upstream status to their users. + +
+ --- Give your API consumers the transparency they expect diff --git a/apps/web/src/content/pages/use-case/compliance.mdx b/apps/web/src/content/pages/use-case/compliance.mdx index 4815dbdc..75ea08eb 100644 --- a/apps/web/src/content/pages/use-case/compliance.mdx +++ b/apps/web/src/content/pages/use-case/compliance.mdx @@ -119,6 +119,38 @@ Article 19(3) requires informing clients where a major incident affects their fi Each guide maps the requirement to specific evidence, and is explicit about where a status page stops and your own process, procedures, and regulator filings begin. +## Frequently asked questions + +
+ +SOC 2's CC2.3 (Communication with external parties) requires you to demonstrate incident communication processes with external users β€” a mechanism to report failures, open communication channels, and documentation of how incidents are communicated. A status page with timestamped incident reports and subscriber notifications is the fastest way to satisfy this. + +
+ +
+ +No β€” SOC 2 CC2.3 requires you to demonstrate incident communication with external parties, but it doesn't prescribe a specific tool. You could use email notifications, a support portal, or other channels. That said, a status page is the fastest, most auditor-friendly way to satisfy the requirement and is increasingly considered standard practice. + +
+ +
+ +Every status report, update, and resolution is timestamped and stored. You get a full incident history showing when issues were detected, communicated, and resolved. Subscriber notification logs show you proactively informed stakeholders. This creates an auditable trail without manual documentation. + +
+ +
+ +Yes. openstatus handles the incident communication side of compliance while Vanta or Drata manage the broader audit automation. Your status page URL and incident history can be referenced in your compliance platform as evidence of your communication controls. + +
+ +
+ +You can have a branded status page with custom domain, incident history, and subscriber notifications live in under 10 minutes. That covers the incident communication side β€” CC2.3 and parts of CC7 β€” not your whole SOC 2 scope. Check that your plan's data retention spans your audit period: a Type II observation window runs 3 to 12 months. + +
+ --- Ready to check the compliance box? diff --git a/apps/web/src/content/pages/use-case/crypto.mdx b/apps/web/src/content/pages/use-case/crypto.mdx index fd1806b1..065fe2d4 100644 --- a/apps/web/src/content/pages/use-case/crypto.mdx +++ b/apps/web/src/content/pages/use-case/crypto.mdx @@ -47,6 +47,32 @@ Let users subscribe for email updates. When you push a status report, they're in Create private status pages for institutional partners or internal operations teams with **password protection** or **magic link authentication**. +## Frequently asked questions + +
+ +Downtime in crypto means lost trades and lost trust. A status page gives your users a single source of truth during incidents β€” reducing support tickets, preventing panic, and demonstrating operational maturity to institutional partners. + +
+ +
+ +Yes. Openstatus monitors any HTTP/HTTPS endpoint. You can monitor RPC nodes, REST APIs, WebSocket endpoints, and more with custom assertions to validate response correctness. + +
+ +
+ +Yes. Host your status page on your own domain (e.g., status.exchange.com) to maintain brand trust. Custom domains are available on paid plans. + +
+ +
+ +Yes. Use password protection or magic link authentication to create private status pages for institutional partners or internal teams. + +
+ --- Keep your users informed, not panicking diff --git a/apps/web/src/content/pages/use-case/enterprise-sales.mdx b/apps/web/src/content/pages/use-case/enterprise-sales.mdx index 49e1a906..b3c275ca 100644 --- a/apps/web/src/content/pages/use-case/enterprise-sales.mdx +++ b/apps/web/src/content/pages/use-case/enterprise-sales.mdx @@ -54,6 +54,32 @@ Create **password-protected status pages** for enterprise clients. Show only the Enterprise clients **subscribe via email** and get updates the moment something changes. No checking, no guessing, no "why didn't you tell us?" conversations. +## Frequently asked questions + +
+ +Increasingly, yes. Enterprise security and procurement teams evaluate vendor reliability as part of their due diligence. A public status page with uptime history, incident reports, and subscriber notifications demonstrates operational maturity. Many vendor questionnaires explicitly ask for a status page URL. + +
+ +
+ +Common questions include: How do you communicate incidents to customers? Do you have a public status page? How are customers notified of outages? What is your incident response process? A status page with subscriber notifications and timestamped incident history answers all of these. + +
+ +
+ +Yes. Use password protection to create private status pages for specific enterprise customers. Show them only the components and services relevant to their account. This gives them dedicated visibility without exposing your full infrastructure. + +
+ +
+ +Yes. Host your status page on your own domain (e.g., status.yourcompany.com) to maintain brand consistency. Enterprise buyers expect a professional, branded experience β€” not a third-party subdomain. + +
+ --- Make your status page the easiest checkbox in the vendor review diff --git a/apps/web/src/content/pages/use-case/open-source.mdx b/apps/web/src/content/pages/use-case/open-source.mdx index 967e1bae..e7fe6eeb 100644 --- a/apps/web/src/content/pages/use-case/open-source.mdx +++ b/apps/web/src/content/pages/use-case/open-source.mdx @@ -8,7 +8,7 @@ faq: - question: "Is openstatus free for open-source projects?" answer: "Yes. The free plan includes one monitor, one status page with three components, and monitoring from up to 6 regions. For larger projects, paid plans start at $30/month with 20 monitors and custom domains." - question: "Can I self-host openstatus?" - answer: "Yes. Openstatus is fully open source (MIT license) and can be self-hosted. The checker runs as an 8.5MB Docker image. You can also use the managed SaaS and keep the monitoring infrastructure off your plate." + answer: "Yes. Openstatus is fully open source (AGPL-3.0) and can be self-hosted. The checker runs as an 8.5MB Docker image. You can also use the managed SaaS and keep the monitoring infrastructure off your plate." - question: "How do open-source projects use openstatus?" answer: "Projects like Cal.com, Documenso, Hanko, and OpenPanel use openstatus to give their communities transparent uptime data. They monitor APIs and services, publish incidents, and let contributors and users subscribe for updates." - question: "Can contributors subscribe to status updates?" @@ -47,6 +47,32 @@ Let your users subscribe via **email**, **RSS/Atom**, or **JSON**. When you push Make your status page match your project's brand with [community themes](https://themes.openstatus.dev). Contribute your own theme back to the store. +## Frequently asked questions + +
+ +Yes. The free plan includes one monitor, one status page with three components, and monitoring from up to 6 regions. For larger projects, paid plans start at $30/month with 20 monitors and custom domains. + +
+ +
+ +Yes. Openstatus is fully open source (AGPL-3.0) and can be self-hosted. The checker runs as an 8.5MB Docker image. You can also use the managed SaaS and keep the monitoring infrastructure off your plate. + +
+ +
+ +Projects like Cal.com, Documenso, Hanko, and OpenPanel use openstatus to give their communities transparent uptime data. They monitor APIs and services, publish incidents, and let contributors and users subscribe for updates. + +
+ +
+ +Yes. Your community can subscribe via email, RSS/Atom feeds, or JSON feeds. When you publish a status report or schedule maintenance, subscribers are notified automatically. + +
+ --- Give your community the transparency they deserve diff --git a/apps/web/src/content/pages/use-case/reduce-support-tickets.mdx b/apps/web/src/content/pages/use-case/reduce-support-tickets.mdx index 912f70d1..f30a323c 100644 --- a/apps/web/src/content/pages/use-case/reduce-support-tickets.mdx +++ b/apps/web/src/content/pages/use-case/reduce-support-tickets.mdx @@ -49,6 +49,32 @@ Break your status page into **components** β€” API, dashboard, billing, webhooks Announce maintenance windows in advance. Subscribers are notified before the work begins β€” so the tickets that would have come in during the window never get created. +## Frequently asked questions + +
+ +When users can't reach your service, their first instinct is to contact support. A status page gives them an immediate answer β€” what's down, what's affected, and when it'll be fixed. Instead of filing a ticket, they check the status page, see the issue is acknowledged, and wait for updates. + +
+ +
+ +Post a status report as soon as you detect the issue. Include what's affected, the current severity, and your next update time. Update regularly β€” even if there's no progress, a 'still investigating' update is better than silence. Resolve the report when the issue is fixed. + +
+ +
+ +Yes. Users can subscribe to your status page via email, RSS/Atom, or JSON feeds. When you publish or update a status report, subscribers are notified automatically. You can also scope notifications to specific components so users only hear about services they care about. + +
+ +
+ +Use the JSON feed to pull your status page data into your own application or support portal. Many teams add a status banner or badge to their app so users see service health without leaving the product. + +
+ --- Stop answering "is it down?" during every outage diff --git a/apps/web/src/content/pages/use-case/startups.mdx b/apps/web/src/content/pages/use-case/startups.mdx index 5186862e..227f81ff 100644 --- a/apps/web/src/content/pages/use-case/startups.mdx +++ b/apps/web/src/content/pages/use-case/startups.mdx @@ -69,6 +69,44 @@ The entire codebase is public on [GitHub](https://github.com/openstatushq/openst Most teams finish in under 10 minutes. +## Frequently asked questions + +
+ +If you're selling to other businesses, yes. Enterprise prospects check for a status page during due diligence. SOC 2 auditors expect documented incident communication (CC2.3). And your first SLA agreement will likely require one. The question isn't whether you need it β€” it's whether you have one when someone asks. + +
+ +
+ +Most teams go from signup to a live, branded status page in under 10 minutes. Pick a theme, add your components, connect your custom domain, and you're done. No engineering work required. + +
+ +
+ +The free plan gives you 1 status page, 1 monitor, and incident reporting β€” enough to evaluate the product and see how it looks. When you need a custom domain, subscriber notifications, or more components, the Starter plan is $30/mo. + +
+ +
+ +Atlassian Statuspage starts at $79/mo, charges per subscriber, requires a separate monitoring tool, and takes time to configure. Openstatus is $30/mo flat with monitoring included, no per-subscriber fees, and a status page that looks better out of the box. It's built for startups, not enterprises with dedicated SRE teams. + +
+ +
+ +We're bootstrapped and profitable β€” no runway pressure, no risk of shutting down. Cal.com, Documenso, Midday, and other growing teams trust us. The codebase is open-source (AGPL-3.0), so you can inspect every line. + +
+ +
+ +Yes. Every incident report is timestamped and stored, and subscriber notifications are logged automatically. This satisfies SOC 2 CC2.3 (incident communication with external parties) without extra configuration. See our compliance use case for details. + +
+ --- Your enterprise prospect is going to ask. Be ready. -- 2.51.2