---
title: "CLI"
publishedAt: "2026-04-29"
author: "Maximilian Kaske"
description: "Manage monitors, status pages, and incidents from your terminal — interactive for humans, scriptable for agents, and YAML-managed for monitoring as code."
category: "Product"
faq:
  - question: "Is the CLI suitable for AI agents?"
    answer: "Yes. Every command supports --json output and structured errors, and required flags fail with a clear list of what's missing instead of hanging in a wizard. Combined with our agent skills, the CLI is the recommended way to give AI agents scriptable control over openstatus."
  - question: "Can I run the CLI in CI?"
    answer: "Yes. Set OPENSTATUS_API_TOKEN, use the --json flag for parseable output, and run openstatus monitors apply to sync your YAML config. We also publish a GitHub Action that wraps the CLI for synthetic tests."
  - question: "What's the difference between the CLI's YAML config and the Terraform provider?"
    answer: "Both treat monitoring as code. The YAML config is lighter to adopt and lives next to your repo. Terraform is the right choice when monitors are part of a larger HCL-managed infrastructure. Run openstatus terraform generate to bootstrap an HCL file from your existing workspace if you want to migrate."
  - question: "Are skills different from the MCP server?"
    answer: "Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows."
---

The openstatus CLI is the terminal interface to your workspace. It works for both humans (interactive wizards, colors, spinners) and agents (`--json`, deterministic flags, structured errors) — and it lets you keep your monitor configuration as YAML in your repo.

## Quickstart

```bash
brew install openstatusHQ/cli/openstatus --cask
openstatus login
openstatus whoami
openstatus monitors apply
```

Set `OPENSTATUS_API_TOKEN` to skip the login flow in CI.

## What you can do

- Manage monitors, status pages, status reports, and maintenance windows.
- Sync a YAML config with `openstatus monitors apply` — monitoring as code, no HCL required.
- Bootstrap a Terraform configuration from your workspace with `openstatus terraform generate`.
- Pipe `--json` output into `jq`, agents, or your own scripts.

## GitHub Action

Run the CLI from a workflow with the published [GitHub Action](https://github.com/openstatusHQ/cli-action) — drop it into your release pipeline to apply monitor config changes, trigger synthetic checks on deploy, or fail a deploy when a probe regresses.

```yaml
- uses: openstatusHQ/cli-action@v1
  with:
    api-token: ${{ secrets.OPENSTATUS_API_TOKEN }}
    args: monitors apply
```

## AI skills

[Openstatus skills](https://github.com/openstatusHQ/skills) are agent-ready bundles that wrap the CLI for terminal-shaped AI workflows like Claude Code. Install once, then let your agent draft incidents, schedule maintenance, and post status updates on your behalf.

```bash
npx skills add openstatushq/skills
```

You get incident communication templates, maintenance announcement drafts, periodic status reports, and shared status-page context so every skill speaks in your voice.

## Auth & audit

Authenticate with `openstatus login` (browser flow) or `OPENSTATUS_API_TOKEN` (CI). The token is the same one the API, Terraform provider, and MCP server share — generate it from **Settings > API Tokens**.

Every mutation lands in the audit log under `actor_type = 'cli'`, so you can trace any change back to a key, a user, and a transport.

## Other surfaces

- Want chat-shaped AI access from Claude or ChatGPT? See the [MCP server](/tooling/mcp-server).
- Already managing infrastructure in HCL? Use the [Terraform provider](/tooling/terraform).
- Building an in-app integration? Call the [API](/tooling/api) directly.

## Reference

Full command list and flags in the [CLI reference](https://www.openstatus.dev/docs/reference/cli-reference/).

## Frequently asked questions

<Details summary="Is the CLI suitable for AI agents?">

Yes. Every command supports --json output and structured errors, and required flags fail with a clear list of what's missing instead of hanging in a wizard. Combined with our agent skills, the CLI is the recommended way to give AI agents scriptable control over openstatus.

</Details>

<Details summary="Can I run the CLI in CI?">

Yes. Set `OPENSTATUS_API_TOKEN`, use the `--json` flag for parseable output, and run `openstatus monitors apply` to sync your YAML config. We also publish a GitHub Action that wraps the CLI for synthetic tests.

</Details>

<Details summary="What's the difference between the CLI's YAML config and the Terraform provider?">

Both treat monitoring as code. The YAML config is lighter to adopt and lives next to your repo. Terraform is the right choice when monitors are part of a larger HCL-managed infrastructure. Run `openstatus terraform generate` to bootstrap an HCL file from your existing workspace if you want to migrate.

</Details>

<Details summary="Are skills different from the MCP server?">

Skills are prompt and command bundles installed into your local agent (Claude Code, etc.) that wrap the openstatus CLI. The MCP server is a remote endpoint that any MCP-compatible client can connect to. Skills are great for terminal-shaped workflows; MCP is great for chat-shaped workflows.

</Details>