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
No alert means the site responded with 200. The workflow stays quiet until something actually breaks.
Schedule Trigger: set to every 5 minutes. That gives a maximum 5-minute window before an alert fires. A 1-minute interval would generate noise from transient blips that recover on their own.
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: condition checks whether statusCode is not equal to 200. True path triggers the alert. False path is left unconnected.
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.
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.
This workflow handles HTTP-level availability. It complements, but does not replace, n8n Error Workflow alerts, which protect your automations from failing silently. One watches the infrastructure, the other watches the workflows running on top of it.
n8n referral
Want to run this on n8n Cloud?
I may earn a commission if you sign up through this link, at no extra cost to you.
Know when your site goes down — not an hour later.
Send your site URL and the channel your team already uses. I will map the smallest monitoring setup that makes sense for your stack.
Get the map