From 73f1465560d5dbb992c588db2a75f6071dba6483 Mon Sep 17 00:00:00 2001 From: Thibault Le Ouay Ducasse Date: Mon, 19 Oct 2026 16:43:40 +0200 Subject: [PATCH] docs: fix docs accuracy --- .../docs/concept/latency-vs-response-time.mdx | 4 +- .../concept/status-reports-and-incidents.mdx | 4 +- .../concept/uptime-calculation-and-values.mdx | 14 +- .../pages/docs/concept/uptime-monitoring.mdx | 2 +- .../how-deploy-status-page-cf-pages.mdx | 57 ++- .../docs/guides/how-to-import-status-page.mdx | 6 +- .../docs/guides/how-to-monitor-mcp-server.mdx | 4 +- .../pages/docs/reference/cli-reference.mdx | 452 ++++++++++++++++-- .../pages/docs/reference/dns-monitor.mdx | 2 +- .../pages/docs/reference/grpc-monitor.mdx | 2 +- .../pages/docs/reference/http-monitor.mdx | 2 +- .../pages/docs/reference/icmp-monitor.mdx | 2 +- .../content/pages/docs/reference/location.mdx | 1 - .../pages/docs/reference/mcp-server.mdx | 6 +- .../pages/docs/reference/page-components.mdx | 5 +- .../pages/docs/reference/subscriber.mdx | 12 +- .../pages/docs/reference/tcp-monitor.mdx | 2 +- .../pages/docs/reference/terraform.mdx | 4 +- .../pages/docs/sdk/nodejs/getting-started.mdx | 4 + .../pages/docs/sdk/nodejs/monitor-service.mdx | 8 +- .../pages/docs/sdk/nodejs/overview.mdx | 2 +- .../pages/docs/sdk/nodejs/reference.mdx | 5 +- .../pages/docs/sdk/nodejs/typescript-tips.mdx | 8 +- .../content/pages/docs/sdk/php/overview.mdx | 2 +- .../pages/docs/sdk/python/overview.mdx | 2 +- .../tutorial/create-your-first-monitor.mdx | 2 +- 26 files changed, 497 insertions(+), 117 deletions(-) diff --git a/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx b/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx index aa959aad3..ae3e4c45e 100644 --- a/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx +++ b/apps/web/src/content/pages/docs/concept/latency-vs-response-time.mdx @@ -150,7 +150,7 @@ By monitoring both metrics, you can quickly pinpoint whether a performance slowd You need two things: the phase breakdown, and more than one vantage point. **For a single check right now**, run the URL through the -[global speed test](/play/checker). It requests from 28 regions in parallel and +[global speed test](/play/checker). It requests from 27 regions in parallel and returns all five phases per region, which is enough to tell a distance problem from an application problem in one pass. No account required. @@ -186,7 +186,7 @@ Latency and response time are the raw measurements. These build on top of them: ## Next steps -- **[Run a one-off speed test](/play/checker)** — see the timing breakdown for your own URL from 28 regions, no account needed. +- **[Run a one-off speed test](/play/checker)** — see the timing breakdown for your own URL from 27 regions, no account needed. - **[Create your first monitor](/docs/tutorial/create-your-first-monitor)** — start tracking these metrics. - **[Understanding uptime monitoring](/docs/concept/uptime-monitoring)** — broader monitoring concepts. - **[Response logs and data retention](/docs/concept/response-logs-and-retention)** — where the per-phase timing shows up for every check. diff --git a/apps/web/src/content/pages/docs/concept/status-reports-and-incidents.mdx b/apps/web/src/content/pages/docs/concept/status-reports-and-incidents.mdx index ee1cdaa15..5b432491a 100644 --- a/apps/web/src/content/pages/docs/concept/status-reports-and-incidents.mdx +++ b/apps/web/src/content/pages/docs/concept/status-reports-and-incidents.mdx @@ -60,7 +60,7 @@ Each update can declare a per-component impact — `degraded_performance`, `part - A component's current impact is whatever the **latest update naming it** said. Components you omit from an update keep their previous impact — you only declare what changed. - Resolving the report sets every still-affected component back to `operational`, so the page clears deterministically. -- On status pages using the [Reports only status source](/docs/concept/uptime-calculation-and-values#reports-only), impacts also weight the uptime percentage: a major outage counts fully against uptime, a partial outage counts half, and degraded performance not at all. +- Impacts also weight the uptime percentage on status pages using the [Reports only status source](/docs/concept/uptime-calculation-and-values#reports-only) or [Monitor checks with Time per status](/docs/concept/uptime-calculation-and-values#time-per-status): a major outage counts fully against uptime, a partial outage counts half, and degraded performance not at all. The [Status report reference](/docs/reference/status-report) covers the exact impact semantics and weights. @@ -89,7 +89,7 @@ If planned work goes sideways and overruns or breaks something, escalate: publis | Scoped to | A monitor | A status page + components | A status page + components | | Audience | Your team | Your users | Your users | | Timing | When detection fires | During/after the event | Announced before the event | -| Affects uptime | Yes — failed checks count | Only with Reports only status source, via impacts | Never | +| Affects uptime | Yes — failed checks count | Via impacts, with Reports only or Time per status | Never | | Resolved by | Acknowledge/resolve, or auto-resolve | A `resolved` update | The window ending | On the status page itself, when several apply to one component, the worst wins: an active incident (error) outranks an unresolved status report (degraded), which outranks maintenance (info), which outranks operational. diff --git a/apps/web/src/content/pages/docs/concept/uptime-calculation-and-values.mdx b/apps/web/src/content/pages/docs/concept/uptime-calculation-and-values.mdx index b31001ccb..d39986f60 100644 --- a/apps/web/src/content/pages/docs/concept/uptime-calculation-and-values.mdx +++ b/apps/web/src/content/pages/docs/concept/uptime-calculation-and-values.mdx @@ -27,7 +27,7 @@ In the dashboard, two settings on the status page's **Components** page control | Setting | Source of truth | What users see | Best for | |-------------|----------------------|-------------------------------------|----------------------------------| -| **Monitor checks** + **Time per status** | Incident duration | Time-based uptime, proportional colours | Accurate long-term view | +| **Monitor checks** + **Time per status** | Incidents and report impacts | Time-based uptime, proportional colours | Accurate long-term view | | **Monitor checks** + **Number of checks** | Every check result | Check-based uptime % | Real-time reflection | | **Reports only** | Your status reports and maintenances | Controlled, narrative updates | Transparency without monitoring | @@ -37,11 +37,17 @@ With **Monitor checks** as the status source (`absolute`), uptime is calculated ### Time per status -The time per status value (`duration`) is calculated from the **total monitoring time and the duration of incidents**. +The time per status value (`duration`) is calculated from the **total monitoring time and the downtime recorded by incidents and status reports**. -In simple terms: `uptime = (total time - incident duration) / total time` +In simple terms: `uptime = (total time - downtime) / total time` -This means uptime is based on how long something was down, not how many checks failed. Only incident durations are included in the calculation. +This means uptime is based on how long something was down, not how many checks failed. Downtime combines: + +- **Incidents**, which count fully. +- **Status report impacts**, weighted by severity: a major outage counts fully, a partial outage counts half, and degraded performance not at all. Reports without per-component impacts are ignored in this mode. +- **Probe errors**, only for monitors that run exclusively from [private locations](/docs/concept/private-locations). + +Overlapping periods are merged, so an incident and a status report describing the same outage count once. Temporary single-region ping failures (e.g., one location failing once, sometimes this just happens) are not propagated to users — because these often don't represent a real outage. That's also why we recommend at least three locations per monitor for redundancy. diff --git a/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx b/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx index ea770dbe8..60d71d24b 100644 --- a/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx +++ b/apps/web/src/content/pages/docs/concept/uptime-monitoring.mdx @@ -80,7 +80,7 @@ Uptime monitoring typically involves a monitoring agent that periodically sends - If the service responds with a successful status code (e.g., 200 OK), it's considered up. -- If the service returns an error code, a timeout, or no response, the agent will perform a re-check from a different location to confirm the outage. This helps prevent false alarms caused by temporary network glitches. +- If the service returns an error code, a timeout, or no response, the agent retries the check from the same location. With openstatus, the outage is then confirmed across locations: an incident opens only when at least half of the monitor's regions report a failure. This helps prevent false alarms caused by temporary network glitches. - Upon confirmation, the system triggers an alert, notifying the relevant team members. The monitoring system will continue to check the service until it's back online, at which point a recovery alert is often sent. 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 a3bf8f6fb..7143d5f83 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 @@ -1,9 +1,9 @@ --- category: Guides -title: How to Deploy a Status Page to Cloudflare Pages -description: Learn how to use openstatus monitoring data to deploy a status page on Cloudflare Pages. +title: How to Deploy a Status Page to Cloudflare Workers +description: Learn how to use openstatus monitoring data to deploy a status page on Cloudflare Workers. sidebar: - label: Host your status page on Cloudflare Pages + label: Host your status page on Cloudflare Workers --- ## Problem @@ -12,7 +12,7 @@ You need a fast, reliable, and automated status page, but you don't want to mana ## Solution -Deploy a custom status page to Cloudflare's global edge network using openstatus as the data source. This guide shows you how to use our Astro-based template to create a status page that automatically reflects your monitoring data. +Deploy a custom status page to Cloudflare's global edge network using openstatus as the data source. This guide shows you how to use our Astro-based template to create a status page that automatically reflects your openstatus status page. The code for the template is available on [GitHub](https://github.com/openstatusHQ/astro-status-page). @@ -24,19 +24,23 @@ The code for the template is available on [GitHub](https://github.com/openstatus ## Prerequisites - A Cloudflare account -- An [openstatus account](https://www.openstatus.dev) with at least one monitor configured. +- An [openstatus account](https://www.openstatus.dev) with at least one status page configured. ## Step-by-step guide ### 1. Get your openstatus API key -First, you need an API key to fetch your monitoring data. +First, you need an API key to fetch your status page data. 1. Navigate to your openstatus dashboard. 2. Go to **Settings** > **General** and find the **API Keys** card. 3. Click **Create** and copy the key. -### 2. Set up the Astro project +### 2. Find your status page ID + +The template renders one of your openstatus status pages. Open the status page in the openstatus dashboard and copy the ID from the URL (`/status-pages/[ID]`). + +### 3. Set up the Astro project Clone our status page template and install the dependencies. @@ -46,33 +50,38 @@ cd astro-status-page pnpm install ``` -### 3. Customize the status page +### 4. Run it locally -You need to specify which monitors to display on your page. +The template reads two secrets: `API_KEY` and `STATUS_PAGE_ID`. For local development, put them in a `.dev.vars` file. -1. Open the `src/pages/index.astro` file. -2. Find the following line of code: - ```javascript - const monitorIds = [1] +1. Copy `.dev.vars.example` to `.dev.vars`. +2. Fill in both values: + ```bash + API_KEY=your_openstatus_api_key + STATUS_PAGE_ID=your_status_page_id + ``` +3. Start the dev server: + ```bash + pnpm dev ``` -3. Replace the `1` with the ID of the monitor you want to display. You can find the monitor ID in the URL when you view a monitor in the openstatus dashboard (`/monitors/[ID]`). You can also add multiple IDs: `[1, 2, 5]`. -### 4. Configure your Cloudflare environment variable +### 5. Set your secrets on Cloudflare -Before deploying, you must provide your openstatus API key to Cloudflare. +Before deploying, provide both secrets to your Worker: + +```bash +npx wrangler secret put API_KEY +npx wrangler secret put STATUS_PAGE_ID +``` -1. Go to your Cloudflare dashboard and click on **Workers & Pages**. -2. Select your site and go to the **Settings** tab. -3. Navigate to **Environment variables** and add a new variable: - - **Variable name** — `API_KEY`. - - **Value** — paste your openstatus API key here. +Wrangler prompts you for each value. -### 5. Deploy to Cloudflare Pages +### 6. Deploy to Cloudflare Workers Now you can deploy your status page. ```bash -pnpm run pages:deploy +pnpm run deploy ``` -After the command completes, your status page will be live on Cloudflare Pages. +After the command completes, your status page will be live on Cloudflare Workers. To upload a preview version without promoting it, run `pnpm run deploy:preview`. 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 13da25128..443b9cf52 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 @@ -125,15 +125,15 @@ openstatus plans have caps on the number of components and monitors. If your imp ### Partial import -If the import succeeds for some phases but fails for others (for example, components import successfully but incidents fail due to a rate limit or timeout), the successfully imported resources remain in place. Fix the underlying issue and re-run the import. Only the failed phases will be retried; already-imported resources are not duplicated. +If the import succeeds for some phases but fails for others (for example, components import successfully but incidents fail due to a rate limit or timeout), the successfully imported resources remain in place. Fix the underlying issue and re-run the import. The whole import runs again, but resources that already exist are skipped, so nothing is duplicated. -### Duplicate incidents on re-import +### Re-importing incidents and maintenances -Running the import a second time does not deduplicate incidents or maintenances. If you need to re-import, delete the previously imported records first to avoid duplicate entries appearing on your status page. +Running the import a second time does not create duplicates. An incident is skipped when a status report with the same title and first update date already exists on the page; a maintenance is skipped when one with the same title, start, and end already exists. If you renamed an imported incident or maintenance in openstatus, the next import treats it as new. ## What's next 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 19213558d..d2c132af4 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-monitor-mcp-server.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-monitor-mcp-server.mdx @@ -1,7 +1,7 @@ --- category: Guides title: How to Monitor an MCP Server -description: Monitor an MCP server with openstatus - JSON-RPC health checks, tools/list assertions, authenticated endpoints, and uptime alerts from 28 regions. +description: Monitor an MCP server with openstatus - JSON-RPC health checks, tools/list assertions, authenticated endpoints, and uptime alerts from 27 regions. seo: title: "How to Monitor an MCP Server - Health Checks & Uptime" sidebar: @@ -213,7 +213,7 @@ Not every MCP failure deserves the same response: - Set up global monitoring to detect localised or widespread issues - 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. +Both monitors run on [openstatus uptime monitoring](/uptime-monitoring) from up to 27 regions, with alerting and history — so a broken handshake reaches you before it reaches the agents depending on it. ## What's next 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 abd23df2b..639918f28 100644 --- a/apps/web/src/content/pages/docs/reference/cli-reference.mdx +++ b/apps/web/src/content/pages/docs/reference/cli-reference.mdx @@ -23,7 +23,7 @@ Global flags: ## `check` command (aliases: `c`) -Run an HTTP check against a URL from 28 global regions. +Run an HTTP check against a URL from 27 global regions. > openstatus check `` > openstatus check https://openstat.us @@ -32,7 +32,7 @@ Run an HTTP check against a URL from 28 global regions. > openstatus check https://openstat.us --timing > openstatus check https://openstat.us --json | jq '.summary' -Run a one-shot HTTP check against a URL from 28 global regions. The check is executed by the public openstatus speed checker. No API token is required. Results stream to the terminal as they arrive from each region. Output is sorted in the order regions report back (roughly fastest first). Pass `--timing` to see DNS/Connection/TLS/TTFB/Transfer phase breakdowns. Pass `--json` for a machine-readable single object including all phase data. Rate limits: 3 requests per 60 seconds and 10 requests per hour, both per IP. +Run a one-shot HTTP check against a URL from 27 global regions. The check is executed by the public openstatus speed checker. No API token is required. Results stream to the terminal as they arrive from each region. Output is sorted in the order regions report back (roughly fastest first). Pass `--timing` to see DNS/Connection/TLS/TTFB/Transfer phase breakdowns. Pass `--json` for a machine-readable single object including all phase data. Rate limits: 3 requests per 60 seconds and 10 requests per hour, both per IP. Usage: @@ -69,6 +69,8 @@ Create or update monitors. Creates or updates monitors according to the openstatus configuration file. Compares your openstatus.yaml with the current state and applies changes. +> **Deprecated:** prefer managing your monitors with Terraform via [`openstatus terraform generate`](#terraform-generate-subcommand-aliases-gen). + Usage: ```bash @@ -84,49 +86,6 @@ The following flags are supported: | `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | | `--dry-run` (`-n`) | Show what would be changed without applying | bool | `false` | *none* | -### `monitors create` subcommand - -Create monitors. - -> openstatus monitors create -> openstatus monitors create --config custom.yaml -y - -Create the monitors defined in the openstatus.yaml file. - -Usage: - -```bash -$ openstatus [GLOBAL FLAGS] monitors create [COMMAND FLAGS] [ARGUMENTS...] -``` - -The following flags are supported: - -| Name | Description | Type | Default value | Environment variables | -|-----------------------------|-------------------------------------------------------|--------|:-------------------:|:----------------------:| -| `--config="…"` (`-c`) | The configuration file containing monitor information | string | `"openstatus.yaml"` | *none* | -| `--access-token="…"` (`-t`) | openstatus API Access Token | string | | `OPENSTATUS_API_TOKEN` | -| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | - -### `monitors delete` subcommand - -Delete a monitor. - -> openstatus monitors delete `` -> openstatus monitors delete 12345 -y - -Usage: - -```bash -$ openstatus [GLOBAL FLAGS] monitors delete [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` | -| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | - ### `monitors import` subcommand Import all your monitors. @@ -134,7 +93,9 @@ Import all your monitors. > openstatus monitors import > openstatus monitors import --output monitors.yaml -Import all your monitors from your workspace to a YAML file; it will also create a lock file to manage your monitors with 'apply'. +Import all your monitors from your workspace to a YAML file; it will also create a lock file to manage your monitors with `apply`. + +> **Deprecated:** the monitors.yaml config file is deprecated for import. Prefer managing your monitors with Terraform via [`openstatus terraform generate`](#terraform-generate-subcommand-aliases-gen). Usage: @@ -339,6 +300,7 @@ The following flags are supported: | `--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* | +| `--incident-id="…"` | ID of an incident to link the report to | string | | *none* | ### `status-report update` subcommand @@ -400,8 +362,406 @@ The following flags are supported: | `--status="…"` | New status (investigating, identified, monitoring, resolved) | string | | *none* | | `--message="…"` | Message describing what changed | string | | *none* | | `--date="…"` | Date for the update (RFC 3339 format, defaults to now) | string | | *none* | +| `--impact="…"` | Per-component impact, repeatable: `--impact =` (level: operational, degraded, partial_outage, major_outage). Can also add new affected components | string | | *none* | | `--notify` | Notify subscribers about this update | bool | `false` | *none* | +## `incident` command (aliases: `inc`, `incidents`) + +Declare and run incidents. + +Incidents are the internal response to an outage: severity, commander, lifecycle (open -> mitigated -> resolved, or canceled), timeline notes, a linked public status report and the postmortem. Use `openstatus status-report` for the public communication on a status page. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident [ARGUMENTS...] +``` + +### `incident list` subcommand + +List incidents. + +> openstatus incident list +> openstatus inc list --active +> openstatus inc list --status open,mitigated --limit 10 + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident 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` | +| `--status="…"` | Filter by status, comma-separated (open, mitigated, resolved, canceled) | string | | *none* | +| `--active` | Only incidents that are not closed | bool | `false` | *none* | +| `--closed` | Only closed incidents | bool | `false` | *none* | +| `--limit="…"` | Maximum number of incidents to return (1-100, defaults to 50) | int | `0` | *none* | +| `--offset="…"` | Number of incidents to skip | int | `0` | *none* | + +### `incident info` subcommand + +Get incident details and timeline. + +> openstatus incident info `` +> openstatus inc info 42 + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident 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` | + +### `incident declare` subcommand (aliases: `create`) + +Declare a new incident. + +> openstatus incident declare --title "Checkout API returns 502" --severity major +> openstatus inc declare --title "Database down" --severity critical --commander jane@example.com --slack +> ID=$(openstatus inc declare --title "Login errors" --severity minor -q) + +Declare a new incident in the open status. Run without --title or --severity in an interactive terminal to be prompted. In scripts, pass every required flag. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident declare [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` | +| `--title="…"` | Title of the incident (1-256 characters) | string | | *none* | +| `--severity="…"` | Severity of the incident (critical, major, minor) | string | | *none* | +| `--summary="…"` | Short human summary | string | | *none* | +| `--commander="…"` | Email of the workspace member leading the response | string | | *none* | +| `--started-at="…"` | When the impact began (RFC 3339, defaults to now) | string | | *none* | +| `--status-report-id="…"` | ID of an existing status report to link | string | | *none* | +| `--slack` | Open a dedicated Slack channel when Slack is connected | bool | `false` | *none* | + +### `incident update` subcommand + +Edit an incident's title, severity, summary, commander or start time. + +> openstatus incident update `` [flags] +> openstatus inc update 42 --severity critical +> openstatus inc update 42 --commander jane@example.com +> openstatus inc update 42 --clear-summary + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident update [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` | +| `--title="…"` | New title (1-256 characters) | string | | *none* | +| `--severity="…"` | New severity (critical, major, minor) | string | | *none* | +| `--summary="…"` | New summary | string | | *none* | +| `--clear-summary` | Remove the summary | bool | `false` | *none* | +| `--commander="…"` | Email of the new commander | string | | *none* | +| `--clear-commander` | Unassign the commander | bool | `false` | *none* | +| `--started-at="…"` | New start of impact (RFC 3339) | string | | *none* | + +### `incident set-status` subcommand + +Move an incident to a new status. + +> openstatus incident set-status `` --status `` [--note "..."] +> openstatus inc set-status 42 --status mitigated --note "Rolled back the deploy" + +Allowed transitions: open -> mitigated, resolved or canceled; mitigated -> resolved, open or canceled; resolved -> open. Canceled is terminal and closes the incident. A linked status report is not updated: post the public update with `openstatus status-report add-update`. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident set-status [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` | +| `--status="…"` | Target status (open, mitigated, resolved, canceled) | string | | *none* | +| `--note="…"` | Note recorded on the timeline with the change | string | | *none* | +| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | + +### `incident mitigate` subcommand + +Mark an incident as mitigated. + +> openstatus incident mitigate `` [--note "..."] +> openstatus inc mitigate 42 --note "..." + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident mitigate [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` | +| `--note="…"` | Note recorded on the timeline with the change | string | | *none* | + +### `incident resolve` subcommand + +Mark an incident as resolved. + +> openstatus incident resolve `` [--note "..."] +> openstatus inc resolve 42 --note "..." + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident resolve [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` | +| `--note="…"` | Note recorded on the timeline with the change | string | | *none* | + +### `incident reopen` subcommand + +Reopen a mitigated or resolved incident. + +> openstatus incident reopen `` [--note "..."] +> openstatus inc reopen 42 --note "..." + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident reopen [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` | +| `--note="…"` | Note recorded on the timeline with the change | string | | *none* | + +### `incident cancel` subcommand + +Cancel an incident (closes it). + +> openstatus incident cancel `` [--note "..."] +> openstatus inc cancel 42 --note "..." + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident cancel [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` | +| `--note="…"` | Note recorded on the timeline with the change | string | | *none* | +| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | + +### `incident note` subcommand + +Add a note to an incident timeline. + +> openstatus incident note `` --message "Rolled back the deploy" +> echo "multi-line markdown" | openstatus inc note 42 --message - + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident note [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` | +| `--message="…"` (`-m`) | Note text in markdown (1-10000 characters); use - to read from stdin | string | | *none* | + +### `incident link-report` subcommand + +Link a public status report to an incident. + +> openstatus incident link-report `` `` +> openstatus inc link-report 42 123 + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident link-report [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` | + +### `incident unlink-report` subcommand + +Remove the link to an incident's status report. + +> openstatus incident unlink-report `` +> openstatus inc unlink-report 42 + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident unlink-report [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` | + +### `incident close` subcommand + +Close a resolved incident. + +> openstatus incident close `` +> openstatus inc close 42 --skip-postmortem -y + +Close a resolved incident. A closed incident is read-only except for its postmortem. Requires an approved postmortem, or --skip-postmortem. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident close [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` | +| `--skip-postmortem` | Close without an approved postmortem | bool | `false` | *none* | +| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | + +### `incident delete` subcommand + +Delete an incident declared by mistake. + +> openstatus incident delete `` +> openstatus inc delete 42 -y + +Delete an incident declared by mistake. Only allowed while the incident is open and was never mitigated, resolved or closed; cancel it otherwise. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident delete [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` | +| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | + +### `incident postmortem` subcommand (aliases: `pm`) + +Read, write and approve an incident's postmortem. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident postmortem [ARGUMENTS...] +``` + +### `incident postmortem show` subcommand + +Show the postmortem of an incident. + +> openstatus incident postmortem show `` +> openstatus inc pm show 42 > postmortem.md + +In a terminal, prints the review status and the markdown body through your pager. When piped, prints only the markdown body, so it can be edited and sent back with `openstatus inc pm edit --file postmortem.md`. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident postmortem show [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` | + +### `incident postmortem edit` subcommand + +Write or replace the postmortem of a resolved incident. + +> openstatus incident postmortem edit `` --file postmortem.md +> cat postmortem.md | openstatus inc pm edit 42 --file - +> openstatus inc pm edit 42 --content "## Summary ..." + +Replaces the whole markdown body. An approved postmortem stays approved. + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident postmortem edit [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` | +| `--file="…"` | Markdown file to upload; use - to read from stdin | string | | *none* | +| `--content="…"` | Markdown body passed inline | string | | *none* | + +### `incident postmortem approve` subcommand + +Approve the postmortem, optionally closing the incident. + +> openstatus incident postmortem approve `` +> openstatus inc pm approve 42 --close -y + +Usage: + +```bash +$ openstatus [GLOBAL FLAGS] incident postmortem approve [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` | +| `--close` | Also close the incident | bool | `false` | *none* | +| `--auto-accept` (`-y`) | Automatically accept the prompt | bool | `false` | *none* | + ## `maintenance` command (aliases: `mt`) Manage maintenance windows. 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 505942ba8..4b1535ecd 100644 --- a/apps/web/src/content/pages/docs/reference/dns-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/dns-monitor.mdx @@ -78,7 +78,7 @@ The duration after which a DNS response is considered degraded. This indicates a **Type:** Integer (optional) **Default:** `3` -The number of times the monitor will retry a failed DNS lookup before reporting a definitive failure. For example: `3` +The total number of lookup attempts made for each check, including the first one. With `3`, a failing lookup is tried up to three times in the same region before the check is reported as failed. `0` is treated as the default (`3`); there is no setting that disables retries, so `1` means a single attempt. ### Assertions diff --git a/apps/web/src/content/pages/docs/reference/grpc-monitor.mdx b/apps/web/src/content/pages/docs/reference/grpc-monitor.mdx index 2be8dba1a..79ee50b8f 100644 --- a/apps/web/src/content/pages/docs/reference/grpc-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/grpc-monitor.mdx @@ -128,7 +128,7 @@ The latency above which a `SERVING` response is recorded as degraded rather than **Type:** Integer (optional) **Default:** `3` -How many times a check is retried before reporting a definitive error. Only connection failures are retried: once the server has answered — including `NOT_SERVING` or `UNIMPLEMENTED` — the result is recorded immediately, because asking again cannot change it. +The total number of attempts made for each check, including the first one. `0` is treated as the default (`3`); there is no setting that disables retries, so `1` means a single attempt. Only connection failures trigger another attempt: once the server has answered — including `NOT_SERVING` or `UNIMPLEMENTED` — the result is recorded immediately, because asking again cannot change it. ### OpenTelemetry 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 d93b12a73..d7151066e 100644 --- a/apps/web/src/content/pages/docs/reference/http-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/http-monitor.mdx @@ -149,7 +149,7 @@ The duration after which the HTTP request is considered to be performing in a de **Default:** `3` **Range:** 0–10 -The number of times the monitor will automatically retry the HTTP request upon failure before reporting a definitive error. For example: `3` +The total number of attempts made for each check, including the first one. With `3`, a failing request is tried up to three times in the same region before the check is reported as failed. `0` is treated as the default (`3`); there is no setting that disables retries, so `1` means a single attempt. ### Follow redirects diff --git a/apps/web/src/content/pages/docs/reference/icmp-monitor.mdx b/apps/web/src/content/pages/docs/reference/icmp-monitor.mdx index 77f06f78d..0e50de809 100644 --- a/apps/web/src/content/pages/docs/reference/icmp-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/icmp-monitor.mdx @@ -74,7 +74,7 @@ The average latency after which a check is considered to be in a degraded perfor **Type:** Integer (optional) **Default:** `3` -The number of times the monitor retries a fully failed check (all packets lost) before reporting a definitive error. +The total number of attempts made for each check, including the first one. An attempt fails only when all packets are lost. `0` is treated as the default (`3`); there is no setting that disables retries, so `1` means a single attempt. ### OpenTelemetry diff --git a/apps/web/src/content/pages/docs/reference/location.mdx b/apps/web/src/content/pages/docs/reference/location.mdx index 5d46ec612..e0a3ecf06 100644 --- a/apps/web/src/content/pages/docs/reference/location.mdx +++ b/apps/web/src/content/pages/docs/reference/location.mdx @@ -37,7 +37,6 @@ Below is the complete list of regions used for monitoring, along with their asso |-------------|---------------|-------------------|-------------------|-------------------------------| | ams | `fly-ams` | Amsterdam | 209.71.64.1 | 2a09:8280:e601:1:0:22:b79b:0 | | arn | `fly-arn` | Stockholm | 209.71.98.189 | 2a09:8280:e602:1:0:22:b79b:0 | -| bom | `fly-bom` | Mumbai | 209.71.68.172 | 2a09:8280:e605:1:0:22:b79b:0 | | cdg | `fly-cdg` | Paris | 209.71.86.183 | 2a09:8280:e607:1:0:22:b79b:0 | | dfw | `fly-dfw` | Dallas | 209.71.71.89 | 2a09:8280:e609:1:0:22:b79b:0 | | ewr | `fly-ewr` | Secaucus, New Jersey | 209.71.69.221 | 2a09:8280:e610:1:0:22:b79b:0 | 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 d9ffa5a85..c0e3600a1 100644 --- a/apps/web/src/content/pages/docs/reference/mcp-server.mdx +++ b/apps/web/src/content/pages/docs/reference/mcp-server.mdx @@ -62,7 +62,7 @@ For AI agents that should only observe state — health summaries, paging on-cal ## Tools -The server exposes 29 tools (27 on plans without the `audit-log` feature), grouped by resource: 25 scoped to the workspace tied to your credential, plus 4 public content tools that read openstatus.dev pages on any credential and any scope (see [Content](#content)). Workspaces with incident management enabled get 10 more (see [Incidents](#incidents)). Mutations write to the audit log with `actor_type = "mcp"` (see [Audit log](#audit-log)). +The server exposes 39 tools (37 on plans without the `audit-log` feature), grouped by resource: 35 scoped to the workspace tied to your credential, plus 4 public content tools that read openstatus.dev pages on any credential and any scope (see [Content](#content)). Mutations write to the audit log with `actor_type = "mcp"` (see [Audit log](#audit-log)). ### Pages @@ -96,7 +96,7 @@ The server exposes 29 tools (27 on plans without the `audit-log` feature), group ### Incidents -Registered only when incident management is enabled for the workspace — otherwise these tools are absent from `tools/list`. They act on declared incidents, not on monitor downtime, and are internal: none of them publishes to a status page or notifies subscribers. See the [Incident management reference](/docs/reference/incident-management). +These tools act on declared incidents, not on monitor downtime, and are internal: none of them publishes to a status page or notifies subscribers. See the [Incident management reference](/docs/reference/incident-management). | Tool | Type | Purpose | |-----------------------|----------|---------| @@ -181,7 +181,7 @@ Notifications dispatch as part of the same call. There is no separate notify too The mutation and the notify dispatch are sequential, not transactional. The mutation persists first; if the notify step then throws (transient provider issue, partial outage of an integration), the response carries `notified: false` and the row stays. -`notified: true` means the dispatch call returned without throwing — **not** that every subscriber received a message. If the workspace plan doesn't include subscriber notifications, the service is a no-op: the maintenance tools report `notified: false`, the status report tools still report `notified: true`. Treat the field as "the dispatch ran cleanly," not as a delivery receipt. +`notified: true` means the dispatch call returned without throwing — **not** that every subscriber received a message. If the workspace plan doesn't include subscriber notifications, the service is a no-op and the tools report `notified: false`. Treat the field as "the dispatch ran cleanly," not as a delivery receipt. | Tool | What `notify: true` sends | |----------------------------|---------------------------| 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 fedf2cd52..765ddc02b 100644 --- a/apps/web/src/content/pages/docs/reference/page-components.mdx +++ b/apps/web/src/content/pages/docs/reference/page-components.mdx @@ -190,13 +190,14 @@ Page components can be affected by up to three types of events that influence th **Applies to:** monitor components only. -Incidents are automatically generated when a monitor detects a failure. They represent unplanned outages or degraded performance discovered through active monitoring. +Incidents are automatically generated when a monitor detects a failure. They represent unplanned outages discovered through active monitoring. **How incidents are created:** - Monitor check fails (connection timeout, HTTP error, DNS failure). - Monitor assertion fails (wrong status code, unexpected response body). -- Monitor reaches degraded threshold (response time too slow). + +A monitor that only crosses its degraded threshold (response time too slow) does not open an incident. **Status impact:** components with active incidents show an **error** status. This takes the highest priority in the status hierarchy. diff --git a/apps/web/src/content/pages/docs/reference/subscriber.mdx b/apps/web/src/content/pages/docs/reference/subscriber.mdx index fdf76bf34..50a3d124f 100644 --- a/apps/web/src/content/pages/docs/reference/subscriber.mdx +++ b/apps/web/src/content/pages/docs/reference/subscriber.mdx @@ -8,7 +8,7 @@ A subscriber in openstatus is an entity (typically a user or an integration) tha **Key functions of subscribers:** -- Receive automated alerts when monitor statuses change or incidents are updated. +- Receive updates when status reports are published or maintenance is scheduled. - Stay informed about service health without actively monitoring the status page. - Choose preferred notification channels for receiving updates. @@ -36,10 +36,9 @@ Webhook subscriptions are only created by the page owner from the dashboard. Sla ## Notification types received -Subscribers receive notifications for key events affecting the monitored services linked to the status page: +Subscribers receive notifications when you communicate on the status page: -- **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`). +- **Status report updates** — when a status report is created or a new update is posted to it (e.g., status changes from `investigating` to `identified`, `monitoring`, or `resolved`), if you choose to notify 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. @@ -50,7 +49,8 @@ Status page administrators can manage their subscriber lists, including: - **Viewing subscribers** — accessing a list of all active subscribers for a status page. - **Adding/removing subscribers** — manually adding or removing subscribers. -- **Communication** — sending ad-hoc notifications to the subscriber list (if supported by the platform). + +There is no ad-hoc broadcast: subscribers are only reached through status report updates and maintenance notifications. ## Adding subscribers from the dashboard @@ -91,7 +91,7 @@ Related commands, all run from the channel: - `/openstatus unsubscribe [status-page-url]` — stop updates. The URL is optional when the channel follows exactly one page. Each Slack message also ends with a *Manage with `/openstatus unsubscribe`* hint. - `/openstatus help` — show the command list. -Re-running `subscribe` on a channel that previously unsubscribed reactivates the existing subscription instead of creating a duplicate. Subscribing from Slack works against any page whose workspace is on a plan that includes subscribers; it does not require the channel's workspace to own the page. +Re-running `subscribe` on a channel that previously unsubscribed reactivates the existing subscription instead of creating a duplicate. Subscribing from Slack works against any **public** page whose workspace is on a plan that includes subscribers; it does not require the channel's workspace to own the page. Protected pages (password, email domain, or IP restriction) are rejected with "Protected status pages can't be subscribed to from Slack". For installation and the natural-language incident commands, see [Set up the openstatus Slack agent](/docs/guides/how-to-setup-slack-agent). 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 9c2cb32e9..769399766 100644 --- a/apps/web/src/content/pages/docs/reference/tcp-monitor.mdx +++ b/apps/web/src/content/pages/docs/reference/tcp-monitor.mdx @@ -74,7 +74,7 @@ The duration after which a TCP connection attempt is considered to be in a degra **Type:** Integer (optional) **Default:** `3` -The number of times the monitor will automatically retry a failed TCP connection attempt before reporting a definitive error. For example: `3` +The total number of connection attempts made for each check, including the first one. With `3`, a failing connection is tried up to three times in the same region before the check is reported as failed. `0` is treated as the default (`3`); there is no setting that disables retries, so `1` means a single attempt. ### OpenTelemetry diff --git a/apps/web/src/content/pages/docs/reference/terraform.mdx b/apps/web/src/content/pages/docs/reference/terraform.mdx index 66c75df71..49b4d152a 100644 --- a/apps/web/src/content/pages/docs/reference/terraform.mdx +++ b/apps/web/src/content/pages/docs/reference/terraform.mdx @@ -828,10 +828,10 @@ output "private_location_names" { ## Available Regions -Monitors can run from any of the following 28 regions: +Monitors can run from any of the following 27 regions: **Fly.io:** -`fly-ams`, `fly-arn`, `fly-bom`, `fly-cdg`, `fly-dfw`, `fly-ewr`, `fly-fra`, `fly-gru`, `fly-iad`, `fly-jnb`, `fly-lax`, `fly-lhr`, `fly-nrt`, `fly-ord`, `fly-sjc`, `fly-sin`, `fly-syd`, `fly-yyz` +`fly-ams`, `fly-arn`, `fly-cdg`, `fly-dfw`, `fly-ewr`, `fly-fra`, `fly-gru`, `fly-iad`, `fly-jnb`, `fly-lax`, `fly-lhr`, `fly-nrt`, `fly-ord`, `fly-sjc`, `fly-sin`, `fly-syd`, `fly-yyz` **Koyeb:** `koyeb-fra`, `koyeb-par`, `koyeb-sfo`, `koyeb-sin`, `koyeb-tyo`, `koyeb-was` 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 c15f07617..ef6c5ec5b 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 @@ -46,6 +46,7 @@ bun add @openstatus/sdk-node ```typescript import { createOpenStatusClient, + HTTPMethod, Periodicity, Region, } from "@openstatus/sdk-node"; @@ -59,6 +60,7 @@ const { monitor } = await client.monitor.v1.MonitorService.createHTTPMonitor({ monitor: { name: "My API", url: "https://api.example.com/health", + method: HTTPMethod.HTTP_METHOD_GET, periodicity: Periodicity.PERIODICITY_1M, regions: [Region.FLY_AMS, Region.FLY_IAD, Region.FLY_SYD], active: true, @@ -119,6 +121,7 @@ A complete example: create a monitor, set up a status page, add the monitor as a ```typescript import { createOpenStatusClient, + HTTPMethod, NotificationProvider, Periodicity, Region, @@ -137,6 +140,7 @@ const { monitor } = await client.monitor.v1.MonitorService.createHTTPMonitor({ monitor: { name: "Production API", url: "https://api.example.com/health", + method: HTTPMethod.HTTP_METHOD_GET, periodicity: Periodicity.PERIODICITY_1M, regions: [Region.FLY_AMS, Region.FLY_IAD, Region.FLY_SYD], active: true, 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 08be19694..f52868a0e 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 @@ -95,11 +95,11 @@ const { monitor } = await client.monitor.v1.MonitorService.updateHTTPMonitor({ | `name` | string | Yes | Monitor name (max 256 chars) | | `url` | string | Yes | URL to monitor (max 2048 chars) | | `periodicity` | Periodicity | Yes | Check interval | -| `method` | HTTPMethod | No | HTTP method (default: GET) | +| `method` | HTTPMethod | Yes | HTTP method, e.g. `HTTPMethod.HTTP_METHOD_GET` (`HTTP_METHOD_UNSPECIFIED` is rejected) | | `body` | string | No | Request body | | `headers` | Headers[] | No | Custom headers `{ key, value }[]` | | `timeout` | bigint | No | Timeout in ms (default: 45000, max: 120000) | -| `retry` | bigint | No | Retry attempts (default: 3, max: 10) | +| `retry` | bigint | No | Total check attempts, including the first (default: 3, max: 10) | | `followRedirects` | boolean | No | Follow redirects (default: true) | | `regions` | Region[] | No | Regions for checks | | `active` | boolean | No | Enable monitoring (default: false) | @@ -156,7 +156,7 @@ const { monitor } = await client.monitor.v1.MonitorService.updateTCPMonitor({ | `uri` | string | Yes | `host:port` to monitor (max 2048 chars) | | `periodicity` | Periodicity | Yes | Check interval | | `timeout` | bigint | No | Timeout in ms (default: 45000, max: 120000) | -| `retry` | bigint | No | Retry attempts (default: 3, max: 10) | +| `retry` | bigint | No | Total check attempts, including the first (default: 3, max: 10) | | `regions` | Region[] | No | Regions for checks | | `active` | boolean | No | Enable monitoring (default: false) | | `public` | boolean | No | Public visibility (default: false) | @@ -222,7 +222,7 @@ const { monitor } = await client.monitor.v1.MonitorService.updateDNSMonitor({ | `uri` | string | Yes | Domain to resolve (max 2048 chars) | | `periodicity` | Periodicity | Yes | Check interval | | `timeout` | bigint | No | Timeout in ms (default: 45000, max: 120000) | -| `retry` | bigint | No | Retry attempts (default: 3, max: 10) | +| `retry` | bigint | No | Total check attempts, including the first (default: 3, max: 10) | | `regions` | Region[] | No | Regions for checks | | `active` | boolean | No | Enable monitoring (default: false) | | `public` | boolean | No | Public visibility (default: false) | diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/overview.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/overview.mdx index dd544d3a4..a81328c9a 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/overview.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/overview.mdx @@ -11,7 +11,7 @@ The SDK is open source and developed in its own repository, [openstatusHQ/sdk-no ## Features -- **HTTP, TCP, and DNS monitoring** — monitor websites, APIs, database connections, and DNS records from 28 locations worldwide. (ICMP and gRPC monitors exist in the API but are not yet exposed by this SDK.) +- **HTTP, TCP, and DNS monitoring** — monitor websites, APIs, database connections, and DNS records from 27 locations worldwide. (ICMP and gRPC monitors exist in the API but are not yet exposed by this SDK.) - **Status pages** — create and manage public status pages with monitor-based or static components, grouping, and subscribers. - **Status reports and maintenance** — manage public status reports with update timelines and schedule planned maintenance windows. - **Incidents** — declare and run incidents with a timeline, a linked status report and a postmortem. (Available on the API; coming to this SDK in an upcoming release.) 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 8d3bf35fe..23ef05b20 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/reference.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/reference.mdx @@ -192,7 +192,7 @@ description: "Complete reference for enums, regions, assertions, and TypeScript ## Regions -Monitor from 28 global locations across multiple providers. +Monitor from 27 global locations across multiple providers. ```typescript import { Region } from "@openstatus/sdk-node"; @@ -200,13 +200,12 @@ import { Region } from "@openstatus/sdk-node"; regions: [Region.FLY_AMS, Region.FLY_IAD, Region.KOYEB_FRA]; ``` -### Fly.io Regions (18) +### Fly.io Regions (17) | Enum Value | Location | |------------|----------| | `FLY_AMS` | Amsterdam | | `FLY_ARN` | Stockholm | -| `FLY_BOM` | Mumbai | | `FLY_CDG` | Paris | | `FLY_DFW` | Dallas | | `FLY_EWR` | Newark | diff --git a/apps/web/src/content/pages/docs/sdk/nodejs/typescript-tips.mdx b/apps/web/src/content/pages/docs/sdk/nodejs/typescript-tips.mdx index 016f5d657..dbd1cf4e3 100644 --- a/apps/web/src/content/pages/docs/sdk/nodejs/typescript-tips.mdx +++ b/apps/web/src/content/pages/docs/sdk/nodejs/typescript-tips.mdx @@ -19,10 +19,11 @@ const { monitor } = await client.monitor.v1.MonitorService.createHTTPMonitor({ monitor: { name: "My API", url: "https://example.com", + method: HTTPMethod.HTTP_METHOD_GET, periodicity: Periodicity.PERIODICITY_1M, active: true, timeout: BigInt(30000), // 30 seconds - retry: BigInt(5), // 5 retries + retry: BigInt(5), // 5 attempts in total degradedAt: BigInt(3000), // degraded after 3s statusCodeAssertions: [ { comparator: NumberComparator.EQUAL, target: BigInt(200) }, @@ -127,14 +128,14 @@ const { httpMonitors } = await openstatus.monitor.v1.MonitorService const { monitor } = await openstatus.monitor.v1.MonitorService .createHTTPMonitor({ - monitor: { name: "API", url: "https://example.com", periodicity: 2, active: true }, + monitor: { name: "API", url: "https://example.com", method: 1, periodicity: 2, active: true }, }, { headers }); ``` **After** — configure once, use everywhere: ```typescript -import { createOpenStatusClient, Periodicity } from "@openstatus/sdk-node"; +import { createOpenStatusClient, HTTPMethod, Periodicity } from "@openstatus/sdk-node"; const client = createOpenStatusClient({ apiKey: process.env.OPENSTATUS_API_KEY, @@ -148,6 +149,7 @@ const { monitor } = await client.monitor.v1.MonitorService monitor: { name: "API", url: "https://example.com", + method: HTTPMethod.HTTP_METHOD_GET, periodicity: Periodicity.PERIODICITY_1M, active: true, }, 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 b8f20cf95..f7d5218e7 100644 --- a/apps/web/src/content/pages/docs/sdk/php/overview.mdx +++ b/apps/web/src/content/pages/docs/sdk/php/overview.mdx @@ -11,7 +11,7 @@ The SDK is open source and developed in its own repository, [openstatusHQ/sdk-ph ## Features -- **HTTP, TCP, and DNS monitoring** — monitor websites, APIs, database connections, and DNS records from 28 locations worldwide. (ICMP and gRPC monitors exist in the API but are not yet exposed by this SDK.) +- **HTTP, TCP, and DNS monitoring** — monitor websites, APIs, database connections, and DNS records from 27 locations worldwide. (ICMP and gRPC monitors exist in the API but are not yet exposed by this SDK.) - **Status pages** — create and manage public status pages with monitor-based or static components, grouping, and subscribers. - **Status reports and maintenance** — manage incident reports with update timelines and schedule planned maintenance windows. - **Notifications** — configure all 12 channels: Slack, Discord, Microsoft Teams, Email, WhatsApp, Telegram, PagerDuty, Opsgenie, Google Chat, Grafana OnCall, ntfy, and generic webhooks. 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 137a5417e..cb18e974c 100644 --- a/apps/web/src/content/pages/docs/sdk/python/overview.mdx +++ b/apps/web/src/content/pages/docs/sdk/python/overview.mdx @@ -11,7 +11,7 @@ The SDK is open source and developed in its own repository, [openstatusHQ/sdk-py ## Features -- **HTTP, TCP, and DNS monitoring** — monitor websites, APIs, database connections, and DNS records from 28 locations worldwide. (ICMP and gRPC monitors exist in the API but are not yet exposed by this SDK.) +- **HTTP, TCP, and DNS monitoring** — monitor websites, APIs, database connections, and DNS records from 27 locations worldwide. (ICMP and gRPC monitors exist in the API but are not yet exposed by this SDK.) - **Status pages** — create and manage public status pages with monitor-based or static components, grouping, and subscribers. - **Status reports and maintenance** — manage incident reports with update timelines and schedule planned maintenance windows. - **Notifications** — configure all 12 channels: Slack, Discord, Microsoft Teams, Email, WhatsApp, Telegram, PagerDuty, Opsgenie, Google Chat, Grafana OnCall, ntfy, and generic webhooks. diff --git a/apps/web/src/content/pages/docs/tutorial/create-your-first-monitor.mdx b/apps/web/src/content/pages/docs/tutorial/create-your-first-monitor.mdx index c4ce83d37..6467e0d0c 100644 --- a/apps/web/src/content/pages/docs/tutorial/create-your-first-monitor.mdx +++ b/apps/web/src/content/pages/docs/tutorial/create-your-first-monitor.mdx @@ -1,7 +1,7 @@ --- category: Tutorials title: Create an Uptime Monitor in 5 Minutes -description: "Set up your first uptime monitor with openstatus — track response time, status codes, and availability from 28 global regions." +description: "Set up your first uptime monitor with openstatus — track response time, status codes, and availability from 27 global regions." --- -- 2.54.0