diff --git a/apps/web/src/app/(landing)/play/uptime-sla/page.tsx b/apps/web/src/app/(landing)/play/uptime-sla/page.tsx index 97afdce7..df5eb3c1 100644 --- a/apps/web/src/app/(landing)/play/uptime-sla/page.tsx +++ b/apps/web/src/app/(landing)/play/uptime-sla/page.tsx @@ -4,6 +4,7 @@ import { BASE_URL, getPageMetadata } from "@/lib/metadata/shared-metadata"; import { createJsonLDGraph, getJsonLDBreadcrumbList, + getJsonLDFAQPage, getJsonLDWebPage, } from "@/lib/metadata/structured-data"; import type { Metadata } from "next"; @@ -24,6 +25,7 @@ export default function Page() { { name: "Playground", url: `${BASE_URL}/play` }, { name: page.metadata.title, url: `${BASE_URL}/play/uptime-sla` }, ]), + getJsonLDFAQPage(page), ]); return ( 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 573d3ed2..787ae66e 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 @@ -1,20 +1,29 @@ --- -title: "Global Latency Monitoring: Benchmarking a Hono App on Hetzner with OpenStatus" -description: "Benchmarking network latency from global locations across Fly, Koyeb, and Railway to analyze the impact of distance and provider networks." +title: "Global Latency Monitoring: Benchmarking a Hono App on Hetzner with openstatus" +description: "We monitored a Hono app on Hetzner Finland from 17 global probes across Fly, Koyeb, and Railway for 7 days. Result: providers differ by less than 10% — geographic distance is what matters most." author: "Thibault Le Ouay Ducasse" publishedAt: "2025-10-23" image: "/assets/posts/global-latency-monitoring-benchmark-hono-hetzner/global.png" category: "engineering" +faq: + - question: "Does the cloud provider affect latency to Hetzner?" + answer: "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." + - question: "What is the latency from different regions to Hetzner Finland?" + answer: "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." + - question: "Should I pick Fly, Koyeb, or Railway based on network performance?" + answer: "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." + - question: "How do you benchmark global latency with openstatus?" + answer: "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." --- -At OpenStatus, we offer **global monitoring** to give you an unbiased, external view of your service's performance. To truly test our monitoring capabilities and gather real-world latency data, we decided to benchmark a simple application deployed outside our internal network. +At openstatus, we offer **global monitoring** to give you an unbiased, external view of your service's performance. To truly test our monitoring capabilities and gather real-world latency data, we decided to benchmark a simple application deployed outside our internal network. As a software developer, I know that **latency** is critical for user experience. When building an application, understanding how your app performs from different locations around the world is essential. ## The Benchmark Setup -To prevent internal networking biases from skewing the results, I deployed a minimal test application a [**Hono server**](https://github.com/openstatusHQ/status-code/) on third-party cloud providers, independent from OpenStatus's infrastructure. +To prevent internal networking biases from skewing the results, I deployed a minimal test application a [**Hono server**](https://github.com/openstatusHQ/status-code/) on third-party cloud providers, independent from openstatus's infrastructure. ### Why Hetzner? @@ -33,11 +42,11 @@ The test app is a single instance deployed in their **Finland datacenter**. /> -## Monitoring Strategy with OpenStatus +## Monitoring Strategy with openstatus The core of this experiment is to see how different cloud providers' network paths affect the latency to our Finland-based Hetzner app. -We've set up OpenStatus probes across multiple continents and providers, specifically leveraging monitoring locations from: +We've set up openstatus probes across multiple continents and providers, specifically leveraging monitoring locations from: - **Fly.io** - **Koyeb** @@ -46,7 +55,7 @@ We've set up OpenStatus probes across multiple continents and providers, specifi The goal is to monitor latency from similar geographic regions across these different providers to observe any network path variations. -### OpenStatus Probe Configuration +### openstatus Probe Configuration Our monitoring strategy is focused on diverse, yet regionally comparable, deployment regions: 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 1b96ad8c..ac8b41c2 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 @@ -1,10 +1,19 @@ --- title: "Monitoring latency: Cloudflare Workers vs Fly vs Koyeb vs Railway vs Render" -description: "" +description: "We benchmarked latency across 5 cloud providers from 6 global locations over 2 weeks. Cloudflare Workers averaged 182ms, Fly.io 61ms (warm), Railway 381ms, Koyeb 539ms, and Render 451ms. Full timing breakdowns included." author: "Thibault Le Ouay Ducasse" publishedAt: "2024-02-19" 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." + - 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?" + answer: "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." + - question: "Which cloud provider had the most downtime in the benchmark?" + answer: "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." --- > ⚠️ We are using the default settings for each provider and conducting 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 b068a9f4..a431da80 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 @@ -1,10 +1,19 @@ --- title: "Monitoring latency: Vercel Serverless Function vs Vercel Edge Function" -description: "" +description: "We benchmarked Vercel Edge vs Serverless functions from 6 global regions. Edge averaged 106ms (P50), Serverless warm 246ms, and Serverless cold 859ms. Edge is 9x faster on cold starts and 2x faster when warm." author: "Thibault Le Ouay Ducasse" publishedAt: "2024-03-14" image: "/assets/posts/monitoring-vercel/serverless-vs-edge.png" category: "education" +faq: + - question: "Is Vercel Edge faster than Vercel Serverless?" + answer: "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." + - question: "What is the cold start latency of Vercel Serverless functions?" + answer: "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." + - question: "Do Vercel Edge functions have cold starts?" + answer: "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)." + - question: "Where are Vercel Serverless functions deployed?" + answer: "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." --- In our previous diff --git a/apps/web/src/content/pages/compare/betterstack.mdx b/apps/web/src/content/pages/compare/betterstack.mdx index a95d4a83..dc3c2e8c 100644 --- a/apps/web/src/content/pages/compare/betterstack.mdx +++ b/apps/web/src/content/pages/compare/betterstack.mdx @@ -1,18 +1,20 @@ --- -title: "BetterStack Alternative" +title: "openstatus vs BetterStack — Feature & Pricing Comparison" publishedAt: "2025-11-10" author: "openstatus" -description: "Open-source uptime monitoring. Learn how openstatus compares to BetterStack." +description: "openstatus vs BetterStack compared side-by-side. 28 regions (parallel) vs 4 (round-robin), open-source vs closed-source, and transparent pricing with no add-on fees for status pages or subscribers." category: "company" faq: - question: "Is openstatus a good BetterStack alternative?" - answer: "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." + answer: "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." - question: "How does openstatus pricing compare to BetterStack?" - answer: "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." - - question: "Does openstatus support as many monitoring regions as BetterStack?" - answer: "Openstatus monitors from 28 regions worldwide. BetterStack uses approximately 4 regions. Openstatus also uses a parallel scheduling strategy — all selected regions fire simultaneously — whereas BetterStack uses round-robin scheduling." + answer: "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." + - question: "Does openstatus support more monitoring regions than BetterStack?" + answer: "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." - question: "Can I self-host openstatus instead of using the cloud service?" - answer: "Yes. Openstatus is open-source (AGPL-3.0 license) and fully self-hostable. BetterStack is a closed-source SaaS product with no self-hosting option." + answer: "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." + - question: "What is the difference between parallel and round-robin monitoring?" + answer: "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." --- Openstatus and BetterStack are both uptime monitoring platforms with status pages. Openstatus is open-source, bootstrapped, and built for teams that want global coverage and transparent pricing. BetterStack is a VC-backed, closed-source SaaS with a broader product suite including log management. diff --git a/apps/web/src/content/pages/compare/uptime-kuma.mdx b/apps/web/src/content/pages/compare/uptime-kuma.mdx index 6095ec25..ed993d03 100644 --- a/apps/web/src/content/pages/compare/uptime-kuma.mdx +++ b/apps/web/src/content/pages/compare/uptime-kuma.mdx @@ -1,18 +1,20 @@ --- -title: "Uptime Kuma Alternative" +title: "openstatus vs Uptime Kuma — Feature Comparison" publishedAt: "2025-11-10" author: "openstatus" -description: "Open-source uptime monitoring. Learn how openstatus compares to Uptime Kuma." +description: "openstatus vs Uptime Kuma compared side-by-side. Both open-source, but openstatus offers managed SaaS + 28-region global monitoring. Uptime Kuma is self-hosted only from 1 location." category: "company" faq: - question: "Is openstatus a good Uptime Kuma alternative?" answer: "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." - question: "What is the main difference between openstatus and Uptime Kuma?" - answer: "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." + answer: "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." - question: "Is openstatus free like Uptime Kuma?" - answer: "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." + answer: "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." - question: "Does openstatus support self-hosting like Uptime Kuma?" - answer: "Yes. Openstatus is AGPL-3.0-licensed and can be self-hosted. You also get the option to use the managed cloud service without managing any infrastructure." + 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." --- Openstatus and Uptime Kuma are both open-source uptime monitoring tools, making this a comparison between two projects with shared values but different architectures. The fundamental difference is the **hosting model**: Uptime Kuma is self-hosted only — you run it on your own server and it monitors from that single location. Openstatus is available both as a **managed SaaS** and for self-hosting, and checks from **28 regions worldwide**. diff --git a/apps/web/src/content/pages/tools/uptime-sla.mdx b/apps/web/src/content/pages/tools/uptime-sla.mdx index e6ff987f..1d6c07a2 100644 --- a/apps/web/src/content/pages/tools/uptime-sla.mdx +++ b/apps/web/src/content/pages/tools/uptime-sla.mdx @@ -1,14 +1,20 @@ --- -title: "Uptime SLA Calculator" +title: "Uptime SLA Calculator - Convert Uptime % to Downtime" publishedAt: "2025-11-10" author: "Thibault Le Ouay Ducasse" -description: "Calculate allowed downtime from uptime percentages or determine uptime percentages from actual downtime. Supports multiple reporting periods and SLA tiers." +description: "Free uptime SLA calculator. See how much downtime 99.9%, 99.99%, or 99.999% uptime allows per day, week, month, and year. Convert any uptime percentage to downtime instantly." category: "Product" faq: - - question: "What is Uptime SLA?" - answer: "Service Level Agreements (SLAs) define the expected performance and availability of your services. Understanding uptime percentages and their corresponding downtime allowances is crucial for maintaining customer trust and meeting compliance requirements." + - question: "What is an Uptime SLA?" + answer: "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." - question: "What are common SLA tiers?" - answer: "Common SLA tiers include 99.9% (three nines), 99.99% (four nines), and 99.999% (five nines). For example, 99.9% uptime allows for 8.77 hours of downtime per year, while 99.99% allows only 52.6 minutes annually. All calculations assume continuous 24/7 availability requirements." + answer: "Common SLA tiers include 99.9% (three nines) allowing 8h 45m downtime/year, 99.99% (four nines) allowing 52m 35s/year, and 99.999% (five nines) allowing only 5m 15s/year. Most cloud providers offer between 99.9% and 99.99% uptime SLAs." + - question: "How much downtime does 99.9% uptime allow?" + 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%." --- _All calculations assume continuous 24/7 availability requirements._