A check that notices more than an outage

An ordinary ping is green while the server returns anything at all. The nastiest kind of failure looks different: the service answers 200 and says in the body that the queue is growing and the database is not responding. Customers already feel that; monitoring does not.

What is inside

1. Scheduled trigger — the entry.
2. Request to /health is made with “fail on a bad status” turned off: we want the body in every case, including the ones where the code is not 200.
3. What exactly it answered — a three-way branch. Conditions are checked top to bottom and nothing past the first match is evaluated.
4. Two branches write to Telegram in different words; the third simply ends.

The order of the conditions carries weight: “down entirely” sits above “answering wrongly”, because a service that has fallen over may have no body at all, and reading a field out of it would produce an error instead of a diagnosis.

What to set up for yourself

• The address and the conditions. The scenario assumes an answer shaped like {"status": "ok"}. If yours differs, edit the expression in the second branch row: it reads nodes.check.output.body.status.
• The message texts. They carry the status code and the field value, so one message is enough to know where to look.
• The third branch deliberately sends nothing. Add a send if you want an “alive” confirmation, but remember: a notification that arrives every half hour stops being read within a day.

What to connect

A Telegram bot and the Schedule target on the Publish tab. The address may be an internal one as long as it is reachable from the internet; a closed network is not visible from here.