From 238d572644e5d05a3d08cfb83c2ffed8d7012d3a Mon Sep 17 00:00:00 2001 From: Thibault Le Ouay Ducasse Date: Wed, 9 Sep 2026 11:31:34 +0200 Subject: [PATCH] docs: fix docs accuracy --- .../pages/docs/guides/getting-started.mdx | 2 +- .../guides/how-to-configure-status-page.mdx | 1 + .../guides/how-to-create-private-location.mdx | 6 +- ...to-deploy-probes-cloudflare-containers.mdx | 6 +- ...how-to-export-metrics-to-otlp-endpoint.mdx | 97 ++++++-- .../docs/guides/how-to-monitor-mcp-server.mdx | 214 ++++++++++-------- .../docs/guides/how-to-use-react-widget.mdx | 4 +- .../guides/self-host-status-page-only.mdx | 13 +- .../docs/guides/self-hosting-openstatus.mdx | 14 +- .../pages/docs/reference/http-monitor.mdx | 14 +- .../content/pages/docs/reference/incident.mdx | 7 +- .../content/pages/docs/reference/location.mdx | 21 +- .../pages/docs/reference/mcp-server.mdx | 17 +- .../pages/docs/reference/private-location.mdx | 4 +- .../pages/docs/reference/status-page.mdx | 19 +- .../create-your-first-status-page.mdx | 67 +++--- .../get-started-with-openstatus-cli.mdx | 54 +++-- .../pages/docs/tutorial/getting-started.mdx | 2 +- .../docs/tutorial/your-first-notification.mdx | 2 +- 19 files changed, 357 insertions(+), 207 deletions(-) diff --git a/apps/web/src/content/pages/docs/guides/getting-started.mdx b/apps/web/src/content/pages/docs/guides/getting-started.mdx index 44e3bbb3..e7bcf778 100644 --- a/apps/web/src/content/pages/docs/guides/getting-started.mdx +++ b/apps/web/src/content/pages/docs/guides/getting-started.mdx @@ -30,7 +30,7 @@ Our how-to guides solve specific problems with step-by-step instructions, walk y ## Agents and team workflow -- **[Connect openstatus to Claude Code](/docs/guides/how-to-connect-openstatus-to-claude-code)** — give a coding agent access through the MCP server. +- **[Connect openstatus to your coding agent](/docs/guides/how-to-connect-openstatus-to-your-agent)** — give Claude Code, Codex, opencode, Cursor, or ChatGPT access through the MCP server. - **[Set up the Slack agent](/docs/guides/how-to-setup-slack-agent)** — manage incidents from Slack in natural language. - **[Set up SAML single sign-on](/docs/guides/how-to-set-up-saml-sso)** — let your team sign in through your identity provider. 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 714bc823..56b8dccf 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 @@ -93,6 +93,7 @@ Pick a theme under **Settings > Appearance**, in the **Style** field. The shippe - `passbolt` - `gruvbox` - `tomorrow` +- `probo` 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-create-private-location.mdx b/apps/web/src/content/pages/docs/guides/how-to-create-private-location.mdx index a3b3f70f..5e9aa05b 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-create-private-location.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-create-private-location.mdx @@ -83,7 +83,11 @@ docker logs openstatus-probe Common causes: - **Invalid token** — double-check the token value; ensure no extra spaces or newlines. -- **Wrong variable name** — the probe reads `OPENSTATUS_KEY`. `OPENSTATUS_TOKEN` is ignored, so the probe starts unauthenticated and fetches no monitors. +- **Wrong variable name** — the probe reads `OPENSTATUS_KEY` and nothing else. If you set + `OPENSTATUS_TOKEN` instead, the probe refuses to start and exits immediately with: + ``` + OPENSTATUS_KEY is required: the probe cannot authenticate against openstatus + ``` - **Network issues** — ensure the container can reach `openstatus-private-location.fly.dev` on port 443. ### No data appearing in the dashboard 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 32c7d4b6..f8241ae0 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 @@ -125,7 +125,7 @@ Your private location probe is now running on Cloudflare Containers and will sta ## Verify the deployment -You can check the logs of your Cloudflare Worker to see the probe in action. In your openstatus dashboard, the private location should now show as connected. +You can check the logs of your Cloudflare Worker to see the probe in action. In your openstatus dashboard, the private location's status flips to **active** once the agent reports, and checks from it start appearing in your monitors' response logs. openstatus Private Location connected diff --git a/apps/web/src/content/pages/docs/guides/how-to-export-metrics-to-otlp-endpoint.mdx b/apps/web/src/content/pages/docs/guides/how-to-export-metrics-to-otlp-endpoint.mdx index 3b1e9bad..db3d1661 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-export-metrics-to-otlp-endpoint.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-export-metrics-to-otlp-endpoint.mdx @@ -11,13 +11,13 @@ You want to analyze your openstatus monitoring data alongside other telemetry da ## Solution -openstatus can export monitoring metrics to any OTLP (OpenTelemetry Protocol) compatible endpoint. By adding a simple configuration to your `openstatus.yaml` file, you can have metrics from every check sent directly to your monitoring stack. +openstatus can export monitoring metrics to any OTLP (OpenTelemetry Protocol) compatible endpoint. Add an `open_telemetry` block to a monitor in your Terraform configuration and metrics from every check that monitor runs are sent straight to your monitoring stack. ## Prerequisites - An observability platform that supports OTLP metric ingestion over HTTP. -- An `openstatus.yaml` file to configure your monitors. -- The [openstatus CLI](/docs/tutorial/get-started-with-openstatus-cli) to apply your configuration. +- A workspace on a plan that includes OTLP export (**Pro** and **Scale**). +- Terraform and the [openstatus provider](/docs/reference/terraform) configured — see [Manage openstatus with Terraform](/docs/guides/how-to-manage-openstatus-with-terraform) if you have not set it up yet. ## Step-by-step guide @@ -28,39 +28,86 @@ First, you need to find the specific URL and any required authentication headers - **Endpoint URL** — look for an HTTP endpoint for OTLP metrics. It typically ends in `/v1/metrics`. For example: `https://otlp.your-provider.com/v1/metrics`. - **Headers** — you will likely need an authentication header, such as `Authorization: Bearer YOUR_API_KEY` or `X-API-Key: YOUR_API_KEY`. -### 2. Configure your `openstatus.yaml` file - -Open your `openstatus.yaml` file and add the `openTelemetry` block at the top level. - -```yaml -# yaml-language-server: $schema=https://www.openstatus.dev/schema.json - -openTelemetry: - endpoint: - headers: - Authorization: Bearer - # Add any other required headers here - -# Your monitors are defined below -my-first-monitor: - # ... +### 2. Add an `open_telemetry` block to your monitor + +`open_telemetry` is a block on the monitor resource, so each monitor declares its own export +target. It is available on every monitor type — `openstatus_http_monitor`, +`openstatus_tcp_monitor`, `openstatus_dns_monitor`, and `openstatus_icmp_monitor`. + +```terraform +variable "otlp_token" { + type = string + sensitive = true +} + +resource "openstatus_http_monitor" "api" { + name = "API Health Check" + url = "https://api.example.com/health" + periodicity = "1m" + active = true + regions = ["fly-iad", "fly-ams"] + + open_telemetry { + endpoint = "https://otlp.your-provider.com/v1/metrics" + + headers { + key = "Authorization" + value = "Bearer ${var.otlp_token}" + } + } +} ``` -Replace `` and `` with the values you found in step 1. +Mark the token `sensitive` and pass it in with `TF_VAR_otlp_token` or from a secrets manager +rather than committing it. **Note**: Currently, we only support OTLP over HTTP. -### 3. Apply the configuration +### 3. Share one endpoint across many monitors + +Because the block lives on each resource, put the endpoint and headers in a `locals` block and +use `dynamic` so a change to the destination is a one-line edit rather than a sweep across every +monitor: + +```terraform +locals { + otlp_endpoint = "https://otlp.your-provider.com/v1/metrics" + otlp_headers = { + Authorization = "Bearer ${var.otlp_token}" + } +} + +resource "openstatus_http_monitor" "api" { + name = "API Health Check" + url = "https://api.example.com/health" + periodicity = "1m" + active = true + regions = ["fly-iad", "fly-ams"] + + open_telemetry { + endpoint = local.otlp_endpoint + + dynamic "headers" { + for_each = local.otlp_headers + content { + key = headers.key + value = headers.value + } + } + } +} +``` -Use the openstatus CLI to apply the changes to your account. +### 4. Apply the configuration ```bash -openstatus monitors apply +terraform plan # confirm only the open_telemetry block is changing +terraform apply ``` -After applying the configuration, openstatus will send metrics to your specified endpoint after every check is completed. +Once applied, openstatus sends metrics to your endpoint after every check completes. -### 4. Verify in your observability platform +### 5. Verify in your observability platform Go to your observability platform and look for the new metrics coming from openstatus. You should be able to build dashboards and alerts based on this data. 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 b584ceae..19213558 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 @@ -20,79 +20,81 @@ How can you confidently ensure your MCP server is healthy and responsive at all ## Solution -openstatus monitors MCP servers by sending JSON-RPC `ping` requests to your endpoint from multiple global locations. This verifies not only network reachability but also the correct functioning of your server's JSON-RPC interface. This guide walks you through setting up comprehensive monitoring for any MCP server using the openstatus CLI. +openstatus monitors MCP servers by sending JSON-RPC `ping` requests to your endpoint from multiple global locations. This verifies not only network reachability but also the correct functioning of your server's JSON-RPC interface. This guide declares those monitors with the openstatus Terraform provider, so your monitoring lives in version control alongside the rest of your infrastructure. ## Prerequisites - An [openstatus account](https://app.openstatus.dev/login). -- The [openstatus CLI installed](/docs/tutorial/get-started-with-openstatus-cli). +- Terraform and the [openstatus provider](/docs/reference/terraform) configured — see [Manage openstatus with Terraform](/docs/guides/how-to-manage-openstatus-with-terraform) if you have not set it up yet. - An MCP server with a publicly accessible endpoint. - A basic understanding of the [JSON-RPC 2.0 protocol](https://www.jsonrpc.org/specification). ## Step-by-step guide -### 1. Create your `openstatus.yaml` file - -openstatus allows you to define and manage your monitors using a YAML configuration file, which is ideal for GitOps workflows. This approach ensures your monitoring setup is version-controlled, auditable, and easily deployable. - -Create a file named `openstatus.yaml` and add the following configuration, adapting it for your own MCP endpoint. This example targets a Hugging Face MCP server. - -```yaml -# yaml-language-server: $schema=https://www.openstatus.dev/schema.json - -mcp-server: - name: "HF MCP Server" - description: "Hugging Face MCP server monitoring" - frequency: "1m" - active: true - regions: ["iad", "ams", "lax"] - retry: 3 - kind: http - request: - url: https://hf.co/mcp - method: POST - body: > - { - "jsonrpc": "2.0", - "id": "openstatus", - "method": "ping" - } - headers: - User-Agent: openstatus - Accept: application/json, text/event-stream - Content-Type: application/json - assertions: - - kind: statusCode - compare: eq - target: 200 - - kind: textBody - compare: eq - target: '{"result":{},"jsonrpc":"2.0","id":"openstatus"}' +### 1. Declare the monitor + +Add an `openstatus_http_monitor` resource, adapting it for your own MCP endpoint. This example +targets a Hugging Face MCP server. + +```terraform +resource "openstatus_http_monitor" "mcp_server" { + name = "HF MCP Server" + description = "Hugging Face MCP server monitoring" + url = "https://hf.co/mcp" + method = "POST" + periodicity = "1m" + active = true + retry = 3 + regions = ["fly-iad", "fly-ams", "fly-lax"] + + body = jsonencode({ + jsonrpc = "2.0" + id = "openstatus" + method = "ping" + }) + + headers { + key = "Content-Type" + value = "application/json" + } + + headers { + key = "Accept" + value = "application/json, text/event-stream" + } + + status_code_assertions { + target = 200 + comparator = "eq" + } + + body_assertions { + target = "{\"result\":{},\"jsonrpc\":\"2.0\",\"id\":\"openstatus\"}" + comparator = "eq" + } +} ``` ### 2. Understand the configuration -The key fields in this YAML configuration: +The fields that matter for an MCP check: - `name` and `description` — human-readable name and explanation for your monitor. -- `frequency` — how often openstatus runs the check (e.g., `1m`, `5m`, `10m`). -- `regions` — an array of geographic regions from which to perform checks (e.g., `["iad", "ams", "lax"]`). Monitoring from multiple regions helps detect localised issues. -- `retry` — the number of times to retry a failed check before marking it as down. -- `kind` — must be `http` for MCP servers. -- `request`: - - `url` — the full URL of your MCP server's JSON-RPC endpoint. - - `method` — must be `POST` for JSON-RPC requests. - - `body` — the JSON-RPC `ping` request payload. - - `headers` — standard HTTP headers for JSON-RPC communication. -- `assertions` — rules to validate the server's response. - - `statusCode` — ensures the HTTP response is `200 OK`. - - `textBody` — verifies that the response payload exactly matches the expected JSON-RPC `ping` result. +- `url` — the full URL of your MCP server's JSON-RPC endpoint. +- `method` — must be `POST` for JSON-RPC requests. +- `periodicity` — how often openstatus runs the check (`30s`, `1m`, `5m`, `10m`, `30m`, `1h`). +- `regions` — the locations the check runs from. Monitoring from several catches localised issues. Terraform uses the prefixed region codes (`fly-iad`), unlike the dashboard — see the [location reference](/docs/reference/location). +- `retry` — how many times a failed check is retried before the monitor is marked down. +- `body` — the JSON-RPC `ping` payload. `jsonencode` keeps it readable and correctly escaped. +- `headers` — one block per header. openstatus already sends `User-Agent: OpenStatus/1.0`; override it only if your server cares. +- `status_code_assertions` — ensures the HTTP response is `200 OK`. +- `body_assertions` — verifies the response payload matches the expected JSON-RPC `ping` result. ### 3. Test your MCP server online first Before deploying a monitor, confirm the server actually speaks MCP. The quickest way is the [MCP server health check](/play/mcp-health) — paste your URL and it runs the full handshake (`initialize`, `ping`, `tools/list`) from the browser, shows the per-step latency, and tells you whether the endpoint is Healthy, Partial, Auth Required, or Unreachable. Use it to read off the exact response your assertion needs to match. -You can also test the `ping` endpoint manually with `curl`. This helps verify the `target` value for your `textBody` assertion. +You can also test the `ping` endpoint manually with `curl`. This helps verify the `target` value for your body assertion. ```bash curl -X POST \\ @@ -105,13 +107,14 @@ A healthy server should return a JSON response like `{"result":{},"jsonrpc":"2.0 ### 4. Deploy your monitor -Once your `openstatus.yaml` file is ready, use the openstatus CLI to create the monitor: +Review the plan, then apply it: ```bash -openstatus monitors apply --config openstatus.yaml +terraform plan # confirm the monitor is what you expect +terraform apply ``` -This command uploads your configuration, and monitoring will begin immediately. +Monitoring begins as soon as the apply completes. ## Monitoring an MCP server that requires authentication @@ -119,21 +122,26 @@ Most production MCP servers are not public. An unauthenticated `ping` against on Add the same `Authorization` header your AI clients use: -```yaml - request: - url: https://mcp.example.com/mcp - method: POST - headers: - Authorization: Bearer - User-Agent: openstatus - Accept: application/json, text/event-stream - Content-Type: application/json +```terraform +variable "mcp_token" { + type = string + sensitive = true +} + +resource "openstatus_http_monitor" "mcp_server" { + # ... + + headers { + key = "Authorization" + value = "Bearer ${var.mcp_token}" + } +} ``` Two things to plan for: -- **Token rotation is the most common false alarm.** When the token expires, the monitor goes down while the server is perfectly healthy. Assert on `statusCode` `eq` `200` so a `401` fails loudly and is easy to recognise, rather than debugging it as an outage. -- **Keep the credential out of your repository.** This YAML is meant to be version-controlled, so use a token scoped to read-only health checks — not a production credential — and rotate it on a schedule you control. +- **Token rotation is the most common false alarm.** When the token expires, the monitor goes down while the server is perfectly healthy. Assert on the status code being `200` so a `401` fails loudly and is easy to recognise, rather than debugging it as an outage. +- **Keep the credential out of your repository.** Mark the variable `sensitive` and pass it in with `TF_VAR_mcp_token` or from a secrets manager. Use a token scoped to read-only health checks — not a production credential — and rotate it on a schedule you control. If you are unsure which authorization server issues your token, the [health check tool](/play/mcp-health) parses the `WWW-Authenticate` challenge and surfaces the OAuth resource metadata for you. @@ -143,35 +151,43 @@ A `ping` proves the server is answering. It does not prove the server still expo Add a second monitor that calls `tools/list` and asserts a known tool name is present: -```yaml -mcp-tools: - name: "MCP tools/list" - description: "Verify the MCP server still exposes its tools" - frequency: "5m" - active: true - regions: ["iad", "ams", "sin"] - retry: 3 - kind: http - request: - url: https://hf.co/mcp - method: POST - body: > - { - "jsonrpc": "2.0", - "id": "openstatus", - "method": "tools/list" - } - headers: - User-Agent: openstatus - Accept: application/json, text/event-stream - Content-Type: application/json - assertions: - - kind: statusCode - compare: eq - target: 200 - - kind: textBody - compare: contains - target: "your_tool_name" +```terraform +resource "openstatus_http_monitor" "mcp_tools" { + name = "MCP tools/list" + description = "Verify the MCP server still exposes its tools" + url = "https://hf.co/mcp" + method = "POST" + periodicity = "5m" + active = true + retry = 3 + regions = ["fly-iad", "fly-ams", "fly-sin"] + + body = jsonencode({ + jsonrpc = "2.0" + id = "openstatus" + method = "tools/list" + }) + + headers { + key = "Content-Type" + value = "application/json" + } + + headers { + key = "Accept" + value = "application/json, text/event-stream" + } + + status_code_assertions { + target = 200 + comparator = "eq" + } + + body_assertions { + target = "your_tool_name" + comparator = "contains" + } +} ``` Assert on the bare tool name, not on `"name":"your_tool_name"`. `contains` matches literally, and servers differ in whether they emit a space after the JSON key — an assertion written against the compact form fails the moment a server pretty-prints its response. @@ -183,7 +199,7 @@ Assert on the bare tool name, not on `"name":"your_tool_name"`. `contains` match Not every MCP failure deserves the same response: - **`ping` failing across all regions** — the server is down. Alert immediately. -- **`ping` failing in one region** — usually a network path problem rather than your server. Retries handle most of these, which is what `retry: 3` is for. +- **`ping` failing in one region** — usually a network path problem rather than your server. Retries handle most of these, which is what `retry = 3` is for. - **`401` after a period of `200`s** — a rotated or expired token. This is a credentials problem, not an outage. - **`tools/list` succeeding but missing a tool** — a deploy removed or renamed a tool. Nothing is "down", but your agents are already broken. - **Latency climbing on `tools/list` while `ping` stays flat** — the server is under load in its application layer rather than its network layer. @@ -195,7 +211,7 @@ Not every MCP failure deserves the same response: - Handled authenticated endpoints without turning token rotation into a false outage - Added a `tools/list` check so a missing tool is caught before your agents hit it - Set up global monitoring to detect localised or widespread issues -- Automated monitor deployment using a version-controlled YAML configuration +- Declared both monitors in Terraform, so they are reviewable and reproducible Both monitors run on [openstatus uptime monitoring](/uptime-monitoring) from up to 28 regions, with alerting and history — so a broken handshake reaches you before it reaches the agents depending on it. @@ -209,4 +225,4 @@ Both monitors run on [openstatus uptime monitoring](/uptime-monitoring) from up - **[JSON-RPC 2.0 specification](https://www.jsonrpc.org/specification)** — deep dive into the JSON-RPC protocol. - **[MCP official documentation](https://modelcontextprotocol.io/docs/concepts/architecture#debugging-and-monitoring)** — official insights into MCP health checks. - **[HTTP monitor reference](/docs/reference/http-monitor)** — comprehensive reference for HTTP monitors. -- **[CLI reference](/docs/reference/cli-reference)** — full documentation for the openstatus CLI. +- **[Terraform provider reference](/docs/reference/terraform)** — every resource, argument, and block. diff --git a/apps/web/src/content/pages/docs/guides/how-to-use-react-widget.mdx b/apps/web/src/content/pages/docs/guides/how-to-use-react-widget.mdx index 1782c792..65e2681c 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-use-react-widget.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-use-react-widget.mdx @@ -89,7 +89,9 @@ async function CustomStatusWidget() { ### Pointing at a self-hosted API Both `getStatus` and `StatusWidget` call `https://api.openstatus.dev` by default. If you self-host -openstatus, set `OPENSTATUS_API_URL` on the server, or pass the base URL as the second argument: +openstatus, set `OPENSTATUS_API_URL` on the server — that is the only lever for `StatusWidget`, +which takes just `slug` and `href`. `getStatus` additionally accepts the base URL as a second +argument: ```tsx const res = await getStatus("slug", "https://api.status.example.com"); diff --git a/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx b/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx index 6b206ceb..90ecd8f1 100644 --- a/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx +++ b/apps/web/src/content/pages/docs/guides/self-host-status-page-only.mdx @@ -125,11 +125,18 @@ If you need automated monitoring, follow the [full self-hosting guide](/docs/gui 5. **Set workspace limits** - Because this is a self-hosted instance, you need to manually set the feature limits for your workspace directly in the database. The following command updates the limits for the workspace with `id = 1`: + Because this is a self-hosted instance, you need to manually set the feature limits for your workspace directly in the database. + + Every key you leave out falls back to its **free-plan default**, not to "unlimited" — a + partial payload silently caps the workspace at 3 page components, 6 regions, and no OTLP export, + screenshots, response logs, custom theme, or translations. The block below sets every key the + current `limitsSchema` (`packages/db/src/schema/plan/schema.ts`) defines, so nothing falls + through. Change the `WHERE id = 1` at the end if your workspace has a different ID. ```bash - curl -X POST http://localhost:8080/ -H "Content-Type: application/json" \ - -d '{"statements":["UPDATE workspace SET limits = '\''{\\"monitors\\":100,\\"periodicity\\":[\\"30s\\",\\"1m\\",\\"5m\\",\\"10m\\",\\"30m\\",\\"1h\\"],\\"multi-region\\":true,\\"data-retention\\":\\"24 months\\",\\"status-pages\\":20,\\"maintenance\\":true,\\"status-subscribers\\":true,\\"custom-domain\\":true,\\"password-protection\\":true,\\"white-label\\":true,\\"notifications\\":true,\\"sms\\":true,\\"pagerduty\\":true,\\"notification-channels\\":50,\\"members\\":\\"Unlimited\\",\\"audit-log\\":true,\\"private-locations\\":true}'\'' WHERE id = 1"]}' + curl -sS -X POST http://localhost:8080/ -H "Content-Type: application/json" -d @- <<'JSON' + {"statements":["UPDATE workspace SET limits = '{\"monitors\":100,\"synthetic-checks\":100000,\"periodicity\":[\"30s\",\"1m\",\"5m\",\"10m\",\"30m\",\"1h\"],\"multi-region\":true,\"max-regions\":28,\"data-retention\":\"24 months\",\"regions\":[\"ams\",\"arn\",\"bom\",\"cdg\",\"dfw\",\"ewr\",\"fra\",\"gru\",\"iad\",\"jnb\",\"lax\",\"lhr\",\"nrt\",\"ord\",\"sjc\",\"sin\",\"syd\",\"yyz\",\"koyeb_fra\",\"koyeb_was\",\"koyeb_sin\",\"koyeb_tyo\",\"koyeb_par\",\"koyeb_sfo\",\"railway_europe-west4-drams3a\",\"railway_us-east4-eqdc4a\",\"railway_asia-southeast1-eqsg3a\",\"railway_us-west2\"],\"private-locations\":true,\"screenshots\":true,\"response-logs\":true,\"otel\":true,\"status-pages\":20,\"page-components\":500,\"maintenance\":true,\"monitor-values-visibility\":true,\"uptime-history\":true,\"status-subscribers\":true,\"custom-domain\":true,\"i18n\":true,\"password-protection\":true,\"email-domain-protection\":true,\"ip-restriction\":true,\"white-label\":true,\"no-index\":true,\"custom-theme\":true,\"notifications\":true,\"pagerduty\":true,\"opsgenie\":true,\"grafana-oncall\":true,\"whatsapp\":true,\"sms\":true,\"sms-limit\":1000,\"notification-channels\":50,\"members\":\"Unlimited\",\"audit-log\":true,\"sso\":true,\"slack-agent\":true}' WHERE id = 1"]} + JSON ``` You can find your workspace ID by querying the database: 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 da7f9e56..bef43ba7 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 @@ -205,10 +205,16 @@ Now that the services are running, you can access the dashboard and perform the - Sign up and create a new workspace. - Because this is a self-hosted instance, you need to manually set the feature limits for your workspace directly in the database. - The following command updates the limits for the workspace with `id = 1`. If your workspace has a different ID, change the `WHERE id = 1` part of the command. + Every key you leave out falls back to its **free-plan default**, not to "unlimited" — a + partial payload silently caps the workspace at 3 page components, 6 regions, and no OTLP export, + screenshots, response logs, custom theme, or translations. The block below sets every key the + current `limitsSchema` (`packages/db/src/schema/plan/schema.ts`) defines, so nothing falls + through. Change the `WHERE id = 1` at the end if your workspace has a different ID. + ```bash - curl -X POST http://localhost:8080/ -H "Content-Type: application/json" \ - -d '{"statements":["UPDATE workspace SET limits = '\''{\\"monitors\\":100,\\"periodicity\\":[\\"30s\\",\\"1m\\",\\"5m\\",\\"10m\\",\\"30m\\",\\"1h\\"],\\"multi-region\\":true,\\"data-retention\\":\\"24 months\\",\\"status-pages\\":20,\\"maintenance\\":true,\\"status-subscribers\\":true,\\"custom-domain\\":true,\\"password-protection\\":true,\\"white-label\\":true,\\"notifications\\":true,\\"sms\\":true,\\"pagerduty\\":true,\\"notification-channels\\":50,\\"members\\":\\"Unlimited\\",\\"audit-log\\":true,\\"private-locations\\":true}'\'' WHERE id = 1"]}' + curl -sS -X POST http://localhost:8080/ -H "Content-Type: application/json" -d @- <<'JSON' + {"statements":["UPDATE workspace SET limits = '{\"monitors\":100,\"synthetic-checks\":100000,\"periodicity\":[\"30s\",\"1m\",\"5m\",\"10m\",\"30m\",\"1h\"],\"multi-region\":true,\"max-regions\":28,\"data-retention\":\"24 months\",\"regions\":[\"ams\",\"arn\",\"bom\",\"cdg\",\"dfw\",\"ewr\",\"fra\",\"gru\",\"iad\",\"jnb\",\"lax\",\"lhr\",\"nrt\",\"ord\",\"sjc\",\"sin\",\"syd\",\"yyz\",\"koyeb_fra\",\"koyeb_was\",\"koyeb_sin\",\"koyeb_tyo\",\"koyeb_par\",\"koyeb_sfo\",\"railway_europe-west4-drams3a\",\"railway_us-east4-eqdc4a\",\"railway_asia-southeast1-eqsg3a\",\"railway_us-west2\"],\"private-locations\":true,\"screenshots\":true,\"response-logs\":true,\"otel\":true,\"status-pages\":20,\"page-components\":500,\"maintenance\":true,\"monitor-values-visibility\":true,\"uptime-history\":true,\"status-subscribers\":true,\"custom-domain\":true,\"i18n\":true,\"password-protection\":true,\"email-domain-protection\":true,\"ip-restriction\":true,\"white-label\":true,\"no-index\":true,\"custom-theme\":true,\"notifications\":true,\"pagerduty\":true,\"opsgenie\":true,\"grafana-oncall\":true,\"whatsapp\":true,\"sms\":true,\"sms-limit\":1000,\"notification-channels\":50,\"members\":\"Unlimited\",\"audit-log\":true,\"sso\":true,\"slack-agent\":true}' WHERE id = 1"]} + JSON ``` You can find your workspace ID by inspecting the database with a command like `curl -X POST http://localhost:8080/ -H "Content-Type: application/json" -d '{"statements":["SELECT id, name FROM workspace"]}'`. @@ -239,7 +245,7 @@ Now that the services are running, you can access the dashboard and perform the The two environment variables are: - - `OPENSTATUS_KEY` — the key you copied from the dashboard. Some older docs call this `OPENSTATUS_TOKEN`; that name is not read by the probe. + - `OPENSTATUS_KEY` — the key you copied from the dashboard. Some older docs call this `OPENSTATUS_TOKEN`; that name is not read by the probe, which exits on startup with `OPENSTATUS_KEY is required` if the variable is unset. - `OPENSTATUS_INGEST_URL` — the URL of your **ingest server**, i.e. the `private-location` service on port **8081**. If you don't set it, the probe defaults to openstatus Cloud (`https://openstatus-private-location.fly.dev`) and your self-hosted instance will never see a check. If you run the probe on the same Docker network as the rest of the stack, use the internal address instead — `http://private-location:8080`. 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 86e0b038..98f1639b 100644 --- a/apps/web/src/content/pages/docs/reference/http-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/http-monitor.mdx @@ -191,10 +191,16 @@ compared as a string, using the same comparators as body assertions. A body that fails to parse as JSON fails the assertion. -