DEV Community: Stepan Nikonov

Website Uptime Monitoring with n8n

Stepan Nikonov — Mon, 06 Jul 2026 01:21:10 +0000

A 4-node workflow checks your website every 5 minutes and sends a Telegram, Slack, or Google Chat alert the moment it goes down, so you find out before a customer does.

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.

Trigger	Check	Alert
Every 5 minutes	HTTP GET + status code	Telegram (or Slack / Google Chat)

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

The false path connects to nothing. The workflow only acts when there is a problem. No alert means the check passed.

How each node is configured

The false path does nothing on purpose.

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.

The alert fires in Telegram when the site check fails. Same pattern works in Slack, Google Chat, or email.

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.

I originally published this on my site, FloxoLab, where I document practical automation and technical SEO for small business in the Philippines. If a workflow here is useful for your team, get in touch.

How to Debug Failed n8n Workflows: Step-by-Step Guide

Stepan Nikonov — Sun, 28 Jun 2026 20:41:45 +0000

A workflow failed. The execution log shows a red node, but the error message is not obvious. This guide covers where to look first, how to reload real data and rerun, and the five errors that cause most n8n failures.

Most n8n failures are not mysterious. They repeat the same patterns: a credential expired, an expression pointed to the wrong field, a webhook URL was the test one instead of the production one. The hard part is knowing where to start when all you see is a red node and a generic error message.

This guide walks through the tools n8n gives you for debugging, the five errors that cover most real-world failures, and two nodes that help you handle failures more intentionally going forward.

1. Start with Execution History

Every time a workflow runs, n8n records the execution: what data came in, what each node did, and where it stopped. This is the first place to go after a failure.

Open the workflow and select the Executions tab at the top. You will see a list of past runs with their status: Success, Failed, or Waiting. Select a failed one to open it.

Inside the execution view you can see the canvas in its failed state: the node that caused the failure is marked in red, and the bottom panel shows the error message and the log. This tells you which node broke and what the error was, before you touch anything.

The Executions tab shows past runs with their status. Open a failed execution to see which node broke, read the error message in the log panel, and find the Debug in editor button in the top right corner.

Read the error message before doing anything else. Many failures explain themselves: "401 Unauthorized", "Cannot read properties of undefined", "The provided authorization grant is invalid". The node name plus the error text is usually enough to know what went wrong.

2. Debug in Editor: reload real data and rerun

Once you understand what failed, use the Debug in editor button. This loads the actual input data from the failed execution into your current canvas. You can then make changes to the broken node and rerun the workflow using the same real data, without needing to trigger a new event.

After clicking Debug in editor, the canvas loads the data from the failed execution. Fix the broken node and rerun with the same real input. No need to trigger a new event.

This is especially useful for workflows triggered by external events: a form submission, a webhook call, or an email. Reproducing that exact input manually takes time. Debug in Editor gives you the original payload immediately.

For successful executions, the same panel offers Copy to editor instead. That is useful when you want to test changes against a known-good input rather than a failed one.

3. Retry a past execution

If you only need to run the failed execution again, you do not have to open the editor at all. n8n can rerun a past execution directly from the Executions tab, reusing the exact input data from the original run.

Hover over a failed execution in the list, or open it, and use the retry option. n8n gives you two choices:

Retry with original workflow: runs the execution again using the workflow exactly as it was when it first ran. Use this when the failure was temporary, like a rate limit or a service that was briefly down, and the workflow itself did not need changing.
Retry with currently saved workflow: runs the same input data through the latest saved version of the workflow. Use this after you have fixed the broken node, to confirm the fix against the data that originally failed.

Both options reuse the original trigger data from that execution, so you do not need to resend the webhook, resubmit the form, or wait for the next scheduled run. The retry appears as a new entry in the Executions list.

Retry is the fastest way to rerun an execution when you already know the cause. Debug in Editor is the better choice when you still need to inspect the data and change a node before running it again.

4. The 5 most common errors

These five patterns account for most of the failures you will actually see in production n8n workflows.

Credential or auth error (401, 403)

The node could not authenticate with the external service. Common causes: the credential expired, the API key was regenerated, OAuth tokens were revoked, or the connected account lost the required permissions.

Fix: open the node settings and re-test the credential. If it fails the test, reconnect or regenerate it in the credentials panel. For OAuth-based services like Gmail or Google Sheets, you may need to re-authorize from scratch.

A 403 is slightly different: the credential is valid but the account does not have permission to perform that specific action. Check the API scopes or the account's role in the connected service.

Expression error (undefined, wrong syntax)

An expression in a field is referencing a value that does not exist. The result shows [undefined] or the workflow throws a "Cannot read properties of undefined" error.

The expression editor shows [undefined] when the referenced field path does not exist in the input data. Open the left panel to inspect what fields are actually available.

Fix: click on the broken field to open the expression editor. On the left panel, expand the input data from the previous node and check the actual field names and structure. A common mistake is using {{ $json.name }} when the real field is nested: {{ $json.contact.name }}. Use the field browser to drag the correct path into the expression.

Webhook not firing (test URL vs production URL)

The workflow is active, the external service is configured, but no data arrives. This is almost always a test URL vs production URL mismatch.

n8n gives each webhook two URLs: one for testing (only works while the workflow is open in the editor), and one for production (only works when the workflow is active). If you configured your external service with the test URL and then activated the workflow, nothing will arrive because the test URL stops listening once you close the editor.

Both URLs are visible directly inside the Webhook node settings. Many people only notice the first one. The test URL is shown at the top; the production URL is listed below it. Copy the production URL and update it in the external service, then test by triggering the actual event from that service.

API timeout or rate limit (429)

The HTTP Request node or an API-connected node stops responding. You may see a 429 Too Many Requests error, or the execution simply times out.

n8n's default HTTP Request node timeout is 5 minutes (300,000 ms), but many workflows hit limits earlier because the external API enforces its own rate limits or because a slow response blocks the execution. A 429 means you are sending too many requests too fast.

Fix for rate limits: add a Wait node between batched requests to slow down the pace. Fix for timeouts: check whether the external API is responding at all (test it directly in a browser or with a manual HTTP call), then increase the timeout in the HTTP Request node settings if the service is just slow.

Data type mismatch (array vs object, null values)

A node expects a single object but receives an array, or a field contains null and the next expression tries to read a property from it. This often surfaces as "Cannot read properties of null" or unexpected behavior where only the first item is processed.

Fix: use the Input panel to inspect what the previous node actually returned. If it returned an array when you expected an object, add a Split Out node to break it into individual items before processing. If null values cause crashes, add an IF node upstream to filter them out before they reach the sensitive step.

5. Enable debug logging (self-hosted only)

If you run n8n on a self-hosted VPS and the execution log does not give enough detail, you can turn on verbose logging by setting N8N_LOG_LEVEL=debug in your .env file and restarting the container.

N8N_LOG_LEVEL=debug

With debug logging active, the server logs include detailed HTTP request and response data, credential resolution steps, and node input/output at each stage. This is useful for intermittent failures that are hard to reproduce by opening the editor: connection timeouts, credential handshake errors, and SSL issues tend to surface in the logs before they appear clearly in the execution view.

Reset after debugging. Debug output is verbose and will fill disk space quickly on a small VPS. Set N8N_LOG_LEVEL=info or remove the variable once you have found what you needed.

6. The Debug Helper node

Most n8n users do not know this node exists. The Debug Helper is a built-in utility node that lets you deliberately trigger different error types or generate random test data inside a workflow.

The Debug Helper node has four modes. Throw Error is useful for testing your error workflow before real failures happen in production.

The four modes are:

Do Nothing: passes through without doing anything. Useful as a placeholder.
Throw Error: deliberately fails the workflow with a message you specify. Use this to test your error handling before a real failure happens.
Out Of Memory: generates a large memory allocation to simulate an out-of-memory error. Useful for stress-testing self-hosted setups.
Generate Random Data: produces random structured data. Useful when you need test input but do not have a real event to trigger the workflow.

The most practical use of Debug Helper for most workflows: add it temporarily before your error-handling path and set it to Throw Error. This lets you verify that your Error Workflow actually fires and sends the alert before you see a real failure in production.

7. Stop And Error: controlled failures with clear messages

Sometimes a workflow should stop not because something broke unexpectedly, but because the data does not meet a condition you care about. An empty response from an API, a missing required field, a contact that should not be there. Without explicit handling, the workflow either completes silently or fails with a confusing message.

Stop and Error lets you define exactly when and why a workflow should fail, with a message that makes the cause clear in the execution log and in any error alerts.

The Stop And Error node ends the workflow at that point and marks the execution as failed, with the message you provide. Two error types are available: Error Message (a plain text string) or Error Object (a JSON object with structured error properties).

Used with an IF node upstream, this gives you intentional failure points. The workflow says "no valid email found, stopping here" instead of crashing three nodes later with a cryptic null reference. When that controlled failure triggers your error alert, the message is already readable.

Stop And Error can only be placed as the last node in a workflow branch. It is not a mid-flow control node.

Connect failures to alerts

Debugging after a failure is reactive. The better habit is knowing about failures before someone else does.

n8n's Error Trigger runs a separate workflow when any production workflow fails. That separate workflow sends an alert to Telegram, Slack, Google Chat, email, or wherever your team already pays attention. For small businesses in the Philippines and anywhere else running automated operations, this is the layer that turns silent failures into visible ones. The execution log gives you the workflow name, failed node, error message, and a link back to the execution.

The full setup, including what the alert should contain and how to point multiple workflows at a single shared error handler, is covered in the n8n error workflow and chat alerts guide.

n8n rerun and retry: common questions

How do I rerun a failed execution in n8n?

Open the Executions tab, hover over the failed run, and choose a retry option. Retry with original workflow reruns it exactly as it was; Retry with currently saved workflow runs the same input through your latest saved version. Both reuse the original trigger data, so you do not need to trigger the workflow again.

What is the difference between Retry with original workflow and Retry with currently saved workflow?

Retry with original workflow runs the execution using the workflow exactly as it was when it first ran, which suits temporary failures like rate limits or a service that was briefly down. Retry with currently saved workflow runs the same input through the latest saved version, which is what you want after fixing the broken node.

Does retrying an n8n execution reuse the original data?

Yes. Both retry options replay the original trigger and input data from the failed execution. You do not need to resend a webhook, resubmit a form, or wait for the next scheduled run.

Can I rerun an n8n workflow from a specific node?

Use Debug in editor to load the failed execution's data onto the canvas, then run a single node or the steps after it without retriggering the whole workflow. This is the better option when you need to change a node before running it again.

Self-hosted n8n Deployment with Docker, Cloudflare, and PostgreSQL

Stepan Nikonov — Mon, 22 Jun 2026 21:02:12 +0000

A private automation server setup for real workflows: domain, Cloudflare proxy, VPS, Docker, n8n, PostgreSQL, HTTPS, and basic hardening.

This setup gives n8n a private place to run real automations: a domain behind Cloudflare, a VPS running Docker, PostgreSQL for workflow data, HTTPS for the editor, and backups to Google Drive. It is the infrastructure layer behind form workflows, chatbots, API jobs, and internal tools.

Domain to Cloudflare to VPS to Docker to n8n.
Public traffic, containers, workflow logic, and storage are separated into clear layers so the automation workspace is easier to inspect, restart, and maintain.

Layer	Detail
Public layer	Domain, Cloudflare proxy, HTTPS
Runtime	VPS at about $7/mo, around PHP 430
Workflow layer	30+ workflows in the workspace

Why this setup

A default n8n install can be useful for testing, but a real automation workspace needs a little more structure. The goal here was to make the server usable for private workflows, webhooks, form automations, API jobs, and internal bots while keeping the public surface understandable.

Cloudflare sits in front of the domain, HTTPS is enforced in the browser, Docker keeps services isolated and restartable, and PostgreSQL gives n8n a proper database layer instead of treating the server as a disposable demo.

This setup runs on a VPS that costs about $7 per month, roughly PHP 430, which is enough for a focused workspace with dozens of small workflows.

Proof screenshots

Cloudflare DNS proxy is enabled so the public entry point is not a raw VPS port. IP values are hidden.

n8n and PostgreSQL run as Docker services with multi-day uptime. PostgreSQL was added later, so its uptime can be newer than other services.

A private n8n workspace with 30+ workflows across drafts, prototypes, and live automations.

HTTPS is active for the n8n domain. The admin path is hidden in the screenshot.

What was configured

Domain and proxy — Cloudflare DNS and proxy are used in front of the VPS, with sensitive origin details hidden from public screenshots.
Docker runtime — n8n and supporting services run as containers so the stack can be restarted, inspected, and extended without mixing every service directly into the host.
PostgreSQL — added as the database layer for n8n. The container is newer because it was introduced as a setup refinement.
HTTPS — the workflow UI loads over HTTPS, so operators are not using the admin surface over plain HTTP.
Basic hardening — small-business practical hardening: Cloudflare in front, HTTPS enforced, firewall rules for required access, and backups rather than an open default install.

This is not described as enterprise infrastructure. It is a practical self-hosted automation foundation for small workflows and internal tools, with the sensitive details removed from public screenshots.

Good fits

Owner-run operations — a small business that wants leads, forms, email drafts, and internal alerts running from one private n8n workspace instead of scattered one-off tools.
VA and service teams — a VA agency or ops team running several client intake workflows from one server, with separate workflows for forms, CRM updates, reports, and review queues.
Webhook-heavy tools — teams that need stable public endpoints for website forms, chatbots, payment events, WooCommerce actions, Airtable updates, or Google Workspace jobs.
Zapier-style migration — teams moving recurring automations into a private workflow engine where the logic is visible, documented, and easier to inspect before scaling further.

Backup and maintenance layer

The server and n8n setup already have backups going to Google Drive. That matters because a self-hosted automation server is not only about getting n8n online. It also needs a way to recover workflows, credentials, and service data if an update, server issue, or configuration mistake breaks something.

The maintenance plan is simple: keep restore steps, update notes, and basic monitoring close to the deployment so the setup is easier to maintain over time.

Related guide

Self-hosting changes the cost math against managed tools. For a side-by-side on what each option actually costs, read Zapier vs Make vs n8n Pricing: A Real Lead Form Example.

I originally published this on my site, FloxoLab, where I document practical automation and technical SEO for small business in the Philippines. If you already have a VPS and need n8n configured properly (domain, Cloudflare, Docker, HTTPS, PostgreSQL, backups, handover notes), get in touch.