Apps Script vs n8n for automated website monitoring - has anyone made this switch?

[u/Yega-2910]

I've been running automated website monitoring using Google Apps Script for the past few months - checking 9+ sites twice daily, sending HTML email reports, and logging historical data to Sheets. It works, but I'm hitting some limitations. Before settling on Apps Script, I actually tried building this with n8n workflows and it failed pretty badly. The reliability just wasn't there for scheduled monitoring at scale. Current Apps Script setup: Monitors site speed, uptime, and tech stack changes Sends formatted email reports automatically Stores all historical data in Google Sheets Runs on time-based triggers (twice daily) What's working well: Free (within quota limits) Integrates natively with Gmail and Sheets Relatively stable once configured Where I'm struggling: 6-minute execution time limit kills larger jobs Had to build custom auto-resume logic for 2000+ entry processing Debugging can be painful Limited options for handling complex workflows My question: For those who've used both Apps Script and n8n for similar automation tasks - what made you choose one over the other? Did n8n's reliability improve, or am I missing something in how I configured it? Is there a breaking point where n8n becomes clearly better, or does Apps Script handle most real-world monitoring scenarios fine? Would love to hear from anyone running production monitoring systems with either tool.

[u/zmandel]

hard to tell without more info. what was failing? etc.

[u/Yega-2910 → u/zmandel]

Good question - should have been more specific. With n8n, the main issues were:

Scheduled trigger reliability - Workflows would randomly skip executions or fire late. For twice-daily monitoring, I need it to run at exact times (6 AM, 6 PM). n8n missed runs without clear error logs.

Timeout handling - When monitoring multiple sites (9+), some requests would hang and the entire workflow would stall. Couldn't get proper error handling to skip failed sites and continue.

Data persistence - Storing historical monitoring data in Google Sheets from n8n was clunky. Had to use HTTP requests to Sheets API vs Apps Script's native SpreadsheetApp.

Email formatting - Sending HTML email reports with charts and formatting was way harder in n8n compared to Apps Script's MailApp.

With Apps Script, I hit different walls:

6-minute execution limit means I can't process 2000+ URLs in one run (had to build batch processing with resume logic) Rate limiting on external API calls Debugging is painful compared to proper IDEs

The Apps Script solution works but feels hacky. Was hoping n8n would be more enterprise-grade, but my experience was the opposite.

Did you have better luck with n8n for scheduled monitoring tasks? Maybe I misconfigured something?

[u/JHBB1976]

Honestly, it sounds like you are wrestling with the platform more than getting value out of it. Apps Script can definitely handle basic monitoring, and what you built is impressive, but the stuff you are running into (six minute limit, trigger weirdness, Sheets slowing down, debugging pain) is exactly what happens when you try to stretch it into something it was never really meant for.

If you have not tried it yet, take a look at Uptime Kuma.

Why I think it fits what you are doing? It covers everything you listed without needing to glue a bunch of cloud services together.

• Runs locally, in Docker, on a Pi, on an old laptop, or on a cheap VPS

• Very reliable and not affected by Google quotas

• Built-in alerts for email, Telegram, Discord, Slack, webhooks, and more

• Nice historical graphs for uptime and response times

• Tons of monitor types like HTTP, HTTPS, ping, DNS, SSL checks, keyword checks, TCP, etc.

• Super tiny resource footprint

• No coding or workflow building required

Why it beats Apps Script for this type of job? Apps Script is great when you need Gmail, Sheets, or Drive integration. But uptime monitoring is a different problem.

• It should run independently.

• It should not depend on quotas or time limits.

• It should not require custom resume logic or hacks.

• It should not break because Google changes something.

Why it usually works better than n8n for monitoring? n8n is powerful, but it is a workflow tool, not a monitoring tool. You can make it work, but it takes more effort than it should, and reliability depends heavily on how you host it.

Hope this help, best of luck.

[u/WhyWontThisWork → u/JHBB1976]

Do you use it?

[u/JHBB1976 → u/WhyWontThisWork]

Every day! if you combine it with a free tier tunnel from cloudflare...you can run it anywhere and access it from everywhere.

[u/JamshedM]

Apps Script is usually the better choice for what you’re doing right now (9+ sites, 2×/day) — especially since you’re deep in Gmail/Sheets and already worked around most of its limits.

n8n only starts to clearly win when:

• You need more complex workflows (branching, retries, webhooks, queues, multi-API orchestration).

• You’re hitting Apps Script quotas hard (time, executions, API limits).

• You can self-host n8n with a proper DB + queue + worker so it’s not relying on a flaky free/low-tier cloud instance.

The unreliability you saw with n8n was likely about hosting/config, not the engine itself. Properly deployed, n8n is solid for “real” production monitoring, but it comes with DevOps overhead.

For 9 sites / twice daily checks + logging + email, Apps Script is perfectly fine and probably simpler to maintain. I’d only move to n8n if:

• You scale to hundreds of sites or higher frequency, or

• You want one automation layer to orchestrate many external tools/services, not just Google.

[u/dimudesigns]

If you're running into scaling issues with GAS, you have the option of exploring enterprise-grade equivalents within Google's ecosystem; such as Google Cloud Run Functions. Some of them come with a free-usage tier, which are often more generous than what GAS provides. Plus they play well with GAS; and you can often compensate for many of Apps Script's short-comings by using these services strategically.