### Install Project Dependencies with pnpm

Source: https://docs.openstatus.dev/llms-full.txt

Installs all necessary project dependencies using the pnpm package manager. This command should be run after cloning the repository.

```shell
pnpm install
```

--------------------------------

### Install Node.js on Ubuntu

Source: https://docs.openstatus.dev/llms-full.txt

Installs Node.js on Ubuntu systems using the apt package manager. Ensure Node.js version 18.0.0 or later is installed.

```bash
sudo apt update
sudo apt install nodejs
```

--------------------------------

### Install sqld-beta using Homebrew

Source: https://docs.openstatus.dev/llms-full.txt

Installs the sqld-beta package, a component for Turso, using the Homebrew package manager. This is a prerequisite for using Turso locally on macOS or Linux.

```bash
brew tap libsql/sqld
brew install sqld-beta
```

--------------------------------

### Install and Run tinybird-cli

Source: https://docs.openstatus.dev/llms-full.txt

This snippet details the steps to install the tinybird-cli for managing data sources and pipes. It includes setting up a virtual environment, installing the package, and preparing data for import. Ensure you use an admin token for authentication.

```plaintext
cd packages/tinybird
python3 -m venv .venv
source .venv/bin/activate
pip install tinybird-cli
```

--------------------------------

### Run OpenStatus Development Environment

Source: https://docs.openstatus.dev/llms-full.txt

Starts the OpenStatus development environment, including running database migrations. This command is essential for local development.

```shell
pnpm dx
```

--------------------------------

### Install OpenStatus React Package

Source: https://docs.openstatus.dev/llms-full.txt

This command installs the OpenStatus React widget package using npm, making its components available for use in your React application.

```bash
npm install @openstatus/react
```

--------------------------------

### Start Turso with a local SQLite database

Source: https://docs.openstatus.dev/llms-full.txt

Launches the Turso development server using a local SQLite database file named 'openstatus.db'. This command allows for local database development without modifying environment files.

```bash
turso dev --db-file openstatus.db
```

--------------------------------

### Clone OpenStatus Repository

Source: https://docs.openstatus.dev/llms-full.txt

Clones the OpenStatus project repository from GitHub. This is the first step in setting up the development environment.

```shell
git clone https://github.com/openstatushq/openstatus.git
```

--------------------------------

### OpenStatus CLI Installation Scripts

Source: https://docs.openstatus.dev/llms-full.txt

These shell scripts provide installation instructions for the OpenStatus CLI across different operating systems. They include commands for macOS using Homebrew or a direct curl script, Linux using curl, and Windows using Invoke-WebRequest.

```bash
# OS X
brew install openstatusHQ/cli/openstatus --cask

or

curl -sSL instl.sh/openstatushq/cli/macos | bash
```

```bash
# Linux
curl -sSL instl.sh/openstatushq/cli/linux | bash
```

```bash
# Windows
iwr instl.sh/openstatushq/cli/windows | iex
```

--------------------------------

### Turso database configuration in .env file

Source: https://docs.openstatus.dev/llms-full.txt

Example of how to configure the Turso cloud database connection details within a .env file. Includes the database URL and authentication token.

```plaintext
# TURSO SQLITE
DATABASE_URL=libsql://my-database-example.turso.io
DATABASE_AUTH_TOKEN=ey••••••••••••••••••••••••••••••••
```

--------------------------------

### Install pnpm Globally with npm

Source: https://docs.openstatus.dev/llms-full.txt

Installs the pnpm package manager globally using npm. This command ensures that pnpm is available system-wide for managing project dependencies.

```bash
npm install -g pnpm
```

--------------------------------

### OpenStatus CLI Command to Create Monitor

Source: https://docs.openstatus.dev/llms-full.txt

Command-line interface instruction to create a new OpenStatus monitor using a specified YAML configuration file. This command initiates the monitor setup process based on the provided configuration.

```bash
openstatus create openstatus.yaml

```

--------------------------------

### Check Node.js Version

Source: https://docs.openstatus.dev/llms-full.txt

Checks the currently installed version of Node.js. This is used to verify that the installed version meets the minimum requirement of 18.0.0.

```bash
node --version
```

--------------------------------

### Check pnpm Version

Source: https://docs.openstatus.dev/llms-full.txt

Checks the currently installed version of pnpm. This is used to verify that the installed version meets the minimum requirement of 8.6.2.

```bash
pnpm --version
```

--------------------------------

### Initialize Local Turso Database

Source: https://docs.openstatus.dev/llms-full.txt

Launches the Turso local database using the 'turso dev' command. This command requires a database file named 'openstatus-dev.db'.

```shell
turso dev --db-file openstatus-dev.db
```

--------------------------------

### Launch Drizzle Studio

Source: https://docs.openstatus.dev/llms-full.txt

This command navigates to the database packages directory and launches Drizzle Studio, a GUI tool for interacting with your database. This is useful for inspecting and managing your database schema and data during development.

```bash
cd packages/db
pnpm studio
```

--------------------------------

### Import OpenStatus Monitors to YAML

Source: https://docs.openstatus.dev/llms-full.txt

Imports existing monitors from the OpenStatus dashboard into a new `openstatus.yaml` file. This is useful for generating an initial configuration file.

```shell
openstatus monitors import
```

--------------------------------

### Status Page Example (Plaintext)

Source: https://docs.openstatus.dev/llms-full.txt

A plaintext representation of a status page, showing a table of services with their current status and uptime percentages, followed by a section for active incidents. This format is suitable for basic display and can be programmatically generated.

```plaintext
+------------------------------------------------+
|               openstatus Status Page           |
+------------------------------------------------+
| Service Name      | Status | Uptime            |
+-------------------+--------+-------------------+
| Web Server        | ✅ OK       | 99.9%        |
| Database          | ✅ OK       | 99.8%        |
| API Gateway       | ⚠️ Degraded | 99.5%        |
| Monitoring        | ✅ OK       | 100%         |
| Payment Processing| ✅ OK       | 99.7%        |
+-------------------+--------+-------------------+
| Incidents:                                     |
|                                                |
|   - Degraded performance on API Gateway due    |
|     to high traffic. Our team is investigating.|
+------------------------------------------------+
```

--------------------------------

### Get Workspace Information using Openstatus CLI

Source: https://docs.openstatus.dev/llms-full.txt

Retrieves information about the current Openstatus workspace, including its name, slug, and subscription plan. Requires an OpenStatus API Access Token.

```bash
openstatus whoami
```

```bash
openstatus -t "<ACCESS_TOKEN>" whoami
```

--------------------------------

### Latency Calculation Example

Source: https://docs.openstatus.dev/llms-full.txt

Illustrates the calculation of network latency using timestamps for a request and its response. This helps in understanding the time taken for data to travel between systems.

```plaintext
openstatus                  Network                 Server (Website)
  |                           |                          |
  |------- Request ---------->|                          |
  | (Timestamp A: Send)       |                          |
  |                           |------- Process --------->|
  |                           | (Server processing time) |
  |                           |<------- Response --------|
  |                           | (Timestamp B: Receive)   |
  |                           |                          |
Latency = Timestamp B - Timestamp A
```

--------------------------------

### Launch OpenStatus Web Application

Source: https://docs.openstatus.dev/llms-full.txt

Launches the OpenStatus web application, typically running on port 3000. This command allows you to view and interact with the application locally.

```shell
pnpm dev:web
```

--------------------------------

### Get Monitor Information using Openstatus CLI

Source: https://docs.openstatus.dev/llms-full.txt

Retrieves detailed information about a specific monitor using its ID. Includes details like name, description, endpoint, method, frequency, status, and more. The 'body' field is truncated to 40 characters. Requires an OpenStatus API Access Token.

```bash
openstatus monitors info <MonitorID>
```

```bash
openstatus -t "<ACCESS_TOKEN>" monitors info <MonitorID>
```

--------------------------------

### Response Time Calculation Example

Source: https://docs.openstatus.dev/llms-full.txt

Demonstrates the calculation of response time, which includes both network latency and server processing time. This metric reflects the total time experienced by a user from request to response.

```plaintext
    openstatus                 Network                Server
        |                         |                     |
(Start) |------- Request -------->|                     |
(T1)    |                         |                     |
        |                         |--- Processing ----->|
        |                         |   (Server's work)   |
        |                         |<-- Response Data ---|
        |                         |                     |
(End)   |<--- (Received) ---------|                     |
(T2)    |                         |                     |


 Response Time = T2 - T1
```

--------------------------------

### Configure Upstash QStash Keys for Queues

Source: https://docs.openstatus.dev/llms-full.txt

This snippet illustrates the .env configuration for QStash, including QSTASH_CURRENT_SIGNING_KEY, QSTASH_NEXT_SIGNING_KEY, QSTASH_TOKEN, and QSTASH_URL. These keys are obtained from the Upstash console.

```plaintext
# UPSTASH for queue
QSTASH_CURRENT_SIGNING_KEY=sig_•••••••••••••••••••••••••
QSTASH_NEXT_SIGNING_KEY=sig_•••••••••••••••••••••••••
QSTASH_TOKEN=ey••••••••••••••••••••••••••••••••
QSTASH_URL=https://qstash.upstash.io/v1/publish/
```

--------------------------------

### Create a new Turso cloud database

Source: https://docs.openstatus.dev/llms-full.txt

Creates a new cloud-hosted database instance within your Turso account. This command initiates the process of provisioning a remote database.

```plaintext
turso db create
```

--------------------------------

### OpenStatus CLI Usage (Bash)

Source: https://docs.openstatus.dev/llms-full.txt

This is the general usage pattern for the OpenStatus CLI. It shows how to invoke the CLI with commands, flags, and arguments to manage monitors and trigger synthetic tests.

```bash
openstatus [COMMAND] [COMMAND FLAGS] [ARGUMENTS...]
```

--------------------------------

### Authenticate Turso CLI

Source: https://docs.openstatus.dev/llms-full.txt

Logs in to your Turso account via the command line interface. This is a necessary step before creating or managing cloud-based databases.

```plaintext
turso auth login
```

--------------------------------

### Apply OpenStatus Configuration Changes

Source: https://docs.openstatus.dev/llms-full.txt

Applies changes defined in the local `openstatus.yaml` file to the OpenStatus monitors. This CLI command synchronizes local configuration with the live monitor state.

```shell
openstatus monitors apply
```

--------------------------------

### Importing StatusWidget in Next.js (JSX)

Source: https://docs.openstatus.dev/llms-full.txt

Example of how to import and use the `StatusWidget` component within a Next.js application. This snippet demonstrates the import statement and the JSX syntax for rendering the widget with a specific monitor slug.

```jsx
import StatusWidget from '../../components/StatusWidget.tsx'


<StatusWidget slug="monitor-slug-here" />
```

--------------------------------

### Fetch Public Status Endpoint (Bash)

Source: https://docs.openstatus.dev/llms-full.txt

Example using curl to fetch the public status of a status page. Requires the unique slug of the page. The response is a JSON object indicating the operational status.

```bash
curl https://api.openstatus.dev/public/status/:slug
```

--------------------------------

### GET /public/status/:slug

Source: https://docs.openstatus.dev/llms-full.txt

Retrieves the public status of a status page using its unique slug.

```APIDOC
## GET /public/status/:slug

### Description
Fetches the current operational status of a specific status page.

### Method
GET

### Endpoint
`https://api.openstatus.dev/public/status/:slug`

### Parameters
#### Path Parameters
- **slug** (string) - Required - The unique identifier for the status page.

### Response
#### Success Response (200)
- **status** (string) - The current status of the page. Possible values include:
  - `operational`
  - `degraded_performance`
  - `partial_outage`
  - `major_outage`
  - `under_maintenance`
  - `unknown`
  - `incident`

#### Response Example
```json
{
  "status": "operational"
}
```
```

--------------------------------

### Get Public Status

Source: https://docs.openstatus.dev/llms-full.txt

Retrieve the current status of a status page using its unique slug.

```APIDOC
## GET /public/status/:slug

### Description
Retrieves the current status of a status page identified by its unique slug.

### Method
GET

### Endpoint
/public/status/:slug

### Parameters
#### Path Parameters
- **slug** (string) - Required - The unique identifier for the status page.

### Response
#### Success Response (200)
- **status** (string) - The current status of the page. Can be one of: "unknown", "operational", "degraded_performance", "partial_outage", "major_outage", "under_maintenance", "incident".

#### Response Example
```json
{
  "status": "operational"
}
```
```

--------------------------------

### Deploy Astro Status Page using npm

Source: https://docs.openstatus.dev/llms-full.txt

This command initiates the deployment of the Astro status page to Cloudflare Pages. It assumes that the necessary environment variables, including the API key, have been configured in the Cloudflare dashboard.

```bash
npm run pages:deploy
```

--------------------------------

### Run Synthetic Tests using Openstatus CLI

Source: https://docs.openstatus.dev/llms-full.txt

Executes synthetic tests defined in the 'config.openstatus.yaml' file. Allows specifying a custom configuration file path. Requires an OpenStatus API Access Token.

```bash
openstatus run
```

```bash
openstatus --config "path/to/config.openstatus.yaml" run
```

```bash
openstatus -t "<ACCESS_TOKEN>" run
```

--------------------------------

### PNG Badge Endpoint

Source: https://docs.openstatus.dev/llms-full.txt

Embed a PNG badge displaying your service status directly into your website.

```APIDOC
## GET /badge

### Description
Returns a PNG image representing the current status of the status page. Supports theme and size customization.

### Method
GET

### Endpoint
https://[slug].openstatus.dev/badge

### Parameters
#### Query Parameters
- **theme** (string) - Optional - The theme for the badge. Supported values: `dark`, `light` (default).
- **size** (string) - Optional - The size of the badge. Supported values: `sm` (default), `md`, `lg`, `xl`.

### Response
#### Success Response (200)
- Returns a PNG image file.

### Response Example
```html
<img src='https://[slug].openstatus.dev/badge?theme=dark&size=lg'>
```

### Labels
- Operational
- Degraded
- Outage
- Incident
- Maintenance
- Unknown
```

--------------------------------

### Export Synthetic Monitoring Data to OpenTelemetry

Source: https://docs.openstatus.dev/llms-full.txt

This section describes how to export synthetic monitoring data to an OpenTelemetry endpoint. It outlines the process of enabling the feature in OpenStatus settings and provides examples of attributes and available metrics for HTTP and TCP probes. This enables integration with observability platforms like Grafana Cloud, New Relic, and Honeycomb.

```text
To change set up an otlp endpont : *Select a monitor → Settings → OTel*.
Add your OTLP endpoint and include your headers.

Attributes
* openstatus.probes -> the region of the probes
* openstatus.target

Available Metrics
For HTTP probes:
* openstatus.http.request.duration
* openstatus.http.dns.duration
* openstatus.http.connection.duration
* openstatus.http.tls.duration
* openstatus.http.ttfb.duration
* openstatus.http.transfer.duration
* openstatus.error ( counter fill when error)
* openstatus.status (counter -> 1 when successful request)

For TCP probes:
* openstatus.tcp.request.duration
```

--------------------------------

### Configure Tinybird API Key

Source: https://docs.openstatus.dev/llms-full.txt

This snippet demonstrates how to set the TINY_BIRD_API_KEY in the .env file for interacting with Tinybird. The API token is generated within the Tinybird workspace.

```plaintext
# TinyBird
TINY_BIRD_API_KEY="•••••••••"
```

--------------------------------

### OpenStatus CLI: Create/Update Monitors (Bash)

Source: https://docs.openstatus.dev/llms-full.txt

This command applies monitor configurations from a YAML file. It supports specifying a configuration file, an access token, and an auto-accept flag for non-interactive use. The default configuration file is 'openstatus.yaml'.

```bash
openstatus monitors apply --config="your-config.yaml" --access-token="your-token" -y
```

--------------------------------

### Show Turso database name and create token

Source: https://docs.openstatus.dev/llms-full.txt

Retrieves the name of a specific Turso database and generates an authentication token for it. These values are essential for connecting applications to the cloud database.

```plaintext
turso db show db-name
turso db tokens create db-name
```

--------------------------------

### SVG Badge (v2) Endpoint

Source: https://docs.openstatus.dev/llms-full.txt

Embed a customizable SVG badge with advanced styling options for your service status.

```APIDOC
## GET /badge/v2

### Description
Returns an SVG image representing the current status of the status page. Supports theme, size, and variant customization, along with border and border-radius options.

### Method
GET

### Endpoint
https://[slug].openstatus.dev/badge/v2

### Parameters
#### Query Parameters
- **theme** (string) - Optional - The theme for the badge. Supported values: `light` (default), `dark`.
- **size** (string) - Optional - The size of the badge. Supported values: `sm` (default), `md`, `lg`, `xl`.
- **variant** (string) - Optional - The variant of the badge. Supported values: `default` (default), `outline`.

### Response
#### Success Response (200)
- Returns an SVG image file.

### Response Example
```html
<img src='https://[slug].openstatus.dev/badge/v2?theme=dark&size=lg&variant=outline'>
```

### Labels
- All Systems Operational
- Degraded Performance
- Partial Outage
- Major Outage
- Ongoing Incident
- Under Maintenance
- Unknown
```

--------------------------------

### OpenStatus CLI: Import Monitors (Bash)

Source: https://docs.openstatus.dev/llms-full.txt

This command imports existing monitors into a YAML file. It requires an OpenStatus API Access Token and allows specifying an output file name. The default output file is 'openstatus.yaml'.

```bash
openstatus monitors import --access-token="your-token" --output="monitors.yaml"
```

--------------------------------

### List Monitors using Openstatus CLI

Source: https://docs.openstatus.dev/llms-full.txt

Lists all monitors associated with the current workspace. By default, it shows active monitors, but the --all flag can be used to include inactive ones. Requires an OpenStatus API Access Token.

```bash
openstatus monitors list
```

```bash
openstatus monitors list --all
```

```bash
openstatus -t "<ACCESS_TOKEN>" monitors list
```

--------------------------------

### Configure Upstash Redis for Waiting List

Source: https://docs.openstatus.dev/llms-full.txt

This snippet shows the .env variables for configuring Upstash Redis, specifically UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN. These are used for the waiting list feature and obtained from the Upstash console.

```plaintext
# UPSTASH redis for waiting list
UPSTASH_REDIS_REST_URL="https://•••••••••.upstash.io"
UPSTASH_REDIS_REST_TOKEN="•••••••••"
```

--------------------------------

### Add PNG Status Badge to GitHub README

Source: https://docs.openstatus.dev/llms-full.txt

Embed a PNG status badge in your GitHub README to display the operational status of your service. Customize theme and size using query parameters.

```html
<img src='https://[slug].openstatus.dev/badge'>
<img src='https://[slug].openstatus.dev/badge?theme=dark'>
<img src='https://[slug].openstatus.dev/badge?size=lg'>
```

--------------------------------

### Export Metrics to OTLP Endpoint via openstatus.yaml

Source: https://docs.openstatus.dev/llms-full.txt

Configure OpenStatus to export metrics to your OpenTelemetry (OTLP) endpoint by specifying the endpoint URL and authorization headers in the `openstatus.yaml` configuration file.

```yaml
openTelemetry:
  endpoint: http://your-otel-endpoint:4318/v1/metrics
  headers:
    Authorization: Bearer your-token
```

--------------------------------

### Create GitHub Action for OpenStatus CI

Source: https://docs.openstatus.dev/llms-full.txt

This YAML file defines a GitHub Action workflow that runs OpenStatus synthetics CI on pushes to the main branch. It checks out the code and uses the OpenStatus GitHub Action to perform the synthetic tests, requiring an API key from GitHub secrets.

```yaml
name: Run OpenStatus Synthetics CI

on:
  workflow_dispatch:
  push:
    branches: [ main ]

jobs:
  synthetic_ci:
    runs-on: ubuntu-latest
    name: Run OpenStatus Synthetics CI
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run OpenStatus Synthetics CI
        uses: openstatushq/openstatus-github-action@v1
        with:
          api_key: ${{ secrets.OPENSTATUS_API_KEY }}
```

--------------------------------

### Configure Resend API Key for Email

Source: https://docs.openstatus.dev/llms-full.txt

This snippet shows how to set the RESEND_API_KEY in the .env file for sending emails via Resend. Obtain the key from the Resend website and paste it into the environment file.

```plaintext
# RESEND for email
RESEND_API_KEY=re_••••••••••••••••••••••••••••••••
```

--------------------------------

### Trigger Monitor Execution using Openstatus CLI

Source: https://docs.openstatus.dev/llms-full.txt

Manually triggers an on-demand execution of a specific monitor. This is useful for launching tests immediately outside their scheduled frequency. Requires an OpenStatus API Access Token.

```bash
openstatus monitors trigger <MonitorId>
```

```bash
openstatus -t "<ACCESS_TOKEN>" monitors trigger <MonitorId>
```

--------------------------------

### YAML Configuration for MCP Server Monitor

Source: https://docs.openstatus.dev/llms-full.txt

Defines an OpenStatus monitor for an Hugging Face MCP server using YAML. It specifies the server details, ping request parameters (URL, method, body, headers), and assertions for status code and response body. This configuration is suitable for GitOps workflows.

```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"}'

```

--------------------------------

### Configure HTTP Uptime Monitor

Source: https://docs.openstatus.dev/llms-full.txt

This configuration sets up an HTTP uptime monitor for a specified URL. It defines the check frequency, regions to monitor from, retry attempts, request details (URL, method, headers), and assertions to validate the response status code. Dependencies include the OpenStatus schema for validation.

```yaml
# yaml-language-server: $schema=https://www.openstatus.dev/schema.json
uptime-monitor:
  name: "Uptime Monitor"
  description: "Uptime monitoring example"
  frequency: "10m"
  active: true
  regions:
    - iad
    - ams
    - syd
    - jnb
    - gru
  retry: 3
  kind: http
  request:
    url: https://openstat.us
    method: GET
    headers:
      User-Agent: OpenStatus
  assertions:
    - kind: statusCode
      compare: eq
      target: 200
```

--------------------------------

### YAML Configuration for Synthetic Test IDs

Source: https://docs.openstatus.dev/llms-full.txt

A minimal YAML configuration file used to specify which OpenStatus monitor IDs should be included in a synthetic test run. This is commonly used in CI/CD pipelines, such as GitHub Actions, to define the scope of tests.

```yaml
tests:
  ids:
    - 1
    - 2

```

--------------------------------

### OpenStatus CLI Commands for Monitor Management

Source: https://docs.openstatus.dev/llms-full.txt

These bash commands are used with the OpenStatus CLI for managing monitors. `openstatus monitors import` imports monitors from your workspace to a YAML file, while `openstatus monitors apply` applies changes (add, remove, update) defined in a YAML file to your OpenStatus configuration.

```bash
# Import Monitors
openstatus monitors import
```

```bash
# Manage Monitors
openstatus monitors apply
```

--------------------------------

### Status Enum Definition

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript enum defines the possible status values that can be returned by the OpenStatus API. These include various levels of service availability and maintenance states.

```ts
enum Status {
  Operational = "operational",
  DegradedPerformance = "degraded_performance",
  PartialOutage = "partial_outage",
  MajorOutage = "major_outage",
  UnderMaintenance = "under_maintenance", // currently not in use
  Unknown = "unknown",
  Incident = "incident",
}
```

--------------------------------

### Configure Uptime Monitors in YAML for openstatus

Source: https://docs.openstatus.dev/llms-full.txt

This YAML file defines various uptime monitors for the openstatus system. It specifies details such as monitor name, description, check frequency, active status, monitoring regions, retry attempts, monitor type (HTTP), request details (URL, method, headers, body), and assertions (e.g., expected status code).

```yaml
# yaml-language-server: $schema=https://www.openstatus.dev/schema.json
uptime-monitor:
  name: "Uptime Monitor"
  description: "Uptime monitoring example"
  frequency: "10m"
  active: true
  regions:
    - iad
    - ams
    - syd
    - jnb
    - gru
  retry: 3
  kind: http
  request:
    url: https://openstat.us
    method: GET
    headers:
      User-Agent: OpenStatus
  assertions:
    - kind: statusCode
      compare: eq
      target: 200

graphql-monitor:
  name: "Graphql"
  description: "GitHub GraphQL API"
  frequency: "10m"
  active: true
  regions:
    - iad
    - ams
    - syd
    - jnb
    - gru
  retry: 3
  kind: http
  request:
    url: https://api.github.com/graphql
    method: POST
    headers:
      User-Agent: OpenStatus
      Authorization: Bearer YOUR_TOKEN_HERE
    body: |
      {
        "query": "query { viewer { login }}"
      }

```

--------------------------------

### Status Calculation Logic

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript function calculates the service status based on a ratio, likely representing uptime. It maps different ratio ranges to predefined status states, with caching implemented for performance.

```ts
function getStatus(ratio: number) {
  if (isNaN(ratio)) return Status.Unknown;
  if (ratio >= 0.98) return Status.Operational;
  if (ratio >= 0.6) return Status.DegradedPerformance;
  if (ratio >= 0.3) return Status.PartialOutage;
  if (ratio >= 0) return Status.MajorOutage;
  return Status.Unknown;
}
```

--------------------------------

### Configure Tailwind CSS for OpenStatus React

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript configuration file shows how to set up Tailwind CSS to include styles for the OpenStatus React components. It specifies the content paths, including the node_modules directory for the @openstatus/react package.

```ts
module.exports = {
  content: [
    "./app/**/*.{tsx,ts,mdx,md}",
    "./node_modules/@openstatus/react/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
};
```

--------------------------------

### Import Global Styles for OpenStatus React (No Tailwind)

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript code snippet shows how to import the global CSS styles for the OpenStatus React widget directly into your application's layout file when not using Tailwind CSS.

```ts
import "@openstatus/react/dist/styles.css";
```

--------------------------------

### Tinybird Queries for Timezone and Daily Aggregations

Source: https://docs.openstatus.dev/llms-full.txt

This set of Tinybird SQL queries processes ping response data to calculate average latency and status counts grouped by day and timezone. It includes data transformation, filtering for recent data, and aggregation to provide daily summaries.

```sql
VERSION 0


NODE group_by_cronTimestamp
SQL >


    %
    SELECT
        toDateTime(cronTimestamp / 1000, 'UTC') AS day,
        -- only for debugging purposes
        toTimezone(day, {{ String(timezone, 'Europe/Berlin') }}) as with_timezone,
        toStartOfDay(with_timezone) as start_of_day,
        avg(latency) AS avgLatency,
        count() AS count,
        count(multiIf((statusCode >= 200) AND (statusCode <= 299), 1, NULL)) AS ok
    FROM ping_response__v4
    WHERE
        (day IS NOT NULL)
        AND (day != 0)
        AND monitorId = {{ String(monitorId, '1') }}
        -- By default, we only only query the last 45 days
        AND cronTimestamp >= toUnixTimestamp64Milli(
            toDateTime64(toStartOfDay(date_sub(DAY, 45, now())), 3)
        )
    GROUP BY cronTimestamp, monitorId
    ORDER BY day DESC





NODE group_by_day
SQL >


    %
    SELECT
        start_of_day as day,
        sum(count) as count,
        sum(ok) as ok,
        round(avg(avgLatency)) as avgLatency
    FROM group_by_cronTimestamp
    GROUP BY start_of_day
    ORDER BY start_of_day DESC
    LIMIT {{ Int32(limit, 100) }}
```

--------------------------------

### Setting OpenStatus API Token via Environment Variable

Source: https://docs.openstatus.dev/llms-full.txt

This command sets the `OPENSTATUS_API_TOKEN` environment variable, which is used by the OpenStatus CLI and Terraform provider for authentication. Replace `<your-api-token>` with your actual API token obtained from your workspace settings.

```bash
export OPENSTATUS_API_TOKEN=<your-api-token>
```

--------------------------------

### Importing Astro Status Widget into Layout

Source: https://docs.openstatus.dev/llms-full.txt

This Astro snippet demonstrates how to import and use the `StatusWidget.astro` component within a layout file, typically a footer. It assumes a relative import path has been configured in `tsconfig.json` and requires the monitor slug to be passed as a prop.

```astro
---
import StatusWidget from '../../components/StatusWidget.astro'
---


<StatusWidget slug="monitor-slug-here" />
```

--------------------------------

### Terraform Configuration for OpenStatus Provider and Monitor

Source: https://docs.openstatus.dev/llms-full.txt

This snippet demonstrates how to configure the OpenStatus Terraform provider and define a monitor resource. It requires an API token for authentication and allows specifying monitor details like URL, regions, periodicity, name, and description.

```plaintext
provider "openstatus" {
  openstatus_api_token= "YOUR_API_TOKEN"
}


resource "openstatus_monitor" "my_monitor" {
  url   = "https://www.openstatus.dev"
  regions= ["iad", "jnb"]
  periodicity =  "10m"
  name = "test-monitor"
  active = true
  description = "This is a test monitor"
}
```

--------------------------------

### Set Cloudflare Pages Environment Variable

Source: https://docs.openstatus.dev/llms-full.txt

This shows how to set the OpenStatus API key as an environment variable within Cloudflare Pages settings. This is crucial for the Astro application to authenticate with the OpenStatus API during deployment.

```env
API_KEY=your-api-key
```

--------------------------------

### Use StatusWidget in React Server Component

Source: https://docs.openstatus.dev/llms-full.txt

This React Server Component demonstrates how to use the StatusWidget from the @openstatus/react package. It displays the status for a given slug and optionally allows customization of the link's destination using the 'href' prop.

```tsx
import { StatusWidget } from "@openstatus/react";

export function Page() {
  return <StatusWidget slug="status" />;
}

<StatusWidget slug="documenso" href="https://status.documenso.com" />
```

--------------------------------

### Fetch OpenStatus Monitor Data in Astro

Source: https://docs.openstatus.dev/llms-full.txt

This snippet demonstrates how to fetch monitoring data from the OpenStatus API within an Astro component. It requires an API key for authentication and parses the JSON response against a predefined schema. It then filters the monitors based on provided IDs.

```typescript
const response = await fetch("https://api.openstatus.dev/v1/monitor", {
  headers: {
    "x-openstatus-key": env.API_KEY,
  },
});


const data = await response.json();


const r = monitorsSchema.parse(data);


// our monitors id
const monitorIds = [1]
const result = r.filter((m) => monitorIds.find(id => m.id === id) );
```

--------------------------------

### Add SVG Status Badge (v2) to GitHub README

Source: https://docs.openstatus.dev/llms-full.txt

Embed an SVG status badge (v2) in your GitHub README for enhanced customization, including theme, size, and variant. The outline variant is particularly useful for Markdown environments.

```html
<img src='https://[slug].openstatus.dev/badge/v2'>
<img src='https://[slug].openstatus.dev/badge/v2?theme=dark'>
<img src='https://[slug].openstatus.dev/badge/v2?size=lg'>
<img src='https://[slug].openstatus.dev/badge/v2?variant=outline'>
```

--------------------------------

### Monitor Recovery Payload JSON

Source: https://docs.openstatus.dev/llms-full.txt

This JSON payload is sent by OpenStatus when a monitored service recovers. It includes details about the monitor, the timestamp of the check, the status indicating recovery, the HTTP status code, and the latency of the check.

```json
{
  "monitor": {
    "id": 1,
    "name": "test",
    "url": "http://openstat.us"
  },
  "cronTimestamp": 1744023705307,
  "status": "recovered",
  "statusCode": 200,
  "latency": 1337
}
```

--------------------------------

### Basic React Server Component Usage

Source: https://docs.openstatus.dev/llms-full.txt

This React Server Component demonstrates how to use the StatusWidget from the OpenStatus package. It displays a status widget for a given slug and automatically links to the corresponding status page. If a custom href is provided, it redirects to that URL instead.

```tsx
import { StatusWidget } from "@openstatus/react";


export function Page() {
  return <StatusWidget slug="status" />;
}
```

```tsx
<StatusWidget slug="documenso" href="https://status.documenso.com" />
```

--------------------------------

### Zod Schemas for Status Validation (TypeScript)

Source: https://docs.openstatus.dev/llms-full.txt

TypeScript code defining Zod schemas to validate the JSON response from the OpenStatus API. Includes an enum for possible status values and an object schema for the status response.

```typescript
import * as z from "zod";


const statusEnum = z.enum([
  "operational",
  "degraded_performance",
  "partial_outage",
  "major_outage",
  "under_maintenance",
  "unknown",
  "incident",
]);


const statusSchema = z.object({
  status: statusEnum
});
```

--------------------------------

### Embed SVG Status Badge (v2)

Source: https://docs.openstatus.dev/llms-full.txt

This HTML snippet demonstrates embedding an SVG status badge (v2) with options for theme, size, and variant (default/outline). The SVG badge offers more styling control, such as border and border-radius.

```html
<img src='https://[slug].openstatus.dev/badge/v2'>
```

--------------------------------

### Typed Fetch Function for Status Data

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript code demonstrates how to use the getStatus function from the @openstatus/react package to fetch the status of a page within a React Server Component. It highlights the expected response structure and the possible status values.

```tsx
import { getStatus } from "@openstatus/react";


// React Server Component
async function CustomStatusWidget() {
  const res = await getStatus("slug");
  // ^StatusResponse = { status: Status }


  const { status } = res;
  // ^Status = "unknown" | "operational" | "degraded_performance" | "partial_outage" | "major_outage" | "under_maintenance" | "incident"


  return <div>{/* customize */}</div>;
}
```

--------------------------------

### Embedding Status Page Badge (HTML)

Source: https://docs.openstatus.dev/llms-full.txt

This HTML snippet shows how to embed the OpenStatus status page badge on a website or GitHub README. It supports customization for theme (dark) and size (sm, md, lg, xl) via URL parameters.

```html
<img src="https://YOUR-SLUG.openstatus.dev/badge" />
```

```html
<img src="https://YOUR-SLUG.openstatus.dev/badge?theme=dark" />
```

```html
<img src="https://YOUR-SLUG.openstatus.dev/badge?theme=dark&size=xl" />
```

--------------------------------

### Embed PNG Status Badge

Source: https://docs.openstatus.dev/llms-full.txt

This HTML snippet shows how to embed a PNG status badge into your website. The badge's appearance can be customized using query parameters for theme (dark/light) and size (sm, md, lg, xl).

```html
<img src='https://[slug].openstatus.dev/badge'>
```

--------------------------------

### Monitor MCP Server with HTTP POST

Source: https://docs.openstatus.dev/llms-full.txt

This configuration defines a monitor for an MCP server using an HTTP POST request. It includes specific details for the request body, headers, and assertions to check both the status code and the response text body. This is useful for services that require POST requests with a JSON payload.

```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"}'
```

--------------------------------

### Zod Schema for Monitor Failure Payload (TypeScript)

Source: https://docs.openstatus.dev/llms-full.txt

A Zod schema defining the expected structure and types for the monitor failure notification payload. It includes optional fields for status code, latency, and error messages, ensuring data integrity and validation.

```typescript
import { z } from "zod";


export const PayloadSchema = z.object({
  monitor: z.object({
    id: z.number(),
    name: z.string(),
    url: z.string(),
  }),
  cronTimestamp: z.number(),
  status: z.enum(["degraded", "error", "recovered"]),
  statusCode: z.number().optional(),
  latency: z.number().optional(),
  errorMessage: z.string().optional(),
});
```

--------------------------------

### Monitor Failure Notification Payload

Source: https://docs.openstatus.dev/llms-full.txt

The JSON payload sent when a monitor fails. It includes details about the monitor, the timestamp of the check, the status (error), and a specific error message. This structure helps in quickly understanding the nature and context of the failure.

```json
{
  "monitor": {
    "id": 1,
    "name": "test",
    "url": "http://openstat.us"
  },
  "cronTimestamp": 1744023705307,
  "status": "error",
  "errorMessage": "Connection refused"
}
```

--------------------------------

### Fetch Status Data with Typed Function

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript code demonstrates using the 'getStatus' function from '@openstatus/react' in a React Server Component to fetch status information. It shows how to handle the response and access the status property, which can be one of several predefined states.

```tsx
import { getStatus } from "@openstatus/react";

// React Server Component
async function CustomStatusWidget() {
  const res = await getStatus("slug");
  // ^StatusResponse = { status: Status }


  const { status } = res;
  // ^Status = "unknown" | "operational" | "degraded_performance" | "partial_outage" | "major_outage" | "under_maintenance" | "incident"

  return <div>{/* customize */}</div>;
}
```

--------------------------------

### Astro Widget for Displaying Service Status

Source: https://docs.openstatus.dev/llms-full.txt

This Astro component fetches service status from the OpenStatus API and displays it visually. It uses Zod for schema validation and dynamically renders labels and colors based on the status. The component requires a monitor slug as a prop and fetches data with a 60-second revalidation period.

```astro
---
import * as z from "zod"


const statusEnum = z.enum([
  "operational",
  "degraded_performance",
  "partial_outage",
  "major_outage",
  "under_maintenance",
  "unknown",
  "incident",
])


const statusSchema = z.object({ status: statusEnum })


const dictionary = {
  operational: {
    label: "Operational",
    color: "bg-green-500",
  },
  degraded_performance: {
    label: "Degraded Performance",
    color: "bg-yellow-500",
  },
  partial_outage: {
    label: "Partial Outage",
    color: "bg-yellow-500",
  },
  major_outage: {
    label: "Major Outage",
    color: "bg-red-500",
  },
  unknown: {
    label: "Unknown",
    color: "bg-gray-500",
  },
  incident: {
    label: "Incident",
    color: "bg-yellow-500",
  },
  under_maintenance: {
    label: "Under Maintenance",
    color: "bg-blue-500",
  },
}


const slug = Astro.props.slug


const res = await fetch(`https://api.openstatus.dev/public/status/${slug}`, {
  // @ts-ignore
  next: { revalidate: 60 },
})
const data = await res.json()
const parsed = statusSchema.safeParse(data)
if (!parsed.success) {
  return null
}
const key = parsed.data.status
const { label, color } = dictionary[key]
---


<a
  class="border-border text-foreground/70 hover:bg-muted hover:text-foreground inline-flex max-w-fit items-center gap-2 rounded-md border px-3 py-1 text-sm"
  href={`https://${slug}.openstatus.dev`}
  target="_blank"
  rel="noreferrer"
>
  {label}
  <span class="relative flex h-2 w-2">
    {
      parsed.data.status === "operational" ? (
        <span
          class:list={
            [
              "absolute",
              "inline-flex",
              "h-full",
              "w-full",
              "animate-ping",
              "rounded-full",
              color,
              "opacity-75",
              "duration-1000",
            ]
          }
        />
      ) : null
    }
    <span
      class:list={
        [
          "relative",
          "inline-flex",
          "h-2",
          "w-2",
          "rounded-full",
          color,
        ]
      }>
    </span>
  </span>
</a>
```

--------------------------------

### Zod Schema for Monitor Failure Payload

Source: https://docs.openstatus.dev/llms-full.txt

This TypeScript code defines a Zod schema for validating monitor failure payloads. It specifies the expected types and structure for each field, including optional fields like statusCode, latency, and errorMessage.

```typescript
import {
  z
} from "zod";


export const PayloadSchema = z.object({
  monitor: z.object({
    id: z.number(),
    name: z.string(),
    url: z.string(),
  }),
  cronTimestamp: z.number(),
  status: z.enum(["degraded", "error", "recovered"]),
  statusCode: z.number().optional(),
  latency: z.number().optional(),
  errorMessage: z.string().optional(),
});
```

--------------------------------

### Define Status Enum and Calculation Logic (TypeScript)

Source: https://docs.openstatus.dev/llms-full.txt

TypeScript code defining the possible status values for a status page and a function to calculate the status based on a given uptime ratio. The ratio is derived from uptime and downtime of recent monitor checks.

```typescript
enum Status {
  Operational = "operational",
  DegradedPerformance = "degraded_performance",
  PartialOutage = "partial_outage",
  MajorOutage = "major_outage",
  UnderMaintenance = "under_maintenance", // currently not in use
  Unknown = "unknown",
  Incident = "incident",
}

function getStatus(ratio: number) {
  if (isNaN(ratio)) return Status.Unknown;
  if (ratio >= 0.98) return Status.Operational;
  if (ratio >= 0.6) return Status.DegradedPerformance;
  if (ratio >= 0.3) return Status.PartialOutage;
  if (ratio >= 0) return Status.MajorOutage;
  return Status.Unknown;
}
```