Files
werkregie/doc/prs/2026-10-12-PR#34-critical-charts.md
claude-code e496dddd30
werkator build succeeded after 00:41
The three most critical charts of a Werkator (#34)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-12 12:55:49 +02:00

2.3 KiB

PR#34: The Three Most Critical Charts of a Werkator

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

Problem

A Werkator panel shows 5 to 6 charts, most of them of metrics that are fine. The user wants to see only what matters now.

After the deployment of 0.13.0 the charts stayed empty until the page was reloaded: when the first read of Werkator's history fails, the next one comes only after 5 minutes.

Non-Goals

  • No new layout of the tiles; it stays as in PR#31.

Specification

Feature: Werkator panel with its most critical charts

Scenario#34.01: the three most critical charts

… so that the panel shows only what needs attention.

  • Given a Werkator with swap in use above its threshold and the other metrics fine
  • When the user opens the overview
  • Then its panel shows swap and the two metrics closest to their thresholds, in Werkator's order
Verified by
  • WerkatorSourceTest: "a metric above its threshold comes first, then the ones closest to theirs"; "the load holds the three most critical charts in Werkator's order" with critical RAM and HDD.

Scenario#34.02: a failed history is read again soon

… so that the charts do not stay empty for minutes.

  • Given a Werkator whose history did not answer
  • When the dashboard reads the Werkator again after 30 seconds
  • Then the panel shows the lines of the history
Verified by

Solution

  • WerkatorSource ranks all metrics: by level first, then by the value against its warning threshold. It keeps the 3 highest and shows them in Werkator's order: CPU, RAM, disks, load, swap, the waits.
  • CPU, RAM and the disks warn at 80 %, load at 1 per thread.
  • A failed read of the history keeps the last lines and does not count as read, so the next fetch, 30 seconds later, reads it again.
  • The history gets the same timeout of 30 seconds as the builds.
  • Version 0.19.0.

Open Questions

None.