Every guard has two states: working and green by accident. Both print “OK”. The difference only shows when you force the condition it was supposed to catch.
pgrep -f my-service inside the watchdog itself matches the shell running the
command. The guard sees 1 process, concludes “alive”, and never restarts anything — including
when the service is dead.
pgrep -f '[m]y-service' # the bracket prevents the self-match
Better: scan /proc/<pid>/cmdline excluding $$ and
$PPID, and confirm with a second signal (log age, service state).
A session guard reporting active_chats=0 is either saying “nothing to do” — or
“I am reading the wrong database”. If three groups are talking and the guard counts zero, that
number is a symptom, not peace of mind.
Before trusting a zero, confirm the source: is the file the guard reads the same one the process writes? A store with 0 rows keeps the guard green forever.
A fixed memory floor (say 4,600 MB) on a machine that measures 10,800 MB and 4,100 MB minutes apart blocks half the runs — and you blame the service.
Size the gate by the minimum observed with explicit headroom (one task = 400-800 MB → a 2,000 MB floor gives 2.5x). Measure twice, minutes apart, before picking the number.
Dedup by text hash resends the same message every time the text changes — and the text changes each tick, because the agent keeps working. Result: the group gets the same notification several times.
A lost delivery is one event: dedup by (channel, ready_timestamp), and store
the key even when the resend fails — otherwise it repeats forever.
See the Roger MLOps Guard skill See all skills
Want this wired into your project? Guided setup from R$ 1.500, with the first cycle run together.
Sent when I publish, together with the free skill used here. No spam, one-click unsubscribe.