Website Uptime Monitoring with n8n

Most small business websites do not go down often. But when they do, the owner usually finds out the wrong way: a message from a customer saying the site is not loading, or a drop in bookings that only becomes obvious the next day.

A basic uptime monitoring workflow changes that. Instead of waiting for someone to notice, n8n checks your site on a schedule and sends a direct alert to the place you already look when something needs attention: Telegram, Slack, Google Chat, or email.

The workflow

The whole setup fits in four nodes:

Schedule Trigger (every 5 min)
-> HTTP Request (GET your site)
-> IF (status code not 200?)
  -> true: send alert
  -> false: do nothing, site is up

How each node is configured

Schedule Trigger: set to every five minutes. One failed check may be a transient network or proxy problem, so a production version should persist failure state and alert only after two consecutive failures. Send a separate recovery message after the first confirmed success.

HTTP Request: method GET, URL is the site homepage or a lightweight status endpoint. Set a Timeout of around 10 000 ms. If the server takes longer than 10 seconds to respond, it is effectively down for a real user. In Settings, enable Continue on Fail so a completely unreachable server does not stop the workflow before it reaches the IF node.

IF node: define success for the endpoint you chose. A homepage may redirect or return another valid 2xx response, while a dedicated health endpoint may require exactly 200 plus expected body text. Handle timeouts and connection errors explicitly because they may not contain a status code.

Telegram node: sends the alert message. n8n has native nodes for Telegram, Slack, and Google Chat. The channel matters less than whether the responsible person will actually see the message when it arrives.

The alert message

The message uses node name referencing to pull the status code from the HTTP Request result:

SITE DOWN ALERT

Site: yoursite.com
Status: {{ $('Check Site').item.json.statusCode ?? 'offline' }}
Time: {{ $now.toISO() }}

Checked by n8n monitoring workflow.

What to check when the alert fires

• Cloudflare dashboard first. Sometimes the origin is up but Cloudflare is returning a cached error or a 522. The dashboard shows recent errors and whether the issue is between Cloudflare and the origin.
• Open the site from a different network. Rules out a local DNS or ISP issue.
• Check the VPS or hosting control panel. A crashed process, full disk, or out-of-memory condition takes the site down without an application-level error.
• Check the n8n execution log. The HTTP Request output shows the exact status code and response body.

How to avoid noisy or misleading alerts

• Require two consecutive failures before opening an incident.
• Store whether an incident is already open so the workflow does not send the same alert every five minutes.
• Send one recovery message and clear the incident state after the endpoint passes again.
• Check expected content as well as status when a cached error page could still return 200.
• Run at least one independent external monitor for the n8n host itself.

Monitoring multiple sites

For several URLs, add a Loop Over Items node before the HTTP Request. Keep the URL list in a Code node or Google Sheets row, process each one at a time, and include the site URL in the alert message so you know which one triggered.

For two or three sites, duplicating the workflow per site is simpler and easier to debug than building a loop.