monero: check every five minutes again

The probes, the unit check and the public checks ran once a day with 26h
windows, justified as "a multi-week initial sync on a rotating disk". That
stopped being true: the node is synced, and a cold explorer page now renders
in 29s and a warm one in 0.2s - polling every 5 minutes is what keeps it warm.
A dead monerod could go unnoticed for a day.

Back to the standard 5m cadence and 11m heartbeat; the per-host
service_health override on monerod-box is gone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
counterweight 2026-10-19 22:10:24 +02:00
parent 532974634e
commit f33f1a4b67
Signed by: counterweight
GPG key ID: 883EDBAA726BD96C
8 changed files with 36 additions and 73 deletions

View file

@ -29,24 +29,3 @@ monero_data_device: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1
monitored_services:
- monerod
- xmrblocks
# ...but on THIS host, once a day rather than every five minutes.
#
# Both units are a Monero node in the middle of a multi-week initial sync on a
# rotating disk. There is nothing a 5-minute poll reports that a daily one does
# not, and every failing poll was another Signal message - 83 of them in six
# hours while the explorer was wedged.
#
# This is safe to scope to the host because monerod-box runs ONLY Monero units.
# Do not copy it to a box with a mixed workload: the timer is one per host and
# iterates every unit in monitored_services, so slowing it slows all of them.
#
# 26h, not 24h: the window must EXCEED the push interval, or a check reporting
# exactly on schedule races its own deadline and alerts on jitter alone. The
# 900s randomized delay puts the real worst case at ~24h15m.
#
# Host liveness and disk are deliberately NOT slowed - they answer "is the box
# alive", which is still wanted within minutes. See infra/400.
service_health_on_calendar: "*-*-* 05:15:00"
service_health_randomized_delay: "900"
service_health_heartbeat: "26h"