ike 🐶

A k9s-style terminal UI for Datadog. Triage alerts, read logs, chase traces and watch spend from your keyboard, across every one of your orgs at once.

_{Named after a dog named Ike. The command is ike; the job is keeping an eye on things.}

brew install cesarsk/tap/ike   # macOS and Linux
ike --demo                     # try the whole thing offline, no credentials

Why not just use the Datadog web UI?

Every org in one table. Datadog puts each org behind its own URL, so comparing dev, stage and prod means three tabs and three logins. Activate several contexts in :ctx and a single :monitors view spans all of them, with a CTX column saying where each row came from. The browser cannot do this.

Two keystrokes from an alert to its cause. l on a firing monitor opens the logs for that service. t on a log line opens the distributed trace it belongs to. P pages the team that owns the monitor, after telling you who that wakes up.

It stays where you already are. Same muscle memory as k9s: : for views (a Spotlight-style palette, type to filter), / to filter, enter to drill in, esc to go back. No tab switch, no dashboard load.

It shows you the bill. :cost is your Datadog spend: this month estimated and projected, twelve months of history with anomaly flags, per product or per sub-org.

 Mode:   demo [demo-dev]            <:>cmd  </>filter  <enter>details  <o>open
 Site:   datadoghq.eu                                           <c>copy  <C>cols
 View:   Monitors                   <ctrl-r>refresh  <p>auto:on  <esc>back  <?>help
 Budget: monitors 973/1000   :monitors :incidents :slos :logs :traces :services …
╔══════════════════════════════ Monitors(all)[18] ═════════════════════════════╗
║STATE   MUTED NAME                             TYPE             PRIO TAGS      ║
║Alert         Payments API p99 latency > 800ms metric alert     P1   team:pay…║
║Alert         Node not ready in prod           service check    P1   team:sre…║
║Warn          Vault sealed                     service check    P1   team:sre…║
║No Data       Datadog agent not reporting      service check    P2   team:sre…║
║OK            Kong data plane 5xx rate         metric alert     P1   team:sre…║
╚═══════════════════════════════════════════════════════════════════════════════╝

Everything it does (22 views, click to expand)

Status: real-org validated. Twenty-two views (monitors, incidents, SLOs, logs, traces, services with catalog metadata, service dependencies, events, RUM, synthetics, downtimes, dashboards, security signals, notebooks, hosts, containers, processes, error tracking, audit trail, cases, CI pipelines, agent fleet) plus :overview (cross-org triage), :metrics (a free-form metric explorer, charted full-pane), :cost (this org's Datadog spend: estimated + projected, 12-month trend with anomaly flags, per-product or per-sub-org), :oncall (who's on call now, the escalation ladder, and confirm-gated paging, per team) and :teams (the org's teams, drill into members and roles). Views can span several Datadog orgs at once (activate contexts with space in :ctx), log and trace correlation with a unified request timeline, an incident war room (people, impacts, to-dos), SLO error-budget burndowns, confirm-gated writes (mute a monitor, change incident state / severity / commander, incident to-dos, cancel a downtime, raise and resolve an On-Call page, page a monitor's on-call owner) with bulk selection (mark rows with space, then act on all at once), a per-service health rollup (monitors + SLOs + errors + events + on-call owner on one screen, h on :services), a fuzzy row finder, session restore, and an offline demo mode. New here? The User Manual is a full walkthrough.

New here? The User Manual walks through the whole thing.

Install

Homebrew (macOS and Linux):

brew install cesarsk/tap/ike

Prebuilt binaries: grab a tarball for your OS and architecture from the latest release (darwin and linux, amd64 and arm64), extract it, and put ike on your PATH.

From source (Go 1.25+):

go install github.com/Cesarsk/ike@latest

Quick start

# No credentials? Explore with demo data (ships two fake orgs, try :ctx):
ike --demo

# Sign in through your browser (OAuth2; no API keys, tokens auto-refresh):
ike auth login --site datadoghq.eu --org myorg
ike

# Or classic env vars, same as dogshell and Terraform:
export DD_API_KEY=...  DD_APP_KEY=...  DD_SITE=datadoghq.eu
ike

ike auth login opens Datadog's own login page (SSO and 2FA included), stores the tokens in your OS keychain tied to a named context, and refreshes them automatically. Re-run it any time to rotate. Orgs with a custom web subdomain pass --subdomain acme-dev. The same flow is available inside the app: in :ctx, add a context with the "Browser sign-in (OAuth)" auth type, then press O on its row to sign in. O also re-signs-in an OAuth context, or converts a key/token context to OAuth (it asks first).

The first launch opens a short getting-started page inside the app; reopen it any time with :manual.

The debugging loop

ike is built around the loop your on-call actually runs. A monitor fires, so you jump to its logs (l), then to the failing request's trace (t, the span waterfall showing every service hop and where the error is), then back to the logs for that whole trace (l). Monitors, logs and traces all connect by trace_id, in the terminal, without opening a browser tab. On any log line, x shows the surrounding context: a ±5-minute window around it from the same service, so you see what led up to the error.

Why ike

Datadog's official CLI, pup, is a scripting tool: 200+ commands with JSON output, built for automation and AI agents. It is the kubectl of Datadog. ike covers the other side: an interactive, keyboard-driven cockpit you sit in front of during an incident, the way you use k9s for Kubernetes. You browse, filter, drill down and take action, all from the keyboard.

Key bindings

The essentials (see the full reference in the Manual):

Key	Action
:	switch view: :monitors :incidents :slos :logs :traces :services :events :rum :synthetics :downtimes :dashboards :overview :cost :ctx :settings
/	filter rows with autocomplete in every view; in Logs/Traces/Events it is a Datadog search query
enter	detail view (SLO error budget, dashboard widget grid, incident People header, …)
l / t	drill to logs / to the trace waterfall (the debugging loop)
x	(logs) surrounding context: a ±5m window around the selected line
esc	back; also clears an active filter first
r / v	incident: change state / severity (confirm-gated)
I / T	incident: assign commander (searchable picker) / open the to-do panel
m / x	mute a monitor / cancel a downtime (confirm-gated)
Q / C	saved-query picker / column picker
F	fuzzy row finder on any table
space	in :ctx: activate a context so views span that org too
O	in :ctx: browser sign-in (OAuth) for the selected org
?	help, from any view

Multiple orgs (contexts)

Most companies run several Datadog organizations (dev, stage, prod, one per business unit, and so on). ike models each as a context, kubeconfig-style, in ~/.config/ike/config.yaml:

current-context: dev
contexts:
  dev:
    site: datadoghq.eu
    api-key-env: IKE_DEV_API_KEY     # the name of the env var holding the key.
    app-key-env: IKE_DEV_APP_KEY     # secrets never go in this file.
  prod:
    site: datadoghq.com
    api-key-env: IKE_PROD_API_KEY
    app-key-env: IKE_PROD_APP_KEY

• :ctx lists contexts; enter switches org. A switch drops the cache, rate-limit budget and navigation history, so nothing leaks between orgs.
• Add a context from inside the app with :ctx then a. The form asks how the org signs in first: browser sign-in (OAuth), an API/APP key pair, or a bearer token (key and token fields are masked). Secrets go to the OS keychain; only {site, keychain: true, auth} is written to the file. e edits a context in the same form later.
• Secrets are always env-indirected or keychain-stored. Plaintext api-key: fields are rejected at parse time. With no config file at all, the classic DD_API_KEY / DD_APP_KEY / DD_SITE vars act as an implicit default context.

Full context and auth details are in the Manual.

Built around Datadog's rate limits

Datadog's API is rate-limited per organization (log search is 300 requests per hour, for example), so you cannot poll it every few seconds the way you can a Kubernetes cluster. ike is built for that:

• every view is cached with a per-resource TTL, so navigating around spends no API budget;
• only the cheap views (monitors, incidents) auto-refresh;
• ctrl-r is the explicit "refresh from the API" action;
• the header shows your live rate-limit headroom, read from Datadog's own X-RateLimit-* response headers.

Customization

:settings edits the theme (ike, default, mono, nord, solarized) and per-view cache TTLs. C on any table opens a column picker (space to show/hide, J/K to reorder). Everything applies live and is saved to the config file, which is hand-editable too. See the Manual.

Development

go test ./...                                             # includes a headless TUI smoke test
IKE_DUMP=1 go test -run TestScreenDump ./internal/ui -v   # regenerate the README screens

pre-commit install                        # gofmt + vet + build on every commit
pre-commit install --hook-type pre-push   # run the test suite before pushing

The TUI is tested end-to-end on a tcell SimulationScreen, so no pty is needed. See docs/ARCHITECTURE.md for the design and docs/DESIGN.md for decisions and roadmap.

License

Apache 2.0