How to Build an n8n Log Alerting Workflow (No Grafana Required)

Most n8n Error Setups Tell You Everything, Which Means They Tell You Nothing

An n8n log alerting workflow has one job: surface the failures that need a human and quietly file the ones that don't. The common approaches miss in opposite directions. The official docs teach the Error Trigger in isolation, so you get a raw error dumped into a channel. The infrastructure tutorials push a full ELK or Grafana stack, which is a lot of YAML to learn that a workflow broke.

There's a lighter pattern in between. Catch the error, let an OpenAI node judge how bad it is, route only the actionable ones, and log the rest for later. No new infrastructure, no dashboards nobody opens.

n8n already has the hard part built in. The Error Trigger fires on any failed execution. What's missing from the ranking pages is the triage layer that decides what to do with it.

What You Can Automate in Log Alerting

A useful alerting layer does more than forward an error string:

• Centralized error capture: one Error Trigger workflow receives failures from every other workflow
• Severity classification: an AI node maps each error to critical, warning, or info
• Selective routing: only actionable failures reach a human; the rest get logged
• Remediation hints: attach a likely-cause note and a runbook link to critical alerts
• Noise suppression: collapse repeated identical errors instead of paging on each one
• Audit logging: append every error to Google Sheets for weekly review
• Escalation: page a second channel if a critical error isn't acknowledged

The Log Alerting Pipeline

Error Trigger (catches any failed workflow)
  → Code (extract workflow name, node, message, timestamp)
  → OpenAI (classify severity → critical | warning | info + one-line cause)
  → Switch (severity)
      → critical: Slack #incidents (+ email on-call) + Google Sheets
      → warning:  Slack #ops-noise + Google Sheets
      → info:     Google Sheets only
  → (optional) IF (no ack in N min) → escalate

1. Catch errors in one place

Build a single workflow whose trigger is the Error Trigger node, then set it as the error workflow in each other workflow's settings. Now every failure across your instance lands in one handler. You write the routing logic once instead of bolting an alert onto every workflow.

The Error Trigger gives you {{ $json.execution.error.message }}, the failing node, and the source workflow. A short Code node flattens these into a clean object for classification.

2. Classify severity with the model

A keyword rule works for errors you've seen before. The problem is the ones you haven't. An OpenAI node handles both:

You are an SRE triaging an automation failure. Given the workflow name,
the failing node, and the error message, return JSON:
{ "severity": "critical|warning|info", "cause": "one short line" }

critical = data loss, customer-facing breakage, or a payment/auth failure
warning  = a retryable or transient failure, degraded but not down
info     = expected/handled errors, validation rejects, empty inputs
Return ONLY the JSON.

Always add a Code node after the OpenAI call to parse the JSON. The model returns text; the Switch node expects a field. Skip the parse and the routing silently reads undefined and dumps everything into one branch. This is the most common way these workflows quietly break.

3. Route only what's actionable

A Switch node on severity does the real work. Critical pages a human and logs. Warning posts to a low-traffic channel and logs. Info just logs. The discipline here is resisting the urge to send info-level events to Slack "just in case." That's exactly how the channel becomes noise nobody reads.

4. Suppress duplicate noise

A workflow stuck in a retry loop can throw the same error dozens of times. Hash the workflow name plus the error message, check a recent-errors list, and collapse repeats into a single alert with a count. The on-call engineer wants to know "this broke 40 times in five minutes," not see 40 messages.

5. Log everything, alert on little

Every error, all three severities, gets a Google Sheets row. That log is your weekly review: which workflows fail most, which errors recur, what's worth fixing properly. The alerts are for right now; the log is for the pattern.

Implementation Patterns

Pattern 1 — One shared error workflow. Don't bolt alerting onto each workflow. Point them all at one Error Trigger handler. The AI Ops Guard for No-Code Agents template is built around exactly this: a central classify-and-route handler you reference from every workflow's settings.

[any workflow fails] → Error Trigger handler → classify → route

Pattern 2 — Parse the model output, every time. The OpenAI node returns a string. Add a Code node to parse it into structured fields before the Switch. Treat this as non-negotiable, even when it feels redundant.

OpenAI (returns text) → Code (JSON.parse → severity, cause) → Switch

Pattern 3 — Collapse, don't flood. Group repeated identical errors and send one alert with a count. A loop throwing the same exception shouldn't generate a message per iteration.

n8n Nodes You'll Use Most

Getting Started

1. Create a new workflow with an Error Trigger node.
2. In your other workflows' settings, set this one as the error workflow.
3. Add a Code node to flatten the error into a clean object.
4. Add an OpenAI node with the severity rubric, then a Code node to parse its JSON.
5. Add a Switch on severity routing to Slack, Gmail, and Google Sheets.
6. Add the dedupe check so retry loops don't flood the channel.
7. Test by throwing an error on purpose, then start from a template instead of wiring the triage from scratch.

This pairs naturally with deploy-time alerting; the capture pattern in automating DevOps workflows with n8n covers the webhook side. If those LLM calls are also where your spend hides, the AI Agent Spend Tracker template logs cost per workflow alongside the errors. And because the classifier leans on an LLM, the output-parsing advice in n8n OpenAI workflows is worth reading before you ship.