Automate Error Logging and Alert Limits with n8n & Postgres

Opening Problem Statement

Meet Davi, a developer managing multiple automation workflows for his clients. One day, a scheduled task in his system starts failing repeatedly, triggering dozens of errors within minutes. Suddenly, Davi’s inbox floods with alert emails—hundreds over a short period—overwhelming his ability to respond effectively.

This flood of error notifications wastes valuable time filtering through duplicates and causes important issues to be missed amid the noise. Meanwhile, each error occurrence is still silently logged in the system. How can Davi automate error logging effectively and avoid sending excessive emails that overwhelm his support process?

What This Automation Does

This n8n workflow elegantly solves Davi’s problem by combining real-time error capturing with smart alert throttling. When an error occurs anywhere in your automation environment connected to n8n, here’s what happens:

• Error Trigger: The workflow instantly captures the error event as it happens.
• Insert Log: It records detailed error information—including stack trace, last failed node, error message, and URL—into a dedicated Postgres database table for permanent error tracking.
• Count for 5 minutes: It checks how many errors have been logged in the past 5 minutes.
• If condition: Determines if an alert should be sent, limiting notifications to one email every 5 minutes to prevent flooding your inbox.
• Error Handling Logic Placeholder: You can add your custom alert or recovery actions here, such as email sending or push notifications.
• Cleanup: Optionally, you can clear logs from the database, useful especially in development/testing environments to avoid database clutter.

This precise control means you never miss an error while avoiding repeated alerts during surges—a perfect balance for managing error notifications efficiently.

Prerequisites ⚙️

• n8n Automation Platform (self-hosted or cloud)
• Postgres database with access configured for n8n to store error logs
• Credentials for Postgres in n8n to execute queries (insert, count, delete)
• Optional: SMTP email accounts if you want to enable the email alert nodes in this workflow 📧
• Optional: Pushover account for mobile push notifications 💬

Step-by-Step Guide to Set Up This Workflow

Step 1: Create the Error Log Table in Postgres

Use this DDL (Data Definition Language) SQL script to create the error logging table required by the workflow:

create table p1gq6ljdsam3x1m."N8Err"
(
    id         serial primary key,
    created_at timestamp,
    updated_at timestamp,
    created_by varchar,
    updated_by varchar,
    nc_order   numeric,
    title      text,
    "URL"      text,
    "Stack"    text,
    json       json,
    "Message"  text,
    "LastNode" text
);

create index "N8Err_order_idx" on p1gq6ljdsam3x1m."N8Err" (nc_order);

You can run this script in your Postgres client. Adjust the schema name p1gq6ljdsam3x1m if needed.

Step 2: Import or Create the Workflow in n8n

In n8n, go to Workflows > Create New Workflow. Import the workflow JSON or create new nodes to mirror the following key nodes:

• Error Trigger: Node type errorTrigger, this is the starting point capturing errors.
• Insert Log (Postgres): Inserts error details into your Postgres table.
• Count for 5 minutes (Postgres): Counts logged errors in the last 5 minutes.
• If node: Decides whether to proceed with alerting or not.
• Cleanup nodes: For deleting logs or resetting execution state.

Ensure the Postgres nodes have proper credential connections to your database.

Step 3: Connect the Error Trigger to Log Insertion

Link the Error Trigger node’s main output to the Insert Log node. This setup makes sure every caught error is logged immediately.

Test this by manually triggering an error or executing a workflow expected to fail, then check that a new record appears in your Postgres “N8Err” table.

Step 4: Count Recent Errors Using the Postgres Node

The Count for 5 minutes node uses this SQL query:

SELECT count(*) FROM p1gq6ljdsam3x1m."N8Err" where created_at >= $1;

The parameter $1 is dynamically replaced with the timestamp 5 minutes ago using n8n’s expression syntax:
= {{$now.minus(5, 'minutes').toString()}}

This node outputs the number of errors logged in that interval.

Step 5: Use If Node to Control Alert Frequency

Configure the If Node to check if the count is less than or equal to zero.
Meaning: There have been no alerts sent in the last 5 minutes, so now is a good time to alert.

If the condition is true, proceed with your alert logic. If false, skip it to avoid flooding.

Step 6: Add Your Custom Error Handling Logic

The example workflow shows placeholder nodes where you can place your email or push notification nodes.

• Principal E-Mail Node (disabled by default): Sends error email to a configured address using SMTP credentials.
• Fallback E-Mail Node (disabled): Backup email sender in case the primary fails.
• Push Mobile Notification (disabled): Sends alerts via Pushover API.

Enable and configure these nodes with your SMTP and Pushover credentials if you want live alerts.

Step 7: Set Up Cleanup Option for Development

The workflow includes a manual trigger node called Sometimes… just cleanup. This is used to trigger the Truncate Log Database node.

This node safely deletes all records in your error logs, useful in development to keep the database clean but DO NOT use in production.

Step 8: Test the Workflow End to End

Trigger an error in any workflow that routes through this error handler.
Then check your Postgres table for inserted logs, verify the count logic, and confirm no excessive emails are sent.

Customizations ✏️

• Change Error Log Retention: Adjust the Count for 5 minutes SQL query to count errors over a different time window, e.g., 10 or 15 minutes.
• Enable Email Alerts: In the Principal E-Mail and Fallback E-Mail nodes, configure your SMTP credentials and turn them on to receive error emails.
• Add More Alert Channels: Include Slack or other communication nodes after the If Node to diversify notifications.
• Custom Cleanup Schedule: Add a Cron node to trigger Truncate Log Database regularly with a safe schedule.
• Log Additional Error Context: Modify the Insert Log Postgres node to include any other JSON data relevant to your application errors.

Troubleshooting 🔧

• Problem: “Postgres node error: connection refused”

  Cause: Incorrect database credentials or Postgres service down.

  Solution: Verify your credentials in n8n > Credentials > Postgres. Ensure your Postgres server is accessible and not blocking connections.

• Problem: “No error logs appear after triggering errors”

  Cause: The Error Trigger node isn’t firing or the Insert Log node misconfigured.

  Solution: Confirm an error occurs and the workflow is active. Check that the Insert Log Postgres node’s table/schema names are exact matches in your database.

• Problem: “Emails are sent too frequently despite the limit”

  Cause: The If node condition is not properly evaluating counts.

  Solution: Debug the output of the Count node, ensure the expression is correctly referencing $json.count and the conditional logic is set to <= 0.

Pre-Production Checklist ✅

• Verify your Postgres table is created as per the DDL script.
• Confirm n8n has correct credentials and access permissions to your Postgres database.
• Test error triggering by forcing an error in a sample workflow.
• Run the Count for 5 minutes query manually in Postgres to verify it returns expected results.
• If using email nodes, verify SMTP credentials and test sending emails in n8n credentials settings.
• Backup existing error log data before enabling cleanup in production environments.

Deployment Guide

Activate your workflow by enabling it in n8n’s editor after configuring all credentials. The workflow runs automatically whenever an error event triggers it.

Monitor the Postgres table regularly to track logged errors and review if the alert rate-limiting is working as intended.

Consider integrating this workflow as a sub-workflow in your broader error handling system for modularity and reuse.

FAQs

• Q: Can I use MySQL instead of Postgres?
  A: This exact workflow uses Postgres-specific SQL syntax and functionality. You would need to adapt queries and node configurations to MySQL.
• Q: Does this workflow consume many API credits?
  A: It mainly uses your Postgres database and n8n internal triggers, so no significant third-party API consumption occurs.
• Q: Is my error data safe?
  A: Your error logs are stored in your own Postgres database, so data security depends on your database’s security controls.
• Q: Will alert throttling work under high error volumes?
  A: Yes, the count-based conditional limits alerts robustly. However, extremely high volumes might require further optimization.

Conclusion

By deploying this n8n workflow, you gain a robust error logging solution that captures every failure while smartly limiting notification overload. This reduces wasted time filtering duplicate alerts and helps your team focus on resolving real issues faster.

Davi now spends less time overwhelmed by emails and more time improving his automations. You can extend this foundation with additional notification channels, scheduled cleanup, or integrate it into larger monitoring setups.

Try implementing this specific error logging and alert throttling workflow today for a cleaner, more manageable error handling process in n8n!