For the complete documentation index, see llms.txt. This page is also available as Markdown.

ilert CLI

The official ilert command line interface. Every API endpoint, generated from ilert's OpenAPI spec at runtime, batteries included.

Unlike the language clients, the CLI builds its command tree from ilert's OpenAPI spec at runtime rather than shipping a hand-written list of commands. Every endpoint is reachable, and the commands cannot fall behind the API. It is also built to help you manage your ilert credentials in a safer way and lets you manage your ilert user through your favorite AI agent.

Install

curl -sL https://raw.githubusercontent.com/iLert/ilert-cli/master/install.sh | bash -

Docker images and build-from-source instructions are in the repository. You can find the source code on our Github organization: https://github.com/iLert/ilert-cli

Authenticate

ilert auth login

This opens your browser and completes an OAuth flow, which is the recommended way of using it for individuals. In CI, set ILERT_API_KEY instead and every command picks it up with no login step.

Use

ilert alerts list                               # list open alerts
ilert alerts ack 42                             # accept alert #42
ilert incidents create --set summary=...        # create an incident
ilert event send -k <INTEGRATION_KEY> -s "msg"  # fire an event at an alert source
ilert dashboard                                 # live TUI

ilert --help lists every resource and action, and ilert api /any/path calls an endpoint directly. Add --dry-run to any command to print the request without sending it, and -o json with --jq to filter output.

Agents

The CLI is also one of ilert's agent-facing interfaces. Anything a person can do in ilert, an agent with the CLI can do too — described in plain language instead of clicked through a UI.

That works because the command tree is generated from ilert's spec at runtime. An agent does not need a wrapper someone kept up to date; it discovers the platform while it works:

Built for unattended execution

Handing an agent write access to your on-call setup only works if the tool is honest about what it is doing:

  • Destructive commands should prompt when no human is attached. They exit 2 with a JSON envelope describing what they refused, so an agent reports the refusal back to you instead of hanging on an invisible prompt or inventing a --yes.

  • --dry-run prints that same envelope without touching the network or the keyring. The agent can plan a whole change set and show it to you before a single request is sent.

  • Output is machine-readable. -o json/ndjson (the default when piped) with --jq means the agent reads results rather than scraping a table.

  • Credentials stay out of the conversation. OAuth tokens live in the OS keyring, nothing needs to be pasted into a prompt.

Skills — what the agent needs to know

Knowing the commands is not the same as knowing the platform. Most mistakes come from concepts, not syntax: an ilert Service is not a routing object, ACCEPTED deliberately stops escalation, support hours downgrade alerts rather than suppress them.

The CLI ships that knowledge as skills — markdown playbooks the agent reads on demand:

What it looks like in practice

Any AI agent — Claude Code, Codex, Cursor, and others — can use the CLI, but it has to know it is there. Tell it once, in the prompt or in the project's agent instructions file (AGENTS.md, CLAUDE.md, or the equivalent), a single line is enough, as the CLI ships internal hints for agents automatically:

From then on you can ask for outcomes instead of commands:

The agent picks the endpoints, runs the calls, and returns the result. You review the plan, not the payloads — same API, same permissions, same audit trail as any other client.

Migrate to ilert

Last updated

Was this helpful?