Dashbox

Chapter 7

It writes down only what changed

A card is read many times a day. Almost none of those readings are news.

Readings against events in the example monthTwo lanes over 30 days. The upper lane, readings, is a dense comb of ticks: about 2,880 readings. The lower lane, events, has seven marks: days 14 and 17, two on day 21, and days 22, 23 and 24.readings: about 2,880events: 7day 1day 15day 30
The upper lane is every reading, far too many to draw one by one. The lower lane is what the history keeps: seven changes of state.

Readings arrive often - an API collector fetches every 15 minutes by default. If every low reading wrote a line, the history would be noise, and nobody would read it.

So Dashbox writes an event only when the card's state changes: it went low, went critical or came back to normal; it turned stale (its collector has not checked in for more than twice its interval), got an error from its source, or its data came back; it reached its target.

A card that stays critical for three days has one event on the day it went critical, and one more when it comes back. Events are judged by the same rules as the colour, so the history never disagrees with what the card showed.

Changes to how the number is read - its name, unit, direction, display or trigger - are kept in the same history. A step that comes from a new definition is not mistaken for a change in the world.

In the example month

An example, not real data.

Day 21
The API answers once with an error: an "error" event with the source's message, then "data back" at the next good fetch.
The month
About 2,880 readings (every 15 minutes for 30 days) and seven events: target reached on days 14 and 17, error and data back on day 21, went low on day 22, went critical on day 23, back to normal on day 24. The change of target on day 28 is in the same history.