Joelclaw runtime-monitor

Monitor ADR-0217 real workloads across Redis queue, Restate, Dkron, and transitional Inngest using joelclaw CLI plus the pi TUI monitor extension. Use when asked to monitor jobs, watch runtime health, keep an eye on async work, run a workload dashboard, or report back on system state. Always pair with `pi-tui-design` for TUI work and `system-architecture` for topology truth.

install

source · Clone the upstream repo

git clone https://github.com/joelhooks/joelclaw

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/joelhooks/joelclaw "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/runtime-monitor" ~/.claude/skills/joelhooks-joelclaw-runtime-monitor && rm -rf "$T"

manifest: skills/runtime-monitor/SKILL.md

Runtime Monitor

Use this skill when the task is real workload monitoring, not vague status-checking.

The canonical operator surfaces are:

```
joelclaw jobs status
```
```
joelclaw queue depth
```
```
joelclaw queue control status
```
```
joelclaw queue observe
```
```
joelclaw restate status
```
```
joelclaw restate cron status
```
pi extension tool:
```
runtime_jobs_monitor
```

Load order

Before doing runtime monitor work:

load
```
system-architecture
```
load
```
pi-tui-design
```
if you are building or changing the monitor widget/TUI
load
```
joelclaw
```
for CLI operator flows

What to use when

First glance

joelclaw jobs status --hours 1 --count 10

This is the first operator answer to:

can the system take more work right now?
is the queue/runtime layer healthy?
is Dkron alive?
is Inngest still healthy during transition?

Queue-specific investigation

joelclaw queue depth
joelclaw queue control status --hours 1
joelclaw queue observe --hours 1
joelclaw queue stats --since <iso|ms>

Use these once

jobs status

tells you the queue layer is the interesting bit.

Runtime substrate investigation

joelclaw restate status
joelclaw restate cron status
joelclaw runs --count 20 --hours 1

Use these when the top-level surface says Restate, Dkron, or transitional Inngest needs a closer look.

Async pi monitor

The loaded pi extension at

packages/pi-extensions/inngest-monitor/index.ts

exposes:

```
runtime_jobs_monitor
```
```
inngest_send
```
```
inngest_runs
```

Start

{"action":"start","interval":5,"report":true}

Effects:

polls
```
joelclaw jobs status
```
in the background
paints a persistent TUI widget
emits OTEL on runtime severity changes and meaningful workload-state changes
sends hidden follow-up summaries when the runtime meaningfully changes or the monitor stops/times out

Status

{"action":"status"}

Returns the latest runtime snapshot:

overall status/summary
queue depth
active pause count
Restate / Dkron / Inngest state

Stop

{"action":"stop"}

Stops the background poller and sends a final follow-up summary.

Rules

```
joelclaw jobs status
```
is the aggregated truth surface; do not rebuild the same picture by hand unless the command is wrong.
If
```
jobs status
```
is noisy or misleading, fix it first. Don’t teach agents to ignore a lying operator surface.
For TUI work, prefer compact status blocks with explicit severity and short summaries. No decorative sludge.
Any runtime monitor widget line must be clamped to the active terminal width with pi-tui truncation (
```
truncateToWidth
```
/
```
visibleWidth
```
). Pi will crash narrow terminals if a custom widget emits over-wide lines.
During transition, Inngest stays visible but must not dominate the runtime story when Restate + queue + Dkron are the real workload path.
Report earned truth only. If the monitor compiles but hasn’t been dogfooded, say that.