Uptime Monitor with Incident Escalation

This workflow is built from 17 nodes. Here's what each one does:

#	Node	Type	What it does
1	Every 5 Minutes	Schedule Trigger	Starts the workflow automatically on a schedule.
2	Site List	Set	Holds editable configuration values — fill in your own settings here before activating.
3	Expand Sites	Code	Runs custom JavaScript to transform, filter, or compute data between steps.
4	Check Site	HTTP Request	Calls an external API or webhook endpoint.
5	Site Down?	IF	Splits the flow into branches based on a condition.
6	Telegram Escalation	Telegram	Sends you a Telegram message or alert.
7	Slack Escalation	Slack	Posts messages or reads data in Slack.
8	Telegram Warning	Telegram	Sends you a Telegram message or alert.
9	Wait 60 Seconds	Wait	Pauses the workflow until a condition or time is met.
10	Recheck Site	HTTP Request	Calls an external API or webhook endpoint.
11	Still Down?	IF	Splits the flow into branches based on a condition.
12	Log Incident	Google Sheets	Reads from or writes to a Google Sheet — this workflow's log and state store.
13	Read Fail Count	Google Sheets	Reads from or writes to a Google Sheet — this workflow's log and state store.
14	Increment Counter	Set	Holds editable configuration values — fill in your own settings here before activating.
15	Update Fail Count	Google Sheets	Reads from or writes to a Google Sheet — this workflow's log and state store.
16	Escalate?	IF	Splits the flow into branches based on a condition.
17	Reset Fail Count	Google Sheets	Reads from or writes to a Google Sheet — this workflow's log and state store.

1. Add your credentials

In n8n go to Credentials → New, create each credential below, then open the named node and select it:

Node	Credential to add
Telegram Escalation	Telegram Bot API
Slack Escalation	Slack OAuth2
Telegram Warning	Telegram Bot API
Log Incident	Google Sheets OAuth2
Read Fail Count	Google Sheets OAuth2
Update Fail Count	Google Sheets OAuth2
Reset Fail Count	Google Sheets OAuth2

2. Fill in your config values

Open the config node listed below and replace each placeholder with your own value before activating the workflow:

Node	Field	What to paste
Telegram Escalation	chatId	PASTE_YOUR_CHAT_ID Your chat id
Telegram Warning	chatId	PASTE_YOUR_CHAT_ID Your chat id

How this workflow starts

• Schedule Trigger: Runs every 5 minutes.

Nobody watches their own website at 3 AM, which is exactly when it goes down. This template does the watching, and it does it with discipline: not every blip becomes a page. Every 5 minutes the schedule trigger starts a check cycle. Site List holds the sites as name and URL pairs, Expand Sites turns them into one item per site, and Check Site sends each an HTTP GET with a 10-second timeout. The never-error setting means a failure flows into the IF node instead of crashing the run. Site Down treats anything other than a 200 as down, and a failure never pages anyone immediately: Wait 60 Seconds pauses, Recheck Site fetches once more, and only a still-failing site moves forward. Then the counting starts. Log Incident appends the time, URL, and status to the Incidents sheet, and the Read Fail Count, Increment Counter, and Update Fail Count nodes maintain a consecutive-failure counter per site on the SiteStatus sheet. One or two consecutive failures send a Telegram-only warning, quiet by design. Three straight failures trip the Escalate check and fire the full alert to both Telegram and Slack. Any successful check hits Reset Fail Count and zeroes the counter, so only truly consecutive failures escalate. It is built for anyone whose money or reputation depends on a site staying up, which these days is nearly everyone.

The freelance developer watching twelve client WordPress sites

A freelancer maintains twelve client WordPress sites and used to learn about outages from angry client texts. Now the Site List holds all twelve name and URL pairs, edited once, and the Telegram warning arrives after the first confirmed recheck, usually minutes before the client notices anything.

• Variation: keep the 5-minute interval for client sites, but drop the escalation threshold in the Escalate node to 2 for the two clients with contractual uptime clauses.

The SaaS founder monitoring landing page, app, and API separately

A SaaS founder's status page says all systems operational while the API has been timing out for twenty minutes, because nobody monitors the parts separately. Three entries in Site List, the marketing site, the app, and the API health endpoint, fix that: the escalation names the exact failing URL, so the founder knows whether to call the frontend developer or the backend one.

• Variation: add the API's key endpoints as separate Site List entries rather than one homepage check, so a broken checkout API pages even when the marketing site is fine.

The agency proving uptime against client SLAs

A twelve-person agency promises 99.5 percent uptime in its maintenance contracts and used to dread the quarterly review where the client asks for proof. The Incidents sheet is now the proof: every confirmed incident logged with time, URL, and status, and the SiteStatus sheet showing the counters resetting on recovery. The Telegram warnings give the team a head start on fixing things before the client ever needs the SLA invoked.

• Variation: branch a monthly summary off the Incidents sheet, a scheduled read that counts incidents per site, and send it to the account manager as the raw numbers for the client report.

The affiliate blogger whose revenue dies with downtime

A blogger earning affiliate commissions from three review sites loses money every hour a site is down, and hosting support tickets take hours. The 5-minute check cycle means the blogger usually knows before the host's own status page admits anything, and the Telegram warning lands on the phone, not in an inbox checked twice a day.

• Variation: during a big product-launch week when traffic and revenue spike, temporarily tighten the check interval on the money pages and loosen it again after.

The ecommerce store through a sale weekend

A small fashion store does forty percent of its monthly revenue during a four-day sale, and last year the site went down for ninety minutes on day two while everyone was asleep. This year the escalation threshold drops to 2 for the sale weekend, so the second consecutive failure, not the third, fires the Telegram and Slack alerts to the founder and the developer on call. After the sale, the Incidents sheet shows exactly how many minutes of downtime occurred and when, which becomes the evidence for the hosting-credit claim.

• Variation: branch a PagerDuty or email node off Telegram Escalation for the sale period, so the alert survives a muted phone, then remove it when normal trading resumes.