Pattern 1: Site Health Monitor

Module 4 · Section 2 of 6

Pattern 1: Site Health Monitor

What it does: Checks nine websites every six hours. Sends a Telegram alert if any site returns a non-200 status or doesn’t respond.

Why it exists: I manage several sites across different hosting providers. I don’t want to manually check them. I want to know within hours if something goes down, not days.

The nodes:

1. Schedule trigger — Cron expression 0 */6 * * *. Fires at 0:00, 6:00, 12:00, 18:00.

2. Split in Batches — I have a list of nine URLs set as workflow-level variables. The Split in Batches node processes them one at a time in a loop.

3. HTTP Request — Makes a GET request to the current URL. Timeout set to 10 seconds. Error handling set to “continue on error” — this is important, because if a site is completely down the HTTP request will throw rather than return a status code. Continuing on error means the workflow keeps running and you can check the error data.

4. IF node — Checks two conditions: did the request fail entirely (no response), or did it return a status code that isn’t 200-299? If either condition is true, route to the alert branch.

5. Telegram node (alert branch) — Sends a message formatted with the site URL, the status code (or “no response”), and the timestamp. My Telegram message looks like:

   🔴 Site alert
   URL: {{ $json.url }}
   Status: {{ $json.statusCode || 'No response' }}
   Time: {{ $now.toFormat('HH:mm, d MMM') }}

6. No-op node (success branch) — Does nothing. The workflow just continues to the next URL.

What to adapt: The URL list, the schedule, the notification destination. If you use Slack instead of Telegram, swap the Telegram node for a Slack node with the same message content. If you want to check every hour, change the cron expression.

One thing to get right: The “continue on error” setting on the HTTP Request node. Without it, the first unreachable site kills the workflow run and you don’t check the rest.

---