From fe3b2c544c89c3d29e99bec256f13eae3718e926 Mon Sep 17 00:00:00 2001 From: Thibault Le Ouay Date: Sun, 7 Jun 2026 21:30:29 +0200 Subject: [PATCH] docs: more contents (#2246) --- .../pages/docs/concept/uptime-monitoring.mdx | 2 +- .../docs/guides/how-to-import-status-page.mdx | 18 +++---- .../pages/docs/reference/dns-monitor.mdx | 52 +++++++++++++++++++ .../create-your-first-status-page.mdx | 4 ++ .../pages/docs/tutorial/getting-started.mdx | 20 +++++-- .../migrate-from-atlassian-statuspage.mdx | 13 +++++ .../pages/guides/migrate-from-betterstack.mdx | 13 +++++ .../pages/guides/migrate-from-instatus.mdx | 13 +++++ 8 files changed, 120 insertions(+), 15 deletions(-) diff --git a/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx b/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx index f4ebcc9a..2c7d766f 100644 --- a/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx +++ b/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx @@ -65,7 +65,7 @@ These terms appear throughout the docs. We use them with specific meanings: - **Monitor**: A configured endpoint and the rules for watching it (URL, frequency, regions, assertions). You create monitors; they persist until you delete them. - **Check**: A single execution of a monitor at a point in time — one request, one response, one row of data. A monitor produces many checks over its lifetime. -- **Region**: A geographic location where openstatus runs checks from (e.g. `iad`, `fra`, `sin`). The terms *region*, *location*, and *probe* are used interchangeably in product UI and prose, but they refer to the same concept: where the request originates. See the [Location Reference](/docs/reference/location) for the full list. +- **Region**: A geographic place where openstatus runs checks from (e.g. `iad`, `fra`, `sin`). Region is one layer in a stack with *probe* and *location*; see [Probes, Locations, and Regions](/docs/concept/probes-and-locations) for the distinction. The [Location Reference](/docs/reference/location) has the full list and the IPs to allowlist. - **Private location**: A region you operate yourself — typically a Docker container behind your firewall — so openstatus can check internal services it could not otherwise reach. ## Why uptime monitoring is crucial diff --git a/apps/web/src/content/pages/docs/guides/how-to-import-status-page.mdx b/apps/web/src/content/pages/docs/guides/how-to-import-status-page.mdx index cae38fa8..077b5e1d 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-import-status-page.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-import-status-page.mdx @@ -17,9 +17,9 @@ Migrating away from your current status page provider does not have to mean star openstatus currently supports importing from three providers: -- **[Atlassian Statuspage](https://openstatus.dev/guides/migrate-from-atlassian-statuspage)** — the most widely used hosted status page solution. -- **[Better Stack](https://openstatus.dev/guides/migrate-from-betterstack)** — monitoring and status page platform (formerly Better Uptime). -- **[Instatus](https://openstatus.dev/guides/migrate-from-instatus)** — a modern status page service with component-level tracking. +- **[Atlassian Statuspage](/guides/migrate-from-atlassian-statuspage)** — the most widely used hosted status page solution. +- **[Better Stack](/guides/migrate-from-betterstack)** — monitoring and status page platform (formerly Better Uptime). +- **[Instatus](/guides/migrate-from-instatus)** — a modern status page service with component-level tracking. Each link above points to a provider-specific migration guide with detailed instructions on API key generation and data mapping. @@ -96,9 +96,9 @@ Not every provider exposes the same data. The table below summarizes what openst ## After import @@ -141,6 +141,6 @@ Running the import a second time does not deduplicate incidents or maintenances. ### Provider-specific guides -- [Migrate from Atlassian Statuspage](https://openstatus.dev/guides/migrate-from-atlassian-statuspage) -- [Migrate from Better Stack](https://openstatus.dev/guides/migrate-from-betterstack) -- [Migrate from Instatus](https://openstatus.dev/guides/migrate-from-instatus) +- [Migrate from Atlassian Statuspage](/guides/migrate-from-atlassian-statuspage) +- [Migrate from Better Stack](/guides/migrate-from-betterstack) +- [Migrate from Instatus](/guides/migrate-from-instatus) diff --git a/apps/web/src/content/pages/docs/reference/dns-monitor.mdx b/apps/web/src/content/pages/docs/reference/dns-monitor.mdx index b3749d28..b884dd19 100644 --- a/apps/web/src/content/pages/docs/reference/dns-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/dns-monitor.mdx @@ -74,6 +74,58 @@ The duration after which a DNS response is considered degraded. This indicates a The number of times the monitor will retry a failed DNS lookup before reporting a definitive failure. For example: `3` +### Assertions + +Assertions let you validate the records returned by a DNS lookup. A check fails if any assertion does not match. + +**Limits:** up to 10 assertions per monitor. + +#### Record assertions + +Validate the values returned for a specific DNS record type. + +**Supported record types:** `A`, `AAAA`, `CNAME`, `MX`, `TXT`. + +> `NS` records can be looked up but cannot be asserted on. + +**Comparisons:** + +- `Equal` — the returned record value must exactly match the specified target. +- `Not Equal` — the returned record value must not exactly match the specified target. +- `Contains` — the returned record value must include the specified target string. +- `Not Contains` — the returned record value must not include the specified target string. + +**Example use cases:** + +- Verify an `A` record resolves to your expected IP after a DNS change. +- Confirm a `CNAME` still points at your CDN provider. +- Check that an `MX` record contains the expected mail host. +- Detect drift in `TXT` records (SPF, DKIM, DMARC, site verification). + +### OpenTelemetry + +Configures the export of monitoring metrics to an OpenTelemetry-compatible observability platform. + +#### OTLP endpoint + +**Type:** String (optional) +**Protocol:** HTTP only + +The OTLP (OpenTelemetry Protocol) endpoint URL where collected metrics should be exported. + +**Example:** `https://otlp.example.com/v1/metrics` + +#### OTLP headers + +**Type:** Key-value pairs (optional) + +Custom headers to include when sending metrics to your OTLP endpoint. Commonly used for authentication or tenant identification. + +**Common example:** +``` +Authorization: Bearer +``` + ## Related resources - **[CLI reference](/docs/reference/cli-reference)** — manage monitors as code using the openstatus CLI. diff --git a/apps/web/src/content/pages/docs/tutorial/create-your-first-status-page.mdx b/apps/web/src/content/pages/docs/tutorial/create-your-first-status-page.mdx index 851fbab5..634a689b 100644 --- a/apps/web/src/content/pages/docs/tutorial/create-your-first-status-page.mdx +++ b/apps/web/src/content/pages/docs/tutorial/create-your-first-status-page.mdx @@ -17,6 +17,10 @@ In this tutorial, you'll create a public status page to communicate your service By the end you'll have a public status page showing your service health, monitors displayed on the page, and a working understanding of the privacy and security options. + + ## Get started ### 1. Create the status page diff --git a/apps/web/src/content/pages/docs/tutorial/getting-started.mdx b/apps/web/src/content/pages/docs/tutorial/getting-started.mdx index f488c615..17e49ef2 100644 --- a/apps/web/src/content/pages/docs/tutorial/getting-started.mdx +++ b/apps/web/src/content/pages/docs/tutorial/getting-started.mdx @@ -7,13 +7,23 @@ sidebar: order: 1 --- -Our tutorials walk you through getting your first monitor up and running, creating and configuring status pages, setting up monitoring infrastructure, and using the openstatus CLI for automation. +Our tutorials walk you end-to-end through the openstatus workflow: monitor an endpoint, get alerted when it fails, publish a status page, and communicate during an incident — then automate the whole thing from the CLI. -### Core tutorials +If you're new, follow the tutorials below in order. Each one builds on the previous and takes 5–10 minutes. -- **[Create your first monitor](/docs/tutorial/create-your-first-monitor)** (~5 min) — set up uptime monitoring for your first endpoint. -- **[Create a status page](/docs/tutorial/create-your-first-status-page)** (~5 min) — build a public status page to communicate service health to your users. -- **[Get started with the openstatus CLI](/docs/tutorial/get-started-with-openstatus-cli)** (~10 min) — automate monitor management from the command line. +### Get started + +1. **[Create an uptime monitor](/docs/tutorial/create-your-first-monitor)** (~5 min) — set up uptime monitoring for your first endpoint. +2. **[Wire up your first notification](/docs/tutorial/your-first-notification)** (~5 min) — create a notification channel, attach it to your monitor, and confirm an alert lands. +3. **[Create a status page](/docs/tutorial/create-your-first-status-page)** (~5 min) — build a public status page to communicate service health to your users. +4. **[Publish your first status report](/docs/tutorial/your-first-status-report)** (~10 min) — walk the four-state incident workflow (investigating → identified → monitoring → resolved) from the dashboard. + +### Automate with the CLI + +Once you're comfortable with the dashboard, manage your stack as code: + +- **[Get started with the openstatus CLI](/docs/tutorial/get-started-with-openstatus-cli)** (~10 min) — install the CLI, authenticate, and import your monitors to a YAML file you can version-control. +- **[Manage status reports from the CLI](/docs/tutorial/manage-status-reports-cli)** (~10 min) — open, update, and resolve a status report from the terminal during an incident. ### What's next 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 49bb243f..dfba5dfe 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 @@ -132,6 +132,19 @@ If you use a custom domain for your status page, update your DNS records to poin After verifying that everything is working correctly on openstatus, you can cancel your Atlassian Statuspage subscription. Consider keeping the old page in read-only mode for a transition period so that any bookmarked URLs still resolve. +## Video walkthrough + +Watch a full migration from Atlassian Statuspage to openstatus in real time. + + + ## Further Reading - [Blog: Import from Statuspage, Betterstack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) 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 1e1d1f2a..ca5015fe 100644 --- a/apps/web/src/content/pages/guides/migrate-from-betterstack.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-betterstack.mdx @@ -161,6 +161,19 @@ Once the import finishes, there are a few things to verify: - **DNS and custom domain.** If your Better Stack status page used a custom domain, update your DNS records to point to openstatus. See the [docs guide](https://www.openstatus.dev/docs/guides/how-to-import-status-page) for instructions on configuring custom domains. - **Subscribers.** Re-invite your subscribers from the openstatus dashboard. Better Stack does not expose subscriber data via their API, so this step must be done manually. +## Video walkthrough + +Watch a full migration from Better Stack to openstatus in real time. + + + ## Further reading - [Import from Statuspage, Better Stack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) -- blog announcement covering all three supported providers. 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 fc9a7358..d5ec550b 100644 --- a/apps/web/src/content/pages/guides/migrate-from-instatus.mdx +++ b/apps/web/src/content/pages/guides/migrate-from-instatus.mdx @@ -90,6 +90,19 @@ Toggle which resource types to include. Click **Import**. The import runs in sec **Remove the old page.** Once you have verified everything works, you can deactivate or delete your Instatus page. +## Video walkthrough + +Watch a full migration from Instatus to openstatus in real time. + + + ## Further reading - [Blog: Importing from Statuspage, Betterstack, and Instatus](/blog/import-from-statuspage-betterstack-instatus) -- 2.51.2