Using Moonway

What changed

A journal of every meaningful cluster change — deploys, scales, image swaps, crashes, Helm operations — kept on disk for 14 days.

Most incident reviews start with the same question: what changed right before this broke? Kubernetes doesn't keep that answer — Events expire in an hour, and a rollout overwrites the evidence of the one before it. Moonway does: the daemon diffs its watch stream and journals every meaningful change to disk.

What gets recorded

  • Rollouts — image changes with the old and new tag, and deployment lifecycle from created to deleted.
  • Scale changes — replica counts moving, whether a human or an autoscaler moved them.
  • Crashes — container exits with their restart count, escalating in severity as restarts accumulate.
  • Helm operations — installs, upgrades, rollbacks and failures, read from Helm's own release records.
  • Lifecycle — namespaces and jobs appearing, finishing, disappearing.

Each entry carries its severity, the object it's about, and the moment it happened — a chronological, per-cluster record you can scroll back through and jump from straight to the object.

Kept on disk, not in memory

The journal writes to a local SQLite file, so it survives daemon restarts, app updates and reboots. Retention is 14 days by default; running the daemon yourself, --retention-days sets the window (0 keeps everything) and --db=postgres://… moves the journal to Postgres.

The journal is only as complete as the watching. With Start at login on, changes are recorded around the clock; otherwise recording runs while the app does. For a journal the whole team shares, run the daemon in the cluster.

Why triage and the timeline agree

Both are computed by the same daemon from the same watch stream — the crashloop on Triage and the image change that caused it in the journal are two views of one record, not two systems that can drift.