Monitoring the uptime of your sites and APIs with n8n, no paid third-party tool

An online store returning a 500 error for forty minutes on a Sunday night, a third-party API that a critical workflow depends on silently timing out with nobody noticing until Monday morning: the cost of these incidents isn't just about how long the outage lasts, it's about how fast it's detected. A now-classic paper by David A. Patterson, A Simple Way to Estimate the Cost of Downtime (USENIX LISA 2002 — see on Google Scholar), lays out a simple method for pricing that cost from the unavailability rate and the hourly value of the affected activity — and it's a useful reminder that a minute of downtime caught in a minute objectively costs less than a minute of downtime caught an hour later. n8n lets you build, in a handful of nodes, an uptime monitor that does exactly this fast-detection job, without depending on a paid third-party service.

A different need from monitoring your own n8n instance

This guide isn't about the health of your n8n instance itself — that topic is covered in detail in our guide on monitoring a self-hosted n8n instance (the /healthz endpoint, Prometheus metrics, heartbeat). Here, n8n plays a different role: it's the monitoring tool, not the target being watched. This is a common need for an agency managing several client sites, a freelancer who wants to know before their clients that a service is down, or a team whose own workflows depend on a third-party API (payments, shipping, CRM) whose availability matters to them directly.

The base workflow: a scheduled ping and a status check

The scheduled trigger

A Schedule Trigger set to Interval mode, firing every one to five minutes depending on how critical the monitored site is, is enough to kick off the pipeline. There's no need to go below a minute: past a certain frequency you risk getting rate-limited by the target site, and the gain in reaction time becomes marginal.

The HTTP Request node

An HTTP Request node using GET (or HEAD, lighter, if the target site handles it correctly) queries the monitored URL with:

• a short timeout (5 to 10 seconds) — a site that takes 15 seconds to respond is, in practice, down for most of its visitors;
• Continue On Fail enabled, so the workflow keeps running even when the request fails (timeout, DNS, connection refused), instead of stopping and doing nothing;
• the response time captured, available in the node's execution metadata, worth keeping for the history.

An IF node then evaluates two conditions: is the returned HTTP status code within the expected range (200-299, or a wider range if the site legitimately returns 3xx), and does the response body contain an expected text fragment — a title, a tag, a word from the footer. That second check catches application-level failures that still return a 200, for instance a generic error page served by an upstream CDN.

Avoiding false alarms: confirm before escalating

A site that fails once out of a thousand checks because of a passing network latency blip isn't an outage. Escalating on the very first failure quickly produces alerts nobody takes seriously anymore — the same fatigue mechanism documented for application-monitoring alerts. The fix is simple: instead of alerting straight from the IF node, increment a consecutive-failure counter in a Supabase table (one row per monitored site, with a consecutive_failures field and a status field). Only escalate to an alert once that counter hits a threshold (two or three consecutive failures, depending on check frequency), and reset it to zero the moment a check succeeds.

This philosophy — verifying a system's actual resilience rather than trusting a single instantaneous signal — echoes the foundational chaos engineering work at Netflix: Basiri, Behnam, de Rooij, Hochstein, Kosewski, Reynolds, and Rosenthal, Chaos Engineering (IEEE Software, 2016 — see on Google Scholar), stress the importance of telling a transient, consequence-free signal apart from a genuine system degradation before reacting. A consecutive-failure counter applies that same principle at the scale of a simple monitoring pipeline.

Alerting without spamming: incident and recovery

The table's status field (say, up or down) acts as state memory between two workflow runs, which lets you send exactly one message per transition:

• up → down (once confirmed by the failure threshold): an alert message to Slack or Telegram, with the affected URL, the status code or error encountered, and the time of first detection;
• down → up: a recovery message, with the total incident duration computed from the timestamp stored when the site flipped to down.

Without this transition logic, every failed check would send an identical message every minute for the whole duration of the outage — exactly the kind of noise that trains a team to ignore the alert channel. For the most critical incidents, sending in parallel by SMS via the pattern described for Twilio alerts guarantees the message gets through even if nobody's watching Slack on a Sunday night.

Logging to Supabase: availability and mean time to recovery

Every run, successful or not, deserves a row in an availability_checks table (site, timestamp, HTTP status, response time, success boolean). This history lets you compute, with a simple SQL query:

• the availability rate over 30 days (share of successful checks);
• the average response time and its drift over time — a site that's gradually slowing down is often the early warning sign of a more serious incident;
• the MTTR (mean time to recovery), by cross-referencing the timestamps of down → up transitions.

This is exactly the kind of audit trail already covered by the Compliance & Audit Pack (149 €), whose append-only Supabase table and AI-generated summary reports adapt with little effort to an uptime-tracking use case instead of a regulatory-compliance one.

Bonus: also watch for SSL certificate expiry

An SSL certificate expiring on a Saturday morning cuts off access to a site just as surely as a server outage — and it's an entirely predictable incident. A Code node called once a day (not on every ping) can check the certificate's expiry date via a TLS request and fire an alert as soon as the deadline drops under 14 days, leaving plenty of time to renew before the cutoff.

Limits worth knowing

This pipeline entirely depends on your own n8n instance being available: if it's down at the same time as the monitored site, or before it, no alert goes out. For genuinely critical stakes, always keep an independent external probe as a complement — the n8n instance monitoring guide explains how to secure that link with a heartbeat to a free third-party service. A dedicated Error Workflow on this monitoring pipeline itself is also worth setting up: the workflow that warns you about outages shouldn't be the one that fails silently.

Going further

This pipeline is built entirely with nodes already available in n8n, with no external dependency beyond Slack or Telegram for the alert. If you're looking for a set of n8n workflows already built with this level of rigor — append-only Supabase logging, structured alerts, built-in error handling — the Compliance & Audit Pack (149 €) and, for the site's full range of use cases, the Complete FlowKit Bundle (269 €) save you from starting from scratch.