Skip to main content

oo

A small CLI for the OpenObserve HTTP API. Commands are a transcription of the API rather than a model of it: oo get dashboards is GET /api/{org}/dashboards, and anything the CLI does not know about is still reachable with oo api.

oo get dashboards
oo get alerts --folder default           # GET /api/v2/{org}/alerts?folder=default
oo get streams/app_logs
oo post alerts -f alert.json
oo put dashboards/0194f0e1 -d @- < dashboard.json
oo delete alerts/7

oo search --sql "select * from default limit 10" --from -30m
oo api GET /api/default/prometheus/api/v1/query --query "up"

Any --name value or --name=value the CLI does not define becomes a query parameter. -d takes a literal body, @file or @- for stdin; -f file is shorthand for -d @file. Output is pretty-printed JSON on stdout, errors on stderr, exit code 1 on HTTP >= 400 and 2 on a bad command.

Times accept now, an offset (-15m, -2h, -7d), an epoch timestamp in seconds, milliseconds or microseconds, or an ISO 8601 datetime (local time when it carries no zone).

Install

uv tool install openobserve-cli     # installs the `oo` command
uvx openobserve-cli get streams     # or run it without installing anything

The command is oo; openobserve-cli is the same command under the distribution's name, which is what makes the uvx one-liner work. From a checkout: uv sync and then uv run oo --help.

Configuration

Everything comes from the environment. Nothing is required: with no variables set the CLI talks to http://localhost:5080 as an anonymous user, which is what a port-forward to a local OpenObserve looks like.

Variable Required Default Meaning
OO_ENDPOINT optional http://localhost:5080 base URL
OO_ORG optional default organization
OO_TOKEN to reach anything but /healthz base64 of email:token, sent as basic auth
OO_USER / OO_PASSWORD instead of OO_TOKEN the same credential spelled out
OO_COOKIE when a gateway guards the host Cookie header, sent verbatim
OO_TIMEOUT optional 60 request timeout in seconds

--endpoint, --org and --timeout override the corresponding variable.

When something authenticates in front of OpenObserve

Plenty of deployments put OpenObserve behind a gateway that authenticates users itself: an AWS ALB with an authenticate-oidc action, oauth2-proxy, an identity-aware proxy. Such a gateway takes nothing but its own session cookie, which it issues to a browser at the end of an interactive login — no API token gets past it, and a CLI cannot run that flow on its own.

So hand it the cookie your browser already has. In devtools, Network tab, take the Cookie header off any request to that host (or Application, Cookies) and:

export OO_COOKIE="AWSELBAuthSessionCookie-0=...; AWSELBAuthSessionCookie-1=..."

It is sent verbatim, so any gateway's cookie works, whatever it calls it. A request that hits the gateway without one says so instead of failing on a page of HTML. The cookie expires on the gateway's schedule — an ALB session lasts 7 days by default.

The gateway is orthogonal to OpenObserve's own authentication: the cookie gets you through the door, OO_TOKEN still identifies you to OpenObserve.

v1 and v2

Where an endpoint exists in both versions, v2 is used; there is no version switch. The CLI reads the instance's own OpenAPI document (/api-doc/openapi.json) to decide, so it follows whatever is deployed. The document is cached per endpoint under ~/.cache/oo-cli for a week.

oo spec paths alerts     # list endpoints and their methods
oo spec refresh          # refetch after an OpenObserve upgrade

Without a reachable spec the CLI falls back to v1, except for alerts, folders and reports, the three resources that have a v2 in OpenObserve 0.91.

Skill for agents

The CLI carries a skill for coding agents: how the commands map onto the API, what the bodies look like, and a reference for every endpoint, written from an instance's own OpenAPI document. It installs itself.

oo skill install            # -> ~/.agents/skills/openobserve
oo skill update             # after upgrading the CLI

--dir puts it wherever your agent looks (oo skill install --dir ~/.claude/skills, or --dir .claude/skills for a single project), --force overwrites an existing copy, and oo skill path prints the bundled original. Without installing anything: uvx openobserve-cli skill install.

The files are also plain Markdown in skills/openobserve, so any agent that reads Markdown can be pointed straight at SKILL.md.

Development

uv sync
uv run pytest
pre-commit install     # ruff, mypy and conventional commit messages

Release files for openobserve-cli 0.2.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for openobserve-cli 0.2.1
File Size Uploaded
openobserve_cli-0.2.1.tar.gz 38.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for openobserve-cli 0.2.1
File Interpreter ABI Platform
openobserve_cli-0.2.1-py3-none-any.whl Python 3 none any Details

Total release size: 83.5 kB

Release files / openobserve_cli-0.2.1.tar.gz

Download URL openobserve_cli-0.2.1.tar.gz
Size 38.6 kB
Tags Source
SHA-256 checksum
How to use checksums
5895db9223ab12a42e4a1d74bf41d457dcb07a23307b64f3e3f89ea94e8ffb22
BLAKE2b-256 checksum
How to use checksums
3e4a926f64fdeec3d00c8214bb0aab2342b1a2ca9d3c624c64756ff705cbd521
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.

Transparency log

Release files / openobserve_cli-0.2.1-py3-none-any.whl

Download URL openobserve_cli-0.2.1-py3-none-any.whl
Size 44.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
89f7d9c0fd6a0b4710fd5c68cbffb7f82bb4bce47bc1d2e1ebfa6d8e8513ae4b
BLAKE2b-256 checksum
How to use checksums
04ca7df6f294a67c08036aa68ee24c7e5efb28c32ebd7935eb6528309ef7b91a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.2.1 This release

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page