Open Source

Set it once. Let the agent watch.

kb-monitor observes services deployed via kb-deploy. Every command has --json with a stable schema, so an agent can poll health, read logs, and react — while you stop thinking about monitoring as a task you own.

curl -fsSL https://kblabs.ru/kb-monitor/install.sh | sh

Documentation GitHub Releases

You know this.

Something is wrong in prod. You SSH into the host, docker ps, grep for the container, docker logs, scroll through a wall of text, forget the flag for tail, try again. Ten minutes before you've seen a single relevant line.

kb-monitor logs <target> --follow. Tailing logs from your laptop, no SSH session, no container name to remember.

A service went down at 3am. You want to know: is it alive now? When did it come back? What image SHA is it on? You run three different commands against the host to piece it together.

kb-monitor status shows every target in one table: running state, uptime, image SHA — ready to paste into an incident channel.

Your agent wrote a hotfix and deployed it. Now it needs to verify the deploy actually went through and the service is healthy. Without structured output it has to parse docker ps output.

Every command supports --json with a stable schema. Agents get a clean dataset to reason over — no screen-scraping.

Monitoring as something your agent does.

Every kb-monitor command outputs structured JSON with a stable, documented schema. Point an agent at it on a schedule and monitoring stops being a human task — it becomes a loop that reacts on its own.

Same pattern works with any agent runtime — Claude, Codex, your own plugin-agent running inside KB Labs. The stable schema is the contract.

agent-watchdog.sh

# run every 5 minutes via cron or kb-dev schedule
kb-monitor status --json > /tmp/state.json

# the agent reads state, reasons over it, and reacts:
#   - health failing on kb-labs-web → kb-deploy run kb-labs-web
#   - new SHA in prod → post to #releases
#   - container restarting → fetch logs and open an issue
#
# you wrote the rules once. you never open a terminal again.

Same file as kb-deploy.

kb-monitor reads .kb/deploy.yaml — the same file your deploys come from. No second source of truth, no parallel inventory to keep in sync.

Deploy and observe are paired by design. If kb-deploy knows about a target, kb-monitor knows about it too.

.kb/deploy.yaml

registry: ghcr.io/your-org

targets:
  api:
    path: apps/api
    host: prod-1
    compose: infra/compose/api.yml
    health: http://localhost:3000/health

  web:
    path: apps/web
    host: prod-1
    compose: infra/compose/web.yml

infrastructure:
  postgres:
    host: prod-1
    image: postgres:16

  redis:
    host: prod-1
    image: redis:7

How it works

The things that matter once your services are running.

Health across every target, one command

health runs HTTP or TCP probes against every target defined in deploy.yaml. Pass or fail per service, with latency.

Running state, uptime, and image SHA

status gives you the three things you always want during an incident — current state, how long it's been that way, and exactly what's running.

Remote logs without SSH sessions

logs streams docker logs from the host. --lines for a tail, --follow for live tail. No more SSH into a box just to tail a file.

Exec into a running container over SSH

exec runs a command inside the running container for a target. Useful for one-off checks: df -h, ps, cat a config, run a migration.

Stateful infra gets the same treatment

The databases, caches, and brokers declared in deploy.yaml show up in status and health alongside your app services.

Every command is scriptable

All commands support --json with stable, documented schemas. Agents and CI pipelines get a clean data layer to work with.

Commands

All commands support --json for scripting and agent workflows.

kb-monitor health

Run health probes against every target. Pass or fail per service, with response latency.

kb-monitor health kb-labs-web

Probe a specific target. Useful for post-deploy verification in CI or agent workflows.

kb-monitor status

Running state, uptime, and image SHA for every target. The three things you need during an incident.

kb-monitor status --json

Structured output for agents and dashboards. Stable schema, every field documented.

kb-monitor logs kb-labs-web --lines 100

Fetch the last 100 lines of logs for a target. No SSH session, no docker ps needed.

kb-monitor logs kb-labs-web --follow

Stream live logs for a target from your laptop. Ctrl-C to stop, no cleanup needed.

kb-monitor exec kb-labs-web -- df -h

Execute a command inside the running container. Any command after -- is passed through verbatim.

kb-monitor infra

Show runtime state of every stateful service declared in deploy.yaml.

Download

Pre-built binaries for macOS, Linux, and Windows. SHA-256 checksums included in every release.

PlatformBinaryDownload

macOS (Apple Silicon)kb-monitor-darwin-arm64Download

macOS (Intel)kb-monitor-darwin-amd64Download

Linux (x86_64)kb-monitor-linux-amd64Download

Linux (ARM64)kb-monitor-linux-arm64Download

Windows (x86_64)kb-monitor-windows-amd64.exeDownload

Part of KB Labs

kb-monitor ships as a standalone binary and as part of the KB Labs platform. When you install KB Labs, kb-monitor is included automatically.

Install KB Labs →