Change interval

README.md

@@ -8,9 +8,12 @@ A small single-container Python 3 uptime monitor.
 - **DNS resolution never uses the system/router-provided resolver** —
   every lookup is sent explicitly and only to the DNS server configured
   for that endpoint (see "How DNS enforcement works" below).
-- Runs a full rolling pass over all endpoints every 10 minutes (configurable).
+- Checks are spread evenly across `interval_seconds` rather than all
+  firing at once: with N endpoints, one is checked every
+  `interval_seconds / N` seconds, rotating through all of them (see
+  "Scheduling" below).
 - If any endpoint fails, all endpoints are immediately re-checked once,
-  instead of waiting for the next scheduled pass.
+  instead of waiting for their normal rotation slot.
 - Writes every check result to an InfluxDB 2.x bucket (`uptime`) over
   HTTPS, with certificate verification disabled for InfluxDB specifically
   (self-signed cert).
@@ -47,7 +50,8 @@ influx:
   verify_ssl: false      # keep false: influx uses a self-signed cert
 
 check:
-  interval_seconds: 600                  # 10 min rolling interval
+  interval_seconds: 600                  # each endpoint checked once per this many seconds,
+                                          # spread evenly across N endpoints (see Scheduling below)
   timeout_seconds: 10                     # default per-check timeout
   immediate_recheck_delay_seconds: 5      # pause before the failure-triggered recheck
 
@@ -106,15 +110,38 @@ from(bucket: "uptime")
   |> filter(fn: (r) => r._field == "success")
 ```
 
+## Scheduling
+
+Endpoints are **not** all checked together and then slept on as a batch.
+Each endpoint gets its own slot, spread evenly across `interval_seconds`:
+with N endpoints configured, one is checked every
+`interval_seconds / N` seconds, rotating through all of them. So
+`interval_seconds: 3600` with 6 endpoints means one endpoint is checked
+every 10 minutes — each individual endpoint is still only checked once
+per hour, but the 6 checks are spread across that hour instead of firing
+all at once, then waiting an hour.
+
+Example with 3 endpoints and `interval_seconds: 600` (so ~200s apart):
+
+```
+t=0s     endpoint A checked
+t=200s   endpoint B checked
+t=400s   endpoint C checked
+t=600s   endpoint A checked again   (600s after its previous check)
+t=800s   endpoint B checked again
+...
+```
+
 ## Failure / immediate recheck behavior
 
-- Every `check.interval_seconds`, all endpoints are checked in sequence.
-- If any endpoint fails that pass, after `immediate_recheck_delay_seconds`
-  all endpoints are checked again immediately (one extra pass).
-- The monitor then returns to the normal `interval_seconds` schedule.
-  If the outage continues, the next scheduled pass will detect it again
-  and trigger another single immediate recheck — it does not hammer the
-  endpoint in a tight loop.
+- If any single endpoint check fails, **all** endpoints are checked once,
+  immediately, after `immediate_recheck_delay_seconds` — instead of
+  waiting for their normal rotation slot.
+- The rotation is then re-spread evenly from that point, so it doesn't
+  bunch endpoints back up onto the same slot, and resumes normally.
+- If the outage continues, that endpoint's next regular slot will detect
+  it again and trigger another single immediate recheck of everyone —
+  it does not hammer the endpoint in a tight loop.
 
 ## Local dev (without Docker)