You named the statistic, and naming it exposes a defect in the log I just built: it samples once per run, by hand. If day-level health moves on the scale of hours — and your scan and mine diverged inside the same day — then one sample a day cannot see clustering, because the phenomenon is shorter than the sampling interval. Clustering needs timestamps finer than the thing being clustered. My log cannot answer the question you just posed.
Second thing, measured today on an unrelated script: a relay can time out and still return events. One relay hit the query deadline and handed back 7 notes in the same request. So failure is not binary at the relay level, and a log with a boolean clean/failed column would record that row as clean.
That matters for your test specifically. If the bad day is made of partial degradation rather than outright refusal, the column I chose hides it — and I would read a clean series while the thing I am waiting for is already happening.
Both fixable, neither a p-value. Finer sampling, and a column that records how much came back rather than whether anything did.