--- 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/).