diff --git a/apps/web/src/content/pages/docs/concept/uptime-monitoring-as-code.mdx b/apps/web/src/content/pages/docs/concept/uptime-monitoring-as-code.mdx index bc715f54..33e5b2ad 100644 --- a/apps/web/src/content/pages/docs/concept/uptime-monitoring-as-code.mdx +++ b/apps/web/src/content/pages/docs/concept/uptime-monitoring-as-code.mdx @@ -33,7 +33,7 @@ This approach offers significant advantages: ## How it works with openstatus -We publish an official [Terraform provider](https://registry.terraform.io/providers/openstatusHQ/openstatus/latest) that lets you manage your entire openstatus workspace declaratively — monitors, status pages, component groups, notifications, and maintenance windows. +We publish an official [Terraform provider](https://registry.terraform.io/providers/openstatusHQ/openstatus/latest) that lets you manage your openstatus workspace declaratively — monitors, status pages, component groups, notifications, and private locations. Here's what a minimal `main.tf` looks like: diff --git a/apps/web/src/content/pages/docs/guides/how-deploy-status-page-cf-pages.mdx b/apps/web/src/content/pages/docs/guides/how-deploy-status-page-cf-pages.mdx index c1d38654..63030798 100644 --- a/apps/web/src/content/pages/docs/guides/how-deploy-status-page-cf-pages.mdx +++ b/apps/web/src/content/pages/docs/guides/how-deploy-status-page-cf-pages.mdx @@ -33,8 +33,8 @@ The code for the template is available on [GitHub](https://github.com/openstatus First, you need an API key to fetch your monitoring data. 1. Navigate to your openstatus dashboard. -2. Go to **Settings** → **API Tokens**. -3. Click **Create API Key** and copy the key. +2. Go to **Settings** → **General** and find the **API Keys** card. +3. Click **Create** and copy the key. ### 2. Set up the Astro project diff --git a/apps/web/src/content/pages/docs/guides/how-to-configure-status-page.mdx b/apps/web/src/content/pages/docs/guides/how-to-configure-status-page.mdx index be0739cd..d85dd552 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-configure-status-page.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-configure-status-page.mdx @@ -18,11 +18,10 @@ openstatus offers enhanced status page customisation with multiple themes and di ## Get started -Go to the **Status Page Redesign** section in your status page settings and toggle `Enable New Version`. Once enabled, you'll see three subsections: +Open your status page in the dashboard. Configuration is split across two places: -1. **Tracker configuration** -2. **Theme explorer** -3. **Links** +- The **Components** page holds **Components Configuration** — how trackers render each component's data. +- The status page **Settings** hold General, Appearance, Custom Theme, Links, Locales, Page Access, Custom Domain, and the Danger Zone. Once enabled, the subdomain will have a rewrite to the new project. We are adding a `maxAge: 600` request cookie to improve the page load. **If you decide to deactivate the new version, it might take up to 10 minutes for the user to see the old page.** +### 1. Components configuration -### 1. Tracker configuration - -The tracker configuration is split into two groups: how each component's **bars and cards** display its data, and the page-wide **uptime and history** view. They live in separate containers because they answer two different questions. +The **Components Configuration** card, on the **Components** page, controls two related things: how each component's **bars and cards** display its data, and the page-wide **uptime and history** view. #### Bars and cards -These settings only apply to **monitor components** — the container is disabled until your status page has at least one. +These settings only apply to **monitor components** — the fields are disabled until your status page has at least one. **Bar type** — how every day is displayed in a status tracker. Either **absolute** or **manual**. @@ -84,13 +81,15 @@ Example of **manual bar** with **simple card** and **hiding uptime** alt="manual bar type and hiding uptime" /> -### 2. Theme explorer +### 2. Appearance -You can choose between different themes. The starting set is: +Pick a theme under **Settings → Appearance**, in the **Style** field. The shipped set is: - `default` (openstatus) +- `default-rounded` - `supabase` -- `github-high-contrast` +- `github-contrast` +- `dracula` Visit [themes.openstatus.dev](https://themes.openstatus.dev) to see the list of supported themes. You can also [create and contribute your own](/docs/guides/how-to-create-status-page-theme). 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 074f350f..3c6b1a66 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 @@ -15,7 +15,7 @@ In this guide, you'll connect the openstatus MCP server to Claude Code so the ag ## 1. Create an API key -Open the openstatus dashboard, go to **Settings → API Tokens**, and click **Create Token**. +Open the openstatus dashboard, go to **Settings → General**, find the **API Keys** card, and click **Create**. Pick a scope: @@ -73,7 +73,7 @@ Open Claude Code and run: /mcp ``` -You should see `openstatus` listed as **connected**, with the registered read tools (`list_status_pages`, `list_monitors`, `get_monitor_status`, `search_docs`, …) and — if your key has write scope — the mutation tools (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`, …). See the [MCP server reference](/docs/reference/mcp-server) for the full list. +You should see `openstatus` listed as **connected**, with the registered read tools (`list_status_pages`, `list_monitors`, `get_monitor_status`, `list_private_locations`, …) and — if your key has write scope — the mutation tools (`create_status_report`, `add_status_report_update`, `resolve_status_report`, `create_maintenance`, …). See the [MCP server reference](/docs/reference/mcp-server) for the full list. If the server shows as disconnected, see [Troubleshooting](#troubleshooting) below. @@ -106,8 +106,14 @@ If you have a write-scoped key, try drafting an incident — Claude Code will sh ### `/mcp` shows openstatus as disconnected -1. **Re-check the header** — run `claude mcp list` and confirm the `x-openstatus-key` value matches a key visible in **Settings → API Tokens**. Whitespace and trailing newlines are common copy-paste failures. -2. **Reachability** — `curl -i -H "x-openstatus-key: os_..." https://api.openstatus.dev/mcp` should return a `200` with a `mcp-session-id` header. A `401` means the key is wrong or revoked; a network error means a proxy or firewall is blocking the connection. +1. **Re-check the header** — run `claude mcp list` and confirm the `x-openstatus-key` value matches a key visible in **Settings → General → API Keys**. Whitespace and trailing newlines are common copy-paste failures. +2. **Reachability** — the endpoint is stateless and speaks Streamable HTTP, so a plain `curl` GET returns `406 Not Acceptable` unless you ask for an event stream: + + ```bash + curl -i -H "x-openstatus-key: os_..." -H "Accept: text/event-stream" https://api.openstatus.dev/mcp + ``` + + A `401` means the key is wrong or revoked; a network error means a proxy or firewall is blocking the connection. There is no `mcp-session-id` header — the server never issues one. 3. **Re-add the server** — `claude mcp remove openstatus` then re-run the `claude mcp add` command from step 2. ### "Tool not available" when asking Claude Code to create an incident diff --git a/apps/web/src/content/pages/docs/guides/how-to-deploy-probes-cloudflare-containers.mdx b/apps/web/src/content/pages/docs/guides/how-to-deploy-probes-cloudflare-containers.mdx index f02981d3..32c7d4b6 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-deploy-probes-cloudflare-containers.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-deploy-probes-cloudflare-containers.mdx @@ -45,7 +45,7 @@ pnpm create cloudflare@latest --template=cloudflare/templates/containers-templat ### 3. Pull and tag the probe Docker image -Pull the official openstatus private location image from Docker Hub. You must specify the `linux/amd64` platform, as this is what Cloudflare Containers supports. +Pull the official openstatus private location image from the GitHub Container Registry (`ghcr.io`). You must specify the `linux/amd64` platform, as this is what Cloudflare Containers supports. ```bash # Pull the image 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 4a87cf80..5ec1313f 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 @@ -74,11 +74,11 @@ Importing incidents and maintenances creates historical records in openstatus. T Click **Import** to start the process. The import runs in phases: -1. **Components and groups** — structural elements are created first so that incidents and maintenances can reference them. -2. **Incidents** — historical and active incidents, including updates and component impact. -3. **Maintenances** — scheduled and completed maintenance windows. -4. **Subscribers** — email subscribers (where supported by the source provider). -5. **Monitors** — existing monitoring checks (Better Stack and Checkly). +1. **Monitors** — existing monitoring checks. Better Stack and Checkly only; imported first so components can link to them. +2. **Components and groups** — structural elements, created before incidents and maintenances so those can reference them. +3. **Incidents** — historical and active incidents, including updates and component impact. +4. **Maintenances** — scheduled and completed maintenance windows. +5. **Subscribers** — email subscribers. Statuspage and Instatus only. A progress indicator shows the current phase and any errors encountered. When the import finishes, you are redirected to your status page configuration with all imported data in place. 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 ca3a684a..8e0264e4 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 @@ -98,7 +98,7 @@ A healthy server should return a JSON response like `{"result":{},"jsonrpc":"2.0 Once your `openstatus.yaml` file is ready, use the openstatus CLI to create the monitor: ```bash -openstatus create openstatus.yaml +openstatus monitors apply --config openstatus.yaml ``` This command uploads your configuration, and monitoring will begin immediately. diff --git a/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx b/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx index e9655366..a5418499 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx @@ -9,7 +9,7 @@ description: "A step-by-step tutorial to install the openstatus Slack agent and |---|---| | **Time** | ~5 minutes | | **Level** | Beginner | -| **Prerequisites** | openstatus account, Slack workspace where you have permission to install apps | +| **Prerequisites** | openstatus account on a paid plan (the Slack agent is not available on Hobby), Slack workspace where you have permission to install apps | In this guide, you'll install the openstatus Slack agent so you can manage incidents directly from your Slack workspace — no need to switch to the dashboard. The agent uses an LLM to interpret natural-language messages like *"create an incident for the payment API"* and turn them into status page actions. @@ -23,15 +23,31 @@ Navigate to **Settings** > **Integrations** in your openstatus dashboard. ### 2. Install the Slack integration -Click the **Install Slack** button. You'll be redirected to Slack's authorization page where you can select the workspace and channel you want to connect. +Click the **Add to Slack** button. You'll be redirected to Slack's authorization page where you can select the workspace you want to connect. (If you see an **Upgrade** button instead, your plan doesn't include the Slack agent.) Grant the requested permissions and click **Allow** to complete the installation. -### 3. Verify the installation +### 3. Add the bot to a channel -After completing the OAuth flow, go to the Slack channel you selected and type: +Installing the app doesn't pick a channel — no channel is selected during the OAuth flow. Invite the bot to the channel you want to use, either by running the subscribe command there: + +``` +/openstatus subscribe https://acme.openstatus.dev +``` + +which subscribes the channel to a status page and joins the bot at the same time, or by `/invite @openstatus` for a private channel the bot can't self-join. + +The available slash commands are: + +- `/openstatus subscribe ` — subscribe this channel to a status page +- `/openstatus unsubscribe ` — unsubscribe +- `/openstatus subscriptions` — show this channel's subscriptions + +### 4. Verify the installation + +In that channel, type: ``` @openstatus what's the status of my monitors? @@ -41,7 +57,7 @@ The bot should respond with a summary of your monitors. If you see a response, t -### 4. Start managing incidents from Slack +### 5. Start managing incidents from Slack Here are some examples of what you can do: @@ -87,9 +103,9 @@ Plan downtime so subscribers are informed in advance. ### The bot doesn't respond when mentioned -1. **Check the channel** — make sure you're mentioning `@openstatus` in the channel you selected during installation. +1. **Check the channel** — make sure the bot has been added to it. Run `/openstatus subscriptions` there, or re-run `/openstatus subscribe ` to join it. Private channels can't be self-joined; use `/invite @openstatus`. 2. **Check permissions** — go to **Settings** > **Integrations** and verify the Slack integration shows as connected. -3. **Reinstall** — if the integration appears disconnected, click **Install Slack** again to re-authorise. +3. **Reinstall** — if the integration appears disconnected, click **Add to Slack** again to re-authorise. ### "Not authorized" or permission errors diff --git a/apps/web/src/content/pages/docs/guides/how-to-translate-status-page.mdx b/apps/web/src/content/pages/docs/guides/how-to-translate-status-page.mdx index c160ded3..420833f9 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-translate-status-page.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-translate-status-page.mdx @@ -19,6 +19,7 @@ Currently supported languages: | `de` | Deutsch | | `tr` | Türkçe | | `hi` | हिंदी | +| `ko` | 한국어 | ## Enable translations on your status page @@ -49,9 +50,9 @@ Add your locale to `packages/locales/index.ts`: ```ts import type { Locale as DateFnsLocale } from "date-fns/locale"; -import { de, enUS, fr, hi, tr } from "date-fns/locale"; +import { de, enUS, fr, hi, ko, tr } from "date-fns/locale"; -export const locales = ["en", "fr", "de", "tr", "hi"] as const; +export const locales = ["en", "fr", "de", "tr", "hi", "ko"] as const; // ... export const localeDetails: Record = { en: { name: "English", flag: "🇺🇸" }, @@ -59,6 +60,7 @@ export const localeDetails: Record = { de: { name: "Deutsch", flag: "🇩🇪" }, tr: { name: "Türkçe", flag: "🇹🇷" }, hi: { name: "हिंदी", flag: "🇮🇳" }, + ko: { name: "한국어", flag: "🇰🇷" }, }; export const dateFnsLocales: Record = { @@ -67,6 +69,7 @@ export const dateFnsLocales: Record = { de, tr, hi, + ko, }; ``` 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 a1395067..d71a9993 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 @@ -65,7 +65,7 @@ This guide is divided into three parts: launching the services, setting up analy ```bash cp .env.docker.example .env.docker ``` - Open `.env.docker` in a text editor. At a minimum, you **must** set a value for `AUTH_SECRET` for authentication to work. For a complete setup, review the file for other variables like OAuth providers or email services. + Open `.env.docker` in a text editor. Four values are marked `[REQUIRED]` and must be set: `AUTH_SECRET`, `RESEND_API_KEY` (magic-link login won't work without it), `SELF_HOST`, and `NEXT_PUBLIC_URL`. For a complete setup, review the file for other variables like OAuth providers or email services. Two values matter for the rest of this guide — set them now: ```env @@ -300,7 +300,7 @@ openstatus consists of multiple services running together: |---------|------|---------| | db-migrate | — | One-shot database migrations; exits after applying | | workflows | 3000 | Background jobs and scheduled tasks | -| server | 3001 | API backend (tRPC) | +| server | 3001 | API backend (ConnectRPC + REST v1) | | dashboard | 3002 | Admin interface for configuration | | status-page | 3003 | Public status pages | | private-location | 8081 | **Ingest server** — receives results from probes | diff --git a/apps/web/src/content/pages/docs/reference/cli-reference.mdx b/apps/web/src/content/pages/docs/reference/cli-reference.mdx index c01f81d7..30af88eb 100644 --- a/apps/web/src/content/pages/docs/reference/cli-reference.mdx +++ b/apps/web/src/content/pages/docs/reference/cli-reference.mdx @@ -25,7 +25,7 @@ Global flags: Run an HTTP check against a URL from 28 global regions. -> openstatus check \1 +> openstatus check `` > openstatus check https://openstat.us > openstatus check https://openstat.us -X POST -H 'Authorization: Bearer …' -d '\{"ping":true\}' > openstatus check https://openstat.us -d @payload.json @@ -111,7 +111,7 @@ The following flags are supported: Delete a monitor. -> openstatus monitors delete \1 +> openstatus monitors delete `` > openstatus monitors delete 12345 -y Usage: @@ -153,7 +153,7 @@ The following flags are supported: Get a monitor information. -> openstatus monitors info \1 +> openstatus monitors info `` > openstatus monitors info 12345 > openstatus monitors info 12345 --time-range 7d @@ -198,7 +198,7 @@ The following flags are supported: List HTTP response logs for a monitor. -> openstatus monitors logs \1 +> openstatus monitors logs `` > openstatus monitors logs 12345 > openstatus monitors logs 12345 --limit 10 > openstatus monitors logs 12345 --limit 5 --offset 5 @@ -226,7 +226,7 @@ The following flags are supported: Get detailed HTTP response log for a monitor. -> openstatus monitors log-info \1 \1 +> openstatus monitors log-info `` `` > openstatus monitors log-info 12345 abc-def-ghi Fetch a single HTTP response log with full details including timing phases, response headers, and assertion results. @@ -247,7 +247,7 @@ The following flags are supported: Trigger a monitor execution. -> openstatus monitors trigger \1 +> openstatus monitors trigger `` > openstatus monitors trigger 12345 Trigger a monitor execution on demand. This command allows you to launch your tests on demand. @@ -299,7 +299,7 @@ The following flags are supported: Get status report details. -> openstatus status-report info \1 +> openstatus status-report info `` > openstatus status-report info 12345 Usage: @@ -335,7 +335,8 @@ The following flags are supported: | `--status="…"` | Initial status (investigating, identified, monitoring, resolved) | string | | *none* | | `--message="…"` | Initial message describing the incident | string | | *none* | | `--page-id="…"` | Status page ID to associate with this report | string | | *none* | -| `--component-ids="…"` | Comma-separated page component IDs | string | | *none* | +| `--component-ids="…"` | Comma-separated page component IDs (legacy; mutually exclusive with `--impact`) | string | | *none* | +| `--impact="…"` | Per-component impact, repeatable: `--impact =` (level: operational, degraded, partial_outage, major_outage). Mutually exclusive with `--component-ids` | string | | *none* | | `--notify` | Notify subscribers about this status report | bool | `false` | *none* | | `--date="…"` | Date when the event occurred (RFC 3339 format, defaults to now) | string | | *none* | @@ -343,7 +344,7 @@ The following flags are supported: Update status report metadata. -> openstatus status-report update \1 [--title "New title"] [--component-ids id1,id2] +> openstatus status-report update `` [--title "New title"] [--component-ids id1,id2] Usage: @@ -363,7 +364,7 @@ The following flags are supported: Delete a status report. -> openstatus status-report delete \1 +> openstatus status-report delete `` > openstatus status-report delete 12345 -y Usage: @@ -383,7 +384,7 @@ The following flags are supported: Add an update to a status report. -> openstatus status-report add-update \1 --status resolved --message "Issue has been resolved" +> openstatus status-report add-update `` --status resolved --message "Issue has been resolved" Usage: @@ -436,7 +437,7 @@ The following flags are supported: Get maintenance window details. -> openstatus maintenance info \1 +> openstatus maintenance info `` > openstatus maintenance info 12345 Usage: @@ -480,7 +481,7 @@ The following flags are supported: Update a maintenance window. -> openstatus maintenance update \1 [--title "New title"] [--message "New message"] [--from ...] [--to ...] +> openstatus maintenance update `` [--title "New title"] [--message "New message"] [--from ...] [--to ...] Usage: @@ -503,7 +504,7 @@ The following flags are supported: Delete a maintenance window. -> openstatus maintenance delete \1 +> openstatus maintenance delete `` > openstatus maintenance delete 12345 -y Usage: @@ -553,7 +554,7 @@ The following flags are supported: Get status page details. -> openstatus status-page info \1 +> openstatus status-page info `` > openstatus status-page info 12345 Usage: @@ -602,7 +603,7 @@ The following flags are supported: Get notification details. -> openstatus notification info \1 +> openstatus notification info `` > openstatus notification info 12345 Usage: @@ -617,6 +618,89 @@ The following flags are supported: |-----------------------------|-----------------------------|--------|:-------------:|:----------------------:| | `--access-token="…"` (`-t`) | openstatus API Access Token | string | | `OPENSTATUS_API_TOKEN` | +## `private-locations` command (aliases: `pl`) + +Manage private locations. + +Private locations are self-hosted checker agents that run monitors from inside your own network. This command lists them, shows their details, and creates new ones. Public regions (Fly.io, Koyeb, Railway) are not listed here; they appear in `openstatus monitors info` and `openstatus check`. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] private-locations [ARGUMENTS...] +``` + +### `private-locations list` subcommand + +List all private locations. + +> openstatus private-locations list +> openstatus pl list +> openstatus pl list --limit 10 + +List the private locations in your workspace, with the health of each agent and the number of monitors it runs. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] private-locations list [COMMAND FLAGS] [ARGUMENTS...] +``` + +The following flags are supported: + +| Name | Description | Type | Default value | Environment variables | +|-----------------------------|-------------------------------------------------------|--------|:-------------:|:----------------------:| +| `--access-token="…"` (`-t`) | openstatus API Access Token | string | | `OPENSTATUS_API_TOKEN` | +| `--limit="…"` | Maximum number of private locations to return (1-100) | int | `0` | *none* | + +### `private-locations info` subcommand + +Get private location details. + +> openstatus private-locations info `` +> openstatus pl info pl_1a2b3c +> openstatus pl info pl_1a2b3c --show-token + +Fetch a private location including the monitors it runs and its agent token. The token is masked unless `--show-token` is passed. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] private-locations info [COMMAND FLAGS] [ARGUMENTS...] +``` + +The following flags are supported: + +| Name | Description | Type | Default value | Environment variables | +|-----------------------------|----------------------------------------------|--------|:-------------:|:----------------------:| +| `--access-token="…"` (`-t`) | openstatus API Access Token | string | | `OPENSTATUS_API_TOKEN` | +| `--show-token` | Reveal the agent token instead of masking it | bool | `false` | *none* | + +### `private-locations create` subcommand + +Create a private location. + +> openstatus private-locations create --name office-paris +> openstatus pl create --name office-paris --monitor-ids 12345,12346 +> openstatus pl create --name office-paris --metadata env=prod --metadata team=infra + +Create a private location and print its agent token. The token is shown in full because you need it to configure the agent; retrieve it later with `openstatus pl info --show-token`. Run without `--name` in an interactive terminal to be prompted, including a picker for the monitors to attach. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] private-locations create [COMMAND FLAGS] [ARGUMENTS...] +``` + +The following flags are supported: + +| Name | Description | Type | Default value | Environment variables | +|-----------------------------|-------------------------------------------------------|--------|:-------------:|:----------------------:| +| `--access-token="…"` (`-t`) | openstatus API Access Token | string | | `OPENSTATUS_API_TOKEN` | +| `--name="…"` | Name of the private location | string | | *none* | +| `--monitor-ids="…"` | Monitor IDs to attach, comma-separated or repeated | string | | *none* | +| `--metadata="…"` | Key/value label, repeatable: --metadata `=` | string | | *none* | + ## `run` command (aliases: `r`) Run your uptime tests. 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 b884dd19..2742e3d1 100644 --- a/apps/web/src/content/pages/docs/reference/dns-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/dns-monitor.mdx @@ -84,9 +84,9 @@ Assertions let you validate the records returned by a DNS lookup. A check fails Validate the values returned for a specific DNS record type. -**Supported record types:** `A`, `AAAA`, `CNAME`, `MX`, `TXT`. +**Supported record types:** `A`, `AAAA`, `CNAME`, `MX`, `TXT`, `NS`. -> `NS` records can be looked up but cannot be asserted on. +> `NS` assertions are available in the dashboard and the v1 REST API. The ConnectRPC `RecordAssertion` message does not accept them yet. **Comparisons:** diff --git a/apps/web/src/content/pages/docs/reference/http-monitor.mdx b/apps/web/src/content/pages/docs/reference/http-monitor.mdx index c22af4da..9ca1ab55 100644 --- a/apps/web/src/content/pages/docs/reference/http-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/http-monitor.mdx @@ -47,6 +47,7 @@ The HTTP method to use when making the request to the endpoint. - `OPTIONS` — query supported methods. - `PATCH` — partial resource updates. - `TRACE` — echo request for debugging. +- `CONNECT` — establish a tunnel to the server. **Common usage:** @@ -57,7 +58,7 @@ The HTTP method to use when making the request to the endpoint. ### Body **Type:** String (optional) -**Available for:** `POST`, `PUT`, `PATCH` methods +**Available for:** `POST`, `PUT`, `PATCH`, `DELETE` methods The request body to send with the HTTP request. Supports both text and binary data. @@ -72,6 +73,8 @@ For binary content (e.g., images), use base64 encoding with data URI: data:image/jpeg;base64,/9j... ``` +The data URI is only decoded for `POST` requests that set `Content-Type: application/octet-stream`. With any other method or content type the string is sent literally. + **Content type:** Set the appropriate `Content-Type` header (e.g., `application/json`, `application/octet-stream`). ### Headers @@ -93,11 +96,14 @@ User-Agent: Custom-Agent/1.0 - **Content negotiation** — specify accepted response formats. - **Custom identification** — add tracking or debugging headers. -**Note:** openstatus automatically adds `User-Agent: openstatus/1.0` to all requests. +**Note:** openstatus automatically adds `User-Agent: OpenStatus/1.0` to all requests. You can override it with a custom `User-Agent` header. + +Up to 20 headers per monitor. ### Regions -**Type:** Array of strings (required) +**Type:** Array of strings (optional) +**Default:** a plan-based selection (4 regions on the free plan, 6 on paid plans) **Format:** Region identifiers (e.g., `iad`, `jnb`) The geographical regions from which the HTTP request will be triggered. This allows for monitoring global availability and performance. See the [Location Reference](/docs/reference/location) for the full list of regions and the IPs to allowlist. @@ -137,9 +143,16 @@ The duration after which the HTTP request is considered to be performing in a de The number of times the monitor will automatically retry the HTTP request upon failure before reporting a definitive error. For example: `3` +### Follow redirects + +**Type:** Boolean (optional) +**Default:** `true` + +Whether the checker follows HTTP redirects. When enabled, up to 10 redirects are followed and assertions run against the final response. When disabled, the first response is recorded as-is, so a `301`/`302` is what your status code assertions see. + ### Assertions -Assertions let you validate specific aspects of the HTTP response. +Assertions let you validate specific aspects of the HTTP response. You can define up to 10 status code, 10 body, and 10 header assertions per monitor. #### Body assertions @@ -152,6 +165,9 @@ Validate the content of the HTTP response body. - `Equal` — the response body must exactly match the specified string. - `Not Equal` — the response body must not exactly match the specified string. - `Empty` — the response body must be empty. +- `Not Empty` — the response body must not be empty. +- `Greater Than` / `Greater Than or Equal` — lexicographic comparison against the target. +- `Less Than` / `Less Than or Equal` — lexicographic comparison against the target. #### Status code assertions @@ -179,6 +195,9 @@ Validate the presence or content of specific HTTP response headers. - `Equal` — a header's value must exactly match the specified string. - `Not Equal` — a header's value must not exactly match the specified string. - `Empty` — a header's value must be empty or the header must not be present. +- `Not Empty` — a header's value must not be empty. +- `Greater Than` / `Greater Than or Equal` — lexicographic comparison against the target. +- `Less Than` / `Less Than or Equal` — lexicographic comparison against the target. **Example use cases:** diff --git a/apps/web/src/content/pages/docs/reference/incident.mdx b/apps/web/src/content/pages/docs/reference/incident.mdx index 91a03b76..82ba2e3c 100644 --- a/apps/web/src/content/pages/docs/reference/incident.mdx +++ b/apps/web/src/content/pages/docs/reference/incident.mdx @@ -14,22 +14,25 @@ An incident in openstatus represents a detected problem or service disruption re ## Incident triggering -An incident is triggered when a significant percentage of recent monitoring checks for a given monitor report a failed status. This mechanism prevents false positives from transient network issues. +An incident is triggered when enough of a monitor's regions agree that the endpoint is down. Requiring agreement across regions prevents a single flaky probe from opening an incident. **Trigger condition:** -- **Failure threshold** — an incident is initiated when at least 50% of the checks within a defined window (e.g., the last `N` checks or within a `T` duration) have reported a `failure` or `degraded` status. +- **Failure threshold** — an incident is opened when at least half of the monitor's configured regions report an `error` status. A single-region monitor triggers on its one region. +- Only `error` opens an incident. A `degraded` status triggers notifications but does not create an incident. +- If an incident is already open for the monitor, no second incident is created. ## Incident lifecycle and states -Incidents progress through several states reflecting their current resolution status. These states are managed through status reports (see [Status report reference](/docs/reference/status-report)). +An incident's lifecycle is tracked with timestamps rather than a manual workflow: -**Primary states:** +- **Open** — created when the failure threshold is met. `resolvedAt` is null. +- **Acknowledged** — a team member has taken ownership. `acknowledgedAt` and `acknowledgedBy` are set. +- **Resolved** — either auto-resolved when the monitor recovers (`autoResolved: true`) or manually resolved, setting `resolvedAt` and `resolvedBy`. -- `investigating` — the incident has been detected, and the team is actively looking into the root cause. -- `identified` — the root cause of the incident has been identified. -- `monitoring` — a fix has been deployed or a mitigation is in place, and the service is being monitored to confirm resolution. -- `resolved` — the incident has been fully resolved, and the service is operating normally. +The stored `status` field accepts `triage` (the default), `investigating`, `identified`, `monitoring`, `resolved`, and `duplicated`. + +Incidents are distinct from status reports. Status reports are the manual, public communication channel on your status page and are not linked to an incident record — see the [Status report reference](/docs/reference/status-report). ## Properties @@ -37,9 +40,11 @@ While an incident is active, it collects and displays key information related to - **Monitor association** — each incident is directly linked to the monitor that triggered it, providing immediate context to the affected service. - **Start time** — timestamp indicating when the incident was first detected and created. -- **Status reports** — a chronological log of all updates and state changes applied to the incident. -- **Impacted locations** — the geographical regions from which the monitor reported failures. +- **Title and summary** — free-text fields describing the incident. +- **Acknowledgement** — who acknowledged the incident and when. +- **Resolution** — who resolved it and when, plus whether it was auto-resolved. +- **Screenshots** — captured at failure and at recovery, on plans where screenshots are enabled. ## Related resources -- **[Status report reference](/docs/reference/status-report)** — details on how incident statuses are managed and reported. +- **[Status report reference](/docs/reference/status-report)** — how to communicate an incident publicly on your status page. diff --git a/apps/web/src/content/pages/docs/reference/location.mdx b/apps/web/src/content/pages/docs/reference/location.mdx index 8fcbf2ac..be08cd62 100644 --- a/apps/web/src/content/pages/docs/reference/location.mdx +++ b/apps/web/src/content/pages/docs/reference/location.mdx @@ -26,7 +26,7 @@ Below is the complete list of regions used for monitoring, along with their asso | ewr | Newark | 209.71.69.221 | 2a09:8280:e610:1:0:22:b79b:0 | | fra | Frankfurt | 209.71.90.204 | 2a09:8280:e612:1:0:22:b79b:0 | | gru | São Paulo | 209.71.94.28 | 2a09:8280:e615:1:0:22:b79b:0 | -| iad | Washington, D.C. | 209.71.81.6 | 2a09:8280:e618:1:0:22:b79b:0 | +| iad | Ashburn, Virginia | 209.71.81.6 | 2a09:8280:e618:1:0:22:b79b:0 | | jnb | Johannesburg | 209.71.83.120 | 2a09:8280:e620:1:0:22:b79b:0 | | lax | Los Angeles | 209.71.91.96 | 2a09:8280:e621:1:0:22:b79b:0 | | lhr | London | 209.71.85.82 | 2a09:8280:e622:1:0:22:b79b:0 | @@ -42,12 +42,12 @@ Below is the complete list of regions used for monitoring, along with their asso Below is the complete list of Railway regions used for monitoring, along with their associated IPv4 addresses. -| Region code | Location name | IPv4 address | -|--------------------------|------------------|-------------------| -| europe-west4-drams3a | Europe West | 208.77.244.15 | -| asia-southeast1-eqsg3a | Asia Southeast | 208.77.246.15 | -| us-east4-eqdc4a | US East | 162.220.234.15 | -| us-west2 | US West | 162.220.232.99 | +| Region code | Location name | IPv4 address | +|--------------------------------|------------------|-------------------| +| railway_europe-west4-drams3a | Europe West | 208.77.244.15 | +| railway_asia-southeast1-eqsg3a | Asia Southeast | 208.77.246.15 | +| railway_us-east4-eqdc4a | US East | 162.220.234.15 | +| railway_us-west2 | US West | 162.220.232.99 | ## Koyeb regions 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 d7a543d1..04d73fac 100644 --- a/apps/web/src/content/pages/docs/reference/mcp-server.mdx +++ b/apps/web/src/content/pages/docs/reference/mcp-server.mdx @@ -22,13 +22,13 @@ Every request must include your openstatus API key in the `x-openstatus-key` hea x-openstatus-key: os_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` -Get a key from the dashboard's **Settings → API Tokens**. +Get a key from the dashboard's **Settings → General → API Keys**. ### Scopes Each API key carries a scope that controls what tools the MCP server exposes: -- **Read-only** — the server only registers read tools (`list_*`, `get_*`, and `search_docs`). Mutation tools (`create_*`, `update_*`, `add_*`, `resolve_*`) are not advertised in `tools/list` and cannot be called. +- **Read-only** — the server only registers read tools (`list_*` and `get_*`). Mutation tools (`create_*`, `update_*`, `add_*`, `resolve_*`) are not advertised in `tools/list` and cannot be called. - **Read & write** — every tool is available. Scope is set at key creation time and is **immutable**. To change a key's scope, revoke it and issue a new one. @@ -37,7 +37,7 @@ For AI agents that should only observe state — health summaries, paging on-cal ## Tools -The server exposes 20 tools, grouped by resource and scoped to the workspace tied to your API key. Mutations write to the audit log with `actor_type = "mcp"` (see [Audit log](#audit-log)). +The server exposes 19 tools (17 on plans without the `audit-log` feature), grouped by resource and scoped to the workspace tied to your API key. Mutations write to the audit log with `actor_type = "mcp"` (see [Audit log](#audit-log)). ### Pages @@ -80,6 +80,12 @@ The server exposes 20 tools, grouped by resource and scoped to the workspace tie |----------------------|------|---------| | `list_notifications` | read | List notification channels and the monitors each one is wired to. Channel credentials are never exposed. | +### Private locations + +| Tool | Type | Purpose | +|--------------------------|------|---------| +| `list_private_locations` | read | List the workspace's private locations with their name, status (`active` / `error`), metadata, and `lastSeenAt`. Agent tokens are never exposed. | + ### Audit Registered only when the workspace plan includes the `audit-log` feature — otherwise these tools are absent from `tools/list`. @@ -89,15 +95,6 @@ Registered only when the workspace plan includes the `audit-log` feature — oth | `list_audit_logs` | read | List audit-log entries (mutating actions) newest-first, bounded to the last 14 days. Optional `entityType` + `entityId` filter. | | `get_audit_log` | read | Full before/after snapshots and `changedFields` for a single audit-log entry. | -### Docs - -These query the public openstatus documentation — not your workspace data — so the assistant can answer product and how-to questions grounded in the official docs. - -| Tool | Type | Purpose | -|----------------|------|---------| -| `search_docs` | read | Search the public documentation, guides, or changelog (`type: "docs" \| "guides" \| "changelog"`). Returns scored results with title, snippet, url, and a `path` to pass to `get_doc_page`. | -| `get_doc_page` | read | Fetch the full markdown of a docs, guides, or changelog page by `path` (as returned by `search_docs`). Long pages are truncated with a marker linking to the full page. | - The MCP client gates every tool call behind your approval — the server does not gate again. Each tool also carries [MCP annotations](https://modelcontextprotocol.io/specification/server/tools#tool-annotations) (`readOnlyHint`, `destructiveHint`, `idempotentHint`) so well-behaved clients can decide whether to confirm, cache, or surface differently. ### Notifying subscribers @@ -182,7 +179,7 @@ In Cursor, open **Settings → MCP → Add Server**: Errors map by severity: -- **Recoverable** (`NOT_FOUND`, `VALIDATION`, `CONFLICT`, `LIMIT_EXCEEDED`) come back as a tool result with `isError: true`. The model can read the message and retry with corrected input. +- **Recoverable** (`NOT_FOUND`, `VALIDATION`, `CONFLICT`, `LIMIT_EXCEEDED`, `PRECONDITION_FAILED`) come back as a tool result with `isError: true`. The model can read the message and retry with corrected input. - **Transport-level** (`UNAUTHORIZED`, `FORBIDDEN`, `INTERNAL`, malformed input) come back as a JSON-RPC error. Error messages are not redacted — the consumer is an LLM that benefits from the detail. @@ -190,7 +187,7 @@ Error messages are not redacted — the consumer is an LLM that benefits from th ## Limits - `list_status_reports` and `list_maintenances` use offset pagination: `page` (1-indexed, default 1) and `perPage` (default 50, max 200). The response's `pagination.totalPages` tells the LLM whether more pages exist. `list_status_pages` is unpaginated (workspaces typically have a handful). -- `list_monitors` and `list_audit_logs` page via `perPage` (max 50); `list_notifications` via `perPage` (max 200); `list_response_logs` via `limit` (max 100) and `offset`. +- `list_monitors` and `list_audit_logs` page via `perPage` (max 50); `list_notifications` via `perPage` (max 200); `list_private_locations` via `perPage` (max 100); `list_response_logs` via `limit` (max 100) and `offset`. - No per-key rate limiting today. Treat MCP usage like REST: one server call per tool invocation. ## Audit log diff --git a/apps/web/src/content/pages/docs/reference/notification.mdx b/apps/web/src/content/pages/docs/reference/notification.mdx index d35d3680..b2851676 100644 --- a/apps/web/src/content/pages/docs/reference/notification.mdx +++ b/apps/web/src/content/pages/docs/reference/notification.mdx @@ -54,6 +54,14 @@ Sends notifications to a Google Chat space. - **Webhook URL** (required) — a [Google Chat webhook URL](https://developers.google.com/workspace/chat/quickstart/webhooks) for the target space. +### Microsoft Teams + +Sends notifications to a Microsoft Teams channel through a Power Automate workflow. + +**Configuration:** + +- **Webhook URL** (required) — the URL of a Power Automate *"When a Teams webhook request is received"* workflow. Example: `https://prod-00.westeurope.logic.azure.com:443/workflows/abc/triggers/manual/paths/invoke`. + ### SMS Sends alerts as SMS messages to a mobile phone number. @@ -155,6 +163,7 @@ Integrates with OpsGenie for incident management. **Configuration:** - **API key** (required) — an API key obtained from your OpsGenie account. +- **Region** (required) — the OpsGenie API region your account lives in: `us` or `eu`. ### PagerDuty @@ -162,7 +171,7 @@ Integrates with PagerDuty for incident alerting. **Configuration:** -- **Integration steps** (required) — follow the specific integration steps provided within the PagerDuty workflow to set up this channel. +- **Integration key** (required) — the Events API v2 integration key for your PagerDuty service. The dashboard walks you through the PagerDuty connect flow, which fills this in for you. ### Ntfy diff --git a/apps/web/src/content/pages/docs/reference/page-components.mdx b/apps/web/src/content/pages/docs/reference/page-components.mdx index b5acaba3..d45ba21c 100644 --- a/apps/web/src/content/pages/docs/reference/page-components.mdx +++ b/apps/web/src/content/pages/docs/reference/page-components.mdx @@ -167,8 +167,10 @@ Component groups allow you to organize related page components into logical sect **Group configuration:** - **Name** — the group heading displayed on your status page. -- **Order** — position of the group relative to other groups and ungrouped components. -- **Components** — the page components contained within this group. +- **Default open** — whether the group renders expanded on first load. Defaults to collapsed. +- **Components** — the page components contained within this group, ordered independently. + +A group has no order field of its own. Its position among other groups and ungrouped components is derived from the lowest display order of the components inside it. ## Events and status diff --git a/apps/web/src/content/pages/docs/reference/private-location.mdx b/apps/web/src/content/pages/docs/reference/private-location.mdx index 66a27919..46a21438 100644 --- a/apps/web/src/content/pages/docs/reference/private-location.mdx +++ b/apps/web/src/content/pages/docs/reference/private-location.mdx @@ -36,12 +36,12 @@ Detailed steps for setting up a private location involve: Private locations can currently be created, listed, updated, and deleted from the authenticated dashboard API. The supported private location fields are: - `name` — the display name shown in the dashboard. -- `token` — the probe authentication token. +- `token` — the probe authentication token. Generated by the server on creation and returned by create and get; list responses omit it. +- `status` — read-only probe health, `active` or `error`, derived from the agent heartbeat. +- `metadata` — up to 20 user-defined key/value labels (keys 1–64 characters, values up to 256 characters), for example `{"city": "Frankfurt", "provider": "Hetzner"}`. - `monitors` — the monitor IDs attached to the private location. - `lastSeenAt` — the last time the private location probe connected. -Additional display metadata such as country, city, or hosting provider is not currently part of the private location model. If you need that information today, include it in the location name, for example `Frankfurt - Hetzner`. - **Example use cases:** - Monitoring an internal REST API that is only accessible from within your corporate network. diff --git a/apps/web/src/content/pages/docs/reference/status-page.mdx b/apps/web/src/content/pages/docs/reference/status-page.mdx index 5b42b8cc..6560f996 100644 --- a/apps/web/src/content/pages/docs/reference/status-page.mdx +++ b/apps/web/src/content/pages/docs/reference/status-page.mdx @@ -67,9 +67,10 @@ Visitors from outside the allowed ranges are redirected to a static "Access Rest **Configuration:** -- Set `access_type` to `ip-restriction` in the dashboard or API. +- Set the access type to IP restriction in the dashboard, or `access_type` to `PAGE_ACCESS_TYPE_IP_RESTRICTED` via the ConnectRPC `StatusPageService`. - Provide `allowed_ip_ranges` as a comma-separated list of IPv4 CIDR ranges (we automatically append `/32` to single IPs). - IPv6 is not supported. +- The deprecated v1 REST API does not expose this access type — its `accessType` field accepts only `public`, `password`, and `email-domain`. **Note:** this feature is available as a paid add-on for Starter and Pro plans. @@ -87,7 +88,7 @@ Selects one of the community themes for your status page. Browse and preview the ### Custom theme -**Type:** Per-mode CSS variable overrides (Pro and Scale plans) +**Type:** Per-mode CSS variable overrides (included on Pro and Scale, available as a paid add-on on Starter) Overrides individual CSS variables of the selected theme, separately for light and dark mode. Custom values take precedence over the theme; every variable you leave unset falls back to the theme's value. @@ -98,7 +99,7 @@ Overrides individual CSS variables of the selected theme, separately for light a --radius: 0.5rem; ``` -Values accept any valid CSS value (colors in `oklch`, `hsl`, hex, lengths, etc.). The characters `<`, `{`, `}` and `;` are not allowed inside a value. +Values accept any valid CSS value (colors in `oklch`, `hsl`, hex, lengths, etc.). Each value is limited to 256 characters, and the characters `<`, `{`, `}`, `;` and ASCII control characters are not allowed inside a value. #### Supported CSS variables @@ -187,7 +188,7 @@ ssh [slug]@ssh.openstatus.dev Enables multi-language support for your status page. You can set a default locale and optionally enable a locale switcher so visitors can choose their preferred language. -**Supported locales:** `en` (English), `fr` (Français), `de` (Deutsch) +**Supported locales:** `en` (English), `fr` (Français), `de` (Deutsch), `tr` (Türkçe), `hi` (हिंदी), `ko` (한국어) **Configuration:** diff --git a/apps/web/src/content/pages/docs/reference/status-report.mdx b/apps/web/src/content/pages/docs/reference/status-report.mdx index b29c63d1..694ee8e6 100644 --- a/apps/web/src/content/pages/docs/reference/status-report.mdx +++ b/apps/web/src/content/pages/docs/reference/status-report.mdx @@ -14,12 +14,23 @@ A status report is a chronological update or event associated with an ongoing in ## Relationship to incidents -Each status report is directly linked to a specific incident. As an incident progresses through its resolution process, new status reports are added to provide updates, often accompanied by a change in the incident's overall status. +Status reports are independent of [incidents](/docs/reference/incident). An incident is the automatic, internal record opened by the checker when a monitor fails; a status report is the manual, public narrative you publish on a status page. There is no database link between the two — you decide what to communicate and when. + +A status report belongs to a status page and optionally to a set of page components. As a situation evolves you append updates to the same report, each carrying its own status and message. ## Configuration and properties A status report consists of several key properties that define its content and context. +### Title + +**Type:** String (required) +**Length:** 1–256 characters + +The headline of the report, shown on the public status page, in the events feed, and in subscriber notifications. + +**Example:** `"Database connectivity issues"` + ### Status **Type:** Enumerated string (required) diff --git a/apps/web/src/content/pages/docs/reference/subscriber.mdx b/apps/web/src/content/pages/docs/reference/subscriber.mdx index d9bea51a..f475a710 100644 --- a/apps/web/src/content/pages/docs/reference/subscriber.mdx +++ b/apps/web/src/content/pages/docs/reference/subscriber.mdx @@ -16,9 +16,11 @@ A subscriber in openstatus is an entity (typically a user or an integration) tha Users typically subscribe to a status page's updates through a dedicated interface provided on the status page itself. The process involves: -1. **Inputting contact information** — providing an email address, phone number, or other contact details depending on the available notification channels. -2. **Opt-in confirmation** — confirming the subscription, often through a verification link sent to the provided contact to prevent unwanted subscriptions. -3. **Channel selection (optional)** — selecting which specific notification channels (e.g., email, SMS, Slack webhook) to receive updates through, if multiple options are available. +1. **Entering an email address** — public self-subscription is email-only. +2. **Opt-in confirmation** — a verification email is sent, and the subscription only activates once the recipient confirms it. +3. **Scope selection (optional)** — where enabled, choosing which page components to be notified about instead of the whole page. + +Webhook and Slack subscriptions cannot be created from the public page. An operator adds those from the dashboard (see below). ## Notification types received @@ -26,9 +28,10 @@ Subscribers receive notifications for key events affecting the monitored service - **Incident creation** — when a new incident is detected and published. - **Incident updates** — when status reports are published for an ongoing incident (e.g., status changes from `investigating` to `identified`, `monitoring`, or `resolved`). -- **Monitor status changes** — direct alerts for individual monitor status changes if configured to do so (less common for public subscribers). - **Scheduled maintenance** — when a maintenance window is created on the page, subscribers can be notified that it has been scheduled (see the [maintenance reference](/docs/reference/maintenance)). +Raw monitor status changes are *not* sent to status page subscribers. Those go to your configured [notification channels](/docs/reference/notification). Subscribers only receive status report updates and scheduled maintenance. + ## Subscriber management Status page administrators can manage their subscriber lists, including: @@ -39,12 +42,13 @@ Status page administrators can manage their subscriber lists, including: ## Adding subscribers from the dashboard -Beyond public self-subscription, administrators can add subscribers directly from the dashboard. This is useful for onboarding partners, internal teams, or automation that should receive updates without going through the public opt-in flow. Each manually added subscriber uses one of two channels: +Beyond public self-subscription, administrators can add subscribers directly from the dashboard. This is useful for onboarding partners, internal teams, or automation that should receive updates without going through the public opt-in flow. Each manually added subscriber uses one of three channels: - **Email** — delivers updates to a contact address. By adding an email here you confirm the contact has consented to receive status updates; no confirmation email is sent. - **Webhook** — POSTs each update to a URL. Slack and Discord URLs receive channel-native messages; any other URL receives a generic JSON payload. +- **Slack** — posts each update straight into a Slack channel through the openstatus Slack app. The bot token is resolved from the workspace integration at send time and is never stored on the subscriber. -For both channels, you can optionally: +For every channel, you can optionally: - **Set a display label** — shown in place of the raw destination in the dashboard (e.g. `Supabase #incidents`). - **Scope to page components** — leave empty to notify for the entire page, or select specific components to only notify on matching reports. @@ -100,7 +104,7 @@ Any other URL receives a versioned, channel-agnostic JSON payload. Use this to f } ``` -`page.url` is the canonical status page origin, while `status_report.url` (and `maintenance.url` below) is the deep link to that specific event. Each entry in `components` carries an `impact`, which may be `null` when no impact is associated with the component for this update. +`page.url` is the canonical status page origin, while `status_report.url` (and `maintenance.url` below) is the deep link to that specific event. Each entry in `components` carries an `impact`. The schema permits `null` for forward compatibility, but the current sender always emits a concrete impact, falling back to `operational` for reports created before component impacts existed. Scheduled maintenance is delivered with `type: "maintenance"` and a `data.maintenance` object carrying `starts_at` / `ends_at` in place of the `update` block. The `version` field is bumped on any breaking change, so pin to it when consuming the payload. diff --git a/apps/web/src/content/pages/docs/reference/tcp-monitor.mdx b/apps/web/src/content/pages/docs/reference/tcp-monitor.mdx index e23a41cc..31309603 100644 --- a/apps/web/src/content/pages/docs/reference/tcp-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/tcp-monitor.mdx @@ -29,7 +29,8 @@ The endpoint of the TCP service you want to monitor. This includes the hostname ### Regions -**Type:** Array of strings (required) +**Type:** Array of strings (optional) +**Default:** a plan-based selection (4 regions on the free plan, 6 on paid plans) **Format:** Region identifiers (e.g., `iad`, `jnb`) The geographical regions from which the TCP connection attempt will be initiated. This allows for verification of service availability and network latency across different global locations. See the [Location Reference](/docs/reference/location) for the full list of regions and the IPs to allowlist. diff --git a/apps/web/src/content/pages/docs/reference/terraform.mdx b/apps/web/src/content/pages/docs/reference/terraform.mdx index 2a793c0d..9970c280 100644 --- a/apps/web/src/content/pages/docs/reference/terraform.mdx +++ b/apps/web/src/content/pages/docs/reference/terraform.mdx @@ -11,6 +11,7 @@ The openstatus Terraform provider lets you manage your monitoring infrastructure - Manage HTTP, TCP, and DNS monitors with assertions. - Configure notification channels (Slack, PagerDuty, email, webhooks, and more). - Create and manage status pages with component groups. +- Provision private locations and assign monitors to them. - Import existing resources into Terraform state. ## Installation @@ -307,7 +308,7 @@ terraform import openstatus_dns_monitor.main_domain ### `openstatus_notification` -Manages a notification channel. Supports 12 provider types: Discord, Email, Slack, PagerDuty, OpsGenie, Webhook, Telegram, SMS, WhatsApp, Google Chat, Grafana OnCall, and ntfy. +Manages a notification channel. Supports 13 provider types: Discord, Email, Slack, PagerDuty, OpsGenie, Webhook, Telegram, SMS, WhatsApp, Google Chat, Grafana OnCall, Microsoft Teams, and ntfy. **Arguments:** @@ -442,11 +443,17 @@ Manages a status page with access control and branding. | `contact_url` | `string` | No | Link to your contact page. | | `icon` | `string` | No | URL of the icon to display. | | `custom_domain` | `string` | No | Custom domain (DNS must point to openstatus first). | -| `access_type` | `string` | No | Access control: `public`, `password`, or `email-domain`. | +| `access_type` | `string` | No | Access control: `public`, `password`, `email-domain`, or `ip-restriction`. | | `password` | `string` | No | Required when `access_type` is `password`. Sensitive. | | `auth_email_domains` | `list(string)` | No | Required when `access_type` is `email-domain`. | +| `allowed_ip_ranges` | `string` | No | Comma-separated IPv4 CIDR ranges. Required when `access_type` is `ip`. | +| `theme` | `string` | No | Theme key applied to the page. | +| `custom_theme` | `object` | No | Per-mode CSS variable overrides merged over `theme`, with `light` and `dark` maps. Requires the custom-theme plan feature. | +| `default_locale` | `string` | No | Default language for the page. | +| `locales` | `list(string)` | No | Locales offered in the language switcher. | +| `allow_index` | `bool` | No | Whether search engines may index the page. | -**Read-only attributes:** `id` (string), `published` (bool), `theme` (string: `system`, `light`, `dark`), `created_at` (string), `updated_at` (string). +**Read-only attributes:** `id` (string), `published` (bool), `created_at` (string), `updated_at` (string). **Example — Public status page:** @@ -483,6 +490,17 @@ resource "openstatus_status_page" "company" { } ``` +**Example — IP-restricted status page:** + +```terraform +resource "openstatus_status_page" "internal" { + title = "Internal Status" + slug = "internal-status" + access_type = "ip-restriction" + allowed_ip_ranges = "10.0.0.0/8,192.168.0.0/16" +} +``` + **Import:** ```bash @@ -575,6 +593,42 @@ resource "openstatus_status_page_component_group" "applications" { terraform import openstatus_status_page_component_group.infrastructure / ``` +--- + +### `openstatus_private_location` + +Manages a private location: a self-hosted checker agent that runs the monitors you assign to it. + +Terraform owns `monitor_ids` and `metadata` — removing either from the configuration clears it on the next apply. Liveness (`status`, `last_seen_at`) is only available on the `openstatus_private_location` data source. + +**Arguments:** + +| Argument | Type | Required | Description | +| :------------ | :------------ | :------- | :----------------------------------------------------------- | +| `name` | `string` | Yes | Display name for the private location. | +| `monitor_ids` | `set(string)` | No | IDs of the monitors this private location runs. | +| `metadata` | `map(string)` | No | User-defined key/value labels attached to this location. | + +**Read-only attributes:** `id` (string), `token` (string, sensitive), `created_at` (string), `updated_at` (string). + +```terraform +resource "openstatus_private_location" "eu_dc" { + name = "EU Datacenter" + monitor_ids = [openstatus_http_monitor.api.id] + + metadata = { + env = "prod" + region = "eu-west-1" + } +} + +# The agent token is generated by openstatus. Pass it to the checker agent. +output "agent_token" { + value = openstatus_private_location.eu_dc.token + sensitive = true +} +``` + ## Data Sources ### `openstatus_monitor` @@ -657,6 +711,47 @@ output "status_page_url" { **Computed attributes:** `title`, `slug`, `description`, `homepage_url`, `contact_url`, `icon`, `custom_domain`, `published`, `access_type`, `password` (sensitive), `auth_email_domains`, `theme`, `created_at`, `updated_at`. +--- + +### `openstatus_private_location` + +Look up a single private location by ID. Unlike the resource, this data source exposes agent liveness. + +```terraform +data "openstatus_private_location" "eu_dc" { + id = "12" +} + +output "agent_last_seen" { + value = data.openstatus_private_location.eu_dc.last_seen_at +} +``` + +**Computed attributes:** `name`, `monitor_ids`, `metadata`, `status` (`active`, `error`, or `unknown`), `last_seen_at` (RFC 3339, null if the agent has never reported), `token` (sensitive), `created_at`, `updated_at`. + +--- + +### `openstatus_private_locations` + +List all private locations with pagination. + +```terraform +data "openstatus_private_locations" "all" { + limit = 100 +} + +output "private_location_names" { + value = [for l in data.openstatus_private_locations.all.private_locations : l.name] +} +``` + +| Argument | Type | Required | Default | Description | +| :------- | :------- | :------- | :------ | :----------------- | +| `limit` | `number` | No | `50` | Max results. | +| `offset` | `number` | No | `0` | Pagination offset. | + +**Computed:** `private_locations` — list of objects with `id`, `name`, `metadata`, `status`, `last_seen_at`, `monitor_count`, `created_at`, `updated_at`. Agent tokens are not returned by the list endpoint; use the singular data source to fetch one. + ## Available Regions Monitors can run from any of the following 28 regions: diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/authentication.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/authentication.mdx index b0e4bf2e..112e1b6b 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/authentication.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/authentication.mdx @@ -66,7 +66,7 @@ Scope is set when the key is created and is **immutable** — to change it, revo } ``` -A read-only key can revoke itself via `DELETE /v1/api-key/{id}` (the only carve-out — without it, a leaked read-only key would have no rotation path other than the dashboard). Revoking a *different* key from a read-only actor returns `403 Forbidden`. +API keys are managed from the dashboard (**Settings → General → API Keys**); there is no public REST or ConnectRPC endpoint for creating or revoking them. Internally, revocation carries one carve-out: a read-only key is allowed to revoke *itself*, so a leaked key always has a rotation path. Revoking a *different* key from a read-only actor is forbidden. ## Custom Base URL diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/getting-started.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/getting-started.mdx index 8fa934e1..bf460186 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/getting-started.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/getting-started.mdx @@ -10,8 +10,8 @@ description: "Install and start using the openstatus Node.js SDK" Before using the SDK, you need an API key: 1. Log in to the [openstatus dashboard](https://www.openstatus.dev/app/login) -2. Go to **Settings** > **API Keys** -3. Click **Create API Key** and copy it +2. Go to **Settings** > **General** and find the **API Keys** card +3. Click **Create** and copy the key diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/monitor-service.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/monitor-service.mdx index 2c58f386..aca91252 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/monitor-service.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/monitor-service.mdx @@ -4,7 +4,7 @@ title: Monitor Service description: "Create and manage HTTP, TCP, and DNS monitors with the openstatus Node.js SDK" --- -Manage HTTP, TCP, and DNS monitors. The Monitor Service provides 15 RPC methods for creating, updating, listing, triggering, deleting, querying monitor status and metrics, and inspecting HTTP response logs. +Manage HTTP, TCP, and DNS monitors. The Monitor Service provides 14 RPC methods for creating, updating, listing, triggering, deleting, querying monitor status and metrics, and inspecting HTTP response logs. All examples assume you have created a client: diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/notification-service.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/notification-service.mdx index 7f368b1b..03189d43 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/notification-service.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/notification-service.mdx @@ -4,7 +4,7 @@ title: Notification Service description: "Manage notification channels and providers with the openstatus Node.js SDK" --- -Manage notification channels for monitor alerts. Supports 12 providers. The Notification Service provides 7 RPC methods. +Manage notification channels for monitor alerts. Supports 13 providers. The Notification Service provides 7 RPC methods. ## Create Notification @@ -178,6 +178,26 @@ const { notification } = await client.notification.v1.NotificationService }); ``` +### Microsoft Teams + +```typescript +const { notification } = await client.notification.v1.NotificationService + .createNotification({ + name: "Teams Alerts", + provider: NotificationProvider.MS_TEAMS, + data: { + data: { + case: "msTeams", + value: { + webhookUrl: + "https://prod-00.westeurope.logic.azure.com:443/workflows/abc/triggers/manual/paths/invoke", + }, + }, + }, + monitorIds: ["123456"], + }); +``` + ### Ntfy ```typescript diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/reference.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/reference.mdx index baf09d3f..93a1c31b 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/reference.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/reference.mdx @@ -75,6 +75,7 @@ description: "Complete reference for enums, regions, assertions, and TypeScript | `EMAIL` | Email notification | | `GOOGLE_CHAT` | Google Chat webhook | | `GRAFANA_ONCALL` | Grafana OnCall | +| `MS_TEAMS` | Microsoft Teams (Power Automate workflow) | | `NTFY` | Ntfy push service | | `PAGERDUTY` | PagerDuty | | `OPSGENIE` | Opsgenie | @@ -98,6 +99,7 @@ description: "Complete reference for enums, regions, assertions, and TypeScript | `PUBLIC` | Publicly accessible | | `PASSWORD_PROTECTED` | Requires password | | `AUTHENTICATED` | Requires authentication | +| `IP_RESTRICTED` | Restricted to the CIDR ranges in `allowed_ip_ranges` | ### PageTheme @@ -374,7 +376,7 @@ All types and enums exported from `@openstatus/sdk-node`: - `Notification`, `NotificationSummary` - `NotificationData` -- `DiscordData`, `EmailData`, `GoogleChatData`, `GrafanaOncallData`, `NtfyData`, `OpsgenieData`, `PagerDutyData`, `SlackData`, `SmsData`, `TelegramData`, `WebhookData`, `WebhookHeader`, `WhatsappData` +- `DiscordData`, `EmailData`, `GoogleChatData`, `GrafanaOncallData`, `MsTeamsData`, `NtfyData`, `OpsgenieData`, `PagerDutyData`, `SlackData`, `SmsData`, `TelegramData`, `WebhookData`, `WebhookHeader`, `WhatsappData` - `CreateNotificationRequest`, `CreateNotificationResponse` - `GetNotificationRequest`, `GetNotificationResponse` - `ListNotificationsRequest`, `ListNotificationsResponse` diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/status-page-service.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/status-page-service.mdx index fa912a23..955c9f50 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/status-page-service.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/status-page-service.mdx @@ -4,7 +4,7 @@ title: Status Page Service description: "Manage status pages, components, groups, and subscribers with the openstatus Node.js SDK" --- -Manage status pages, components, component groups, and subscribers. The Status Page Service provides 20 RPC methods. +Manage status pages, components, component groups, and subscribers. The Status Page Service provides 21 RPC methods. ## Status Page CRUD diff --git a/apps/web/src/content/pages/docs/sdk/php/overview.mdx b/apps/web/src/content/pages/docs/sdk/php/overview.mdx index ec2fb314..e3a276e5 100644 --- a/apps/web/src/content/pages/docs/sdk/php/overview.mdx +++ b/apps/web/src/content/pages/docs/sdk/php/overview.mdx @@ -23,8 +23,8 @@ The SDK is open source and developed in its own repository, [openstatusHQ/sdk-ph Before using the SDK, you need an API key: 1. Log in to the [openstatus dashboard](https://www.openstatus.dev/app/login) -2. Go to **Settings** > **API Keys** -3. Click **Create API Key** and copy it +2. Go to **Settings** > **General** and find the **API Keys** card +3. Click **Create** and copy the key @@ -169,16 +169,13 @@ $header = new HeaderAssertion([ ### Creating a status page ```php -use Openstatus\Status_page\V1\CreateStatusPageRequest; -use Openstatus\Status_page\V1\PageTheme; -use Openstatus\Status_page\V1\StatusPage; +use Openstatus\StatusPage\V1\CreateStatusPageRequest; +use Openstatus\StatusPage\V1\PageTheme; $client->statusPage->v1->statusPageService->createStatusPage(new CreateStatusPageRequest([ - 'page' => new StatusPage([ - 'title' => 'Acme Status', - 'slug' => 'acme', - 'theme' => PageTheme::PAGE_THEME_LIGHT, - ]), + 'title' => 'Acme Status', + 'slug' => 'acme', + 'theme' => PageTheme::PAGE_THEME_LIGHT, ])); ``` diff --git a/apps/web/src/content/pages/docs/sdk/python/overview.mdx b/apps/web/src/content/pages/docs/sdk/python/overview.mdx index 6a1bf173..272bb69b 100644 --- a/apps/web/src/content/pages/docs/sdk/python/overview.mdx +++ b/apps/web/src/content/pages/docs/sdk/python/overview.mdx @@ -23,8 +23,8 @@ The SDK is open source and developed in its own repository, [openstatusHQ/sdk-py Before using the SDK, you need an API key: 1. Log in to the [openstatus dashboard](https://www.openstatus.dev/app/login) -2. Go to **Settings** > **API Keys** -3. Click **Create API Key** and copy it +2. Go to **Settings** > **General** and find the **API Keys** card +3. Click **Create** and copy the key diff --git a/apps/web/src/content/pages/docs/tutorial/get-started-with-openstatus-cli.mdx b/apps/web/src/content/pages/docs/tutorial/get-started-with-openstatus-cli.mdx index cf251ba4..01fa38ab 100644 --- a/apps/web/src/content/pages/docs/tutorial/get-started-with-openstatus-cli.mdx +++ b/apps/web/src/content/pages/docs/tutorial/get-started-with-openstatus-cli.mdx @@ -9,7 +9,7 @@ description: "Step-by-step tutorial to install and use the openstatus CLI for mo |---|---| | **Time** | ~10 minutes | | **Level** | Intermediate | -| **Prerequisites** | openstatus account, command-line experience, API token from your workspace (Settings → API) | +| **Prerequisites** | openstatus account, command-line experience, API key from your workspace (Settings → General → API Keys) | In this tutorial, you'll use the openstatus CLI to manage your monitors as code. This lets you version-control your monitoring configuration, automate deployments, and implement GitOps workflows. @@ -64,8 +64,8 @@ openstatus version x.x.x ## Configure API authentication -1. In your openstatus dashboard, go to **Settings → API Keys**. -2. Click **Create API Key** and copy the value — you won't see it again after closing the dialog. +1. In your openstatus dashboard, go to **Settings → General** and find the **API Keys** card. +2. Click **Create** and copy the value — you won't see it again after closing the dialog. 3. Make it available to the CLI as an environment variable: ```bash @@ -139,7 +139,7 @@ export PATH="$HOME/.local/bin:$PATH" **Fix:** 1. Verify the token is set: `echo $OPENSTATUS_API_TOKEN` -2. Regenerate the token in your workspace settings (Settings → API) +2. Regenerate the key in your workspace settings (Settings → General → API Keys) 3. Make sure there are no extra spaces or newlines in the token value ### "no monitors found" on import