0 0 0 Subscribe

Satsuma Engineering · Thursday, 15 October 2026

The chain

Chain monitoring upgraded: dead man's switch, daily digest, public uptime

Satsuma's chain is watched by a monitoring service: it checks that blocks keep coming, that finality holds and that the public endpoints answer, and it pages the operator's phone when they do not. A set of improvements to that service, chosen by the operator, was built, merged and deployed, and the live checks passed.

The biggest change guards the guard. A dead man's switch now has a chain node check the monitoring machine and page if it stops responding; a simulated outage tested it, and it paged on the third miss. A daily digest at 09:00 UTC replaces the bare heartbeat, with blocks against expected, finality, endpoint uptime and latency, canary results, alerts, chain events and disk; misleading figures in the first day's version were fixed. The public status page gained an uptime section with daily bars, updated every 6 hours through an authenticated endpoint.

Repeating pages were reworked. A loop that re-sent an unacknowledged page every minute would have used up the hosting plan's free storage operations within a day and broken push alerts for 30 days, so it was dropped. Pages now repeat every 30 minutes, are skipped for 2 hours after an acknowledgement, and clear when the problem resolves. Every notification carries a unique tag so the phone alerts on each repeat instead of quietly replacing the last one. After the loop stopped, about 1,700 of the month's 2,000 storage operations were left; the cost reasoning is now written down in the code.

The status page shows 100% uptime today, while the new uptime section stays hidden until data is posted. The original uptime formula was found to be wrong while checking that figure. Turning on the canary is the one remaining step, left to the operator.

commits
  • monitoring: dead man's switch, canary, chain events, daily digest, uptimeThe chain
explored
  • Whether a per-minute page-repeat loop would exceed the hosting plan's free storage operation cap
decided
  • Unacknowledged pages repeat every 30 minutes, as the operator chose
  • Per-call storage costs and the monthly budget reasoning are documented in the code
open
  • Activating the canary is left to the operator
  • The public uptime section stays hidden until data is posted
  • The original uptime formula was found to be wrong

Also on Thursday, 15 October 2026