Operating Blue Canoe · 3 of 3
One Green Report Is Only One Day
Giving Blue Canoe's daily mail reports a history while keeping publication small and recoverable.
A daily report can tell me whether today's checks passed. It is less good at showing whether something has been changing slowly for a fortnight.
The mail platform already produced structured daily reports. The next useful step was to give those observations a history, without building a second monitoring platform just to display them.
Reuse the observations
The trends work reads the existing report data. It does not need to send test messages or interfere with mail delivery in order to draw a chart.
Its contract defines which reports are comparable: the required traffic, filtering, filesystem and certificate fields must be present for all three nodes. The default window is the latest 90 comparable report dates.
“Comparable report dates” matters. It is not automatically the same thing as 90 consecutive calendar days. An incomplete report cannot be made comparable by giving it a place on a graph.
That keeps the history tied to what was actually recorded rather than the shape we would like the chart to have.
A chart should not hide its numbers
The first published page contained ten charts and ten corresponding data tables. A visual trend helps with inspection; the table makes its individual observations available without requiring someone to interpret the picture.
The page is static. It does not need an interactive application simply to present a fixed set of dated results. Its stylesheet is separate, and the publication checks recorded no inline scripts or styles.
That is a small implementation choice with an ongoing benefit: fewer moving parts in the thing we use to inspect the other moving parts.
Failure should leave useful evidence behind
The publication design retains the last good page if generation or publication fails. A new result is prepared separately and replaces the existing output only after the relevant checks succeed.
The failure must still be reported. Keeping yesterday's page available is useful; allowing it to masquerade as today's successful run is not.
The trends contract therefore couples preservation with a warning and diagnostic, while allowing the main daily report to continue. An optional historical view should not prevent the current report from doing its job.
Installation is not the final observation
The 14 September installation record confirms the initial publication: 36 comparable report dates, from 9 August to 13 September, with matching worker and public-host files and successful public responses.
We did not rerun the daily report or send another email to demonstrate the installation. The existing daily-report pointers were left alone.
That leaves a deliberate distinction in the record. Initial publication was checked; the next normal scheduled run still needed observation to establish automatic refresh and the new notification links. The evidence used here does not close that later check.
History changes the question
The earlier reporting work asked whether the result could be trusted. This addition asks what a sequence of trustworthy results can tell us.
It is no longer just “Is this acceptable today?” It is also “What has changed, when did it begin, and is it worth investigating?”
One green report is one observation. Keeping the history makes it possible to ask the next question.