All three rules evaluate healthy after the pull and reload, with the prefix
matcher active and the probe named in the message.
Healthy only means a rule can be evaluated, not that it sees anything, so
the series underneath were checked as well. The new cronjob has info and
created series but no last_schedule_time - a manual run does not set it and
the first scheduled one is 04.09. Without the "or kube_cronjob_created"
fallback the rule would stand on an expression with no series for this
probe and could never fire: green, healthy and blind.
Whoever wrote that fallback a week ago did it as a precaution. Today it
carries real weight for the first time, on a cronjob that did not exist
when it was written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Thore CimbalandClaude Opus 5
94f0308c08