Website Uptime Monitoring with n8n

This build shows a scheduled website check and a private alert path. The separate local lab below reproduces outage confirmation, one recovery event, and repeat-alert suppression after restarting with persisted state.

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.

Reproduce an outage and recovery locally

Measured local result: nine real loopback HTTP probes produce one down event and one recovery event. The test covers 200, 500, timeout, a redirect that is not followed, repeated failures, and a fresh Node process reloading persisted state. It was run on October 8, 2026; it does not describe an outage of floxolab.com.

Download the uptime transition lab v1.0.0 (ZIP). Run node run.mjs with Node.js 22 or later. The kit starts its own local HTTP fixture server and uses a local sink instead of Telegram or Slack.

200 → healthy, no alert
500 → first failure, no alert
timeout → second failure, one down event
500 → continued outage, no repeat event
new process + saved state + 500 → no repeat event
200 → one recovery event
200 → no repeat recovery

State and delivery boundary: two consecutive failures confirm the outage in this reference policy. Only 2xx is healthy; redirects are not followed. A single-process state file is atomically replaced before the sink records an event. That order suppresses repeat alerts after a restart, but a crash between saving state and delivering the alert could lose a notification. A live system needs an acknowledged outbox or another tested delivery design.

The measured scope is local HTTP probing, a real timeout, persisted state, and restart suppression. No n8n execution, external uptime, TLS behavior, scheduler, Telegram delivery, concurrent writers, or incident response is tested by this kit. The existing screenshots show a separate four-node demo; its direct-alert path does not automatically inherit the lab’s stateful policy.

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.