Debounce

Single execution after delay

Overview

This node implements a debounce mechanism to ensure that only a single execution occurs after a specified delay, even if multiple triggers happen in quick succession. It is useful in scenarios where you want to avoid repeated processing of the same event within a short time frame, such as:

Preventing duplicate API calls when a user rapidly triggers an action.
Throttling events from sensors or webhooks to reduce load.
Ensuring that batch processing happens once after a burst of incoming data.

The node supports two database backends (Redis and Postgres) to store context about the debounce state, allowing it to track whether an execution should proceed or be skipped ("killed").

Practical example:

If you have a webhook that fires multiple times within seconds, you can use this node to wait for a quiet period (e.g., 5 seconds) before actually processing the data, ensuring only one workflow run per burst of events.

Properties

Name	Meaning
Database Type	The type of database used to store debounce context. Options: `Redis`, `Postgres`.
Table	(Postgres only) The name of the table used to store debounce keys and counters.
Key	A unique key string to identify the debounce context.
Wait Amount	The amount of time in seconds to wait before allowing execution to proceed.

Output

The node has two outputs:

Debounced (main output 1)
Contains the input data passed through if the debounce condition allows execution (i.e., no other executions happened during the wait time).
Killed (main output 2)
Contains the input data if the debounce condition was not met (i.e., another execution occurred during the wait time), effectively "killing" this execution.

The output JSON structure matches the input data structure, simply routed to one of the two outputs depending on debounce logic.

No binary data output is involved.

Dependencies

Requires either a Redis or Postgres database connection to store debounce state.
Corresponding credentials must be configured in n8n for Redis or Postgres.
For Redis, uses the redis npm package client.
For Postgres, uses the pg npm package client.
The Postgres connection disables SSL certificate verification (rejectUnauthorized: false).
The node listens for process termination signals to cleanly close Redis connections.

Troubleshooting

Connection errors:
Ensure Redis or Postgres credentials are correctly set up and the database is reachable from the n8n instance.
Table does not exist (Postgres):
The node expects the specified table to exist with at least columns key (string) and incr (integer). Create the table manually if missing.
Key collisions:
Use unique keys per debounce context to avoid interference between different debounce operations.
Unexpected behavior with concurrency:
If multiple workflows use the same key simultaneously, some executions may be killed as expected by debounce logic.
Error messages related to Redis or Postgres clients:
Check network connectivity, credentials, and database server status.