Hey all,
Describe the problem/error/question
We have ~206 per-project Asana webhooks registered in n8n (portfolio-level webhooks aren’t supported due to Asana’s filter restrictions on larger-scoped resources). Asana sends periodic heartbeat pings to every registered webhook to verify the endpoint is alive — even when no data has changed. With 206 webhooks, this generates a large number of no-op executions that fill up execution history and make it difficult to identify real workflow runs.
Our Filter node correctly discards heartbeats by checking events.length > 0, so the workflow logic isn’t affected. But the executions still get created and stored in the DB.
Has anyone found a clean way to suppress heartbeat executions from being stored, or used a different webhook architecture to avoid this problem entirely?
What is the error message (if any)?
No error — executions complete successfully with status success. The issue is volume, not failure.
Please share your workflow (can’t share the actual nodes)
Webhook node (path: abc-sync responseMode: responseNode)
→ Respond to Webhook (echoes X-Hook-Secret for Asana handshake)
→ Filter (AND: events.length > 0 AND relevant field/GID check)
→ Set: capture trigger source + project GID
→ Get portfolio items → Loop → sync logic
Heartbeat payload from Asana:
```json
{ "events": [] }
```
Real event payload has `events[0].change.field = due_on` or `custom_fields`.
Share the output returned by the last node
Heartbeat executions complete in 10-20ms, status success, mode webhook. Roughly 206 heartbeats per cycle = thousands of execution records per day accumulating in Postgres.
Information on your n8n setup
- n8n version: 2.0.0
- Database (default: SQLite): Postgres (pg16)
- n8n EXECUTIONS_PROCESS setting (default: own, main): default (main)
- Running n8n via (Docker, npm, n8n cloud, desktop app): Docker (self-hosted on Azure)
- Operating system: Ubuntu (Azure VM)
- No execution pruning configured yet (EXECUTIONS_DATA_PRUNE not set)
Hi @Nikita_Kohli
The problem is that n8n creates a database record the moment a webhook is triggered, even if your filter immediately stops the workflow. Because Asana sends frequent “heartbeat” pings to check if your system is alive, you are generating thousands of useless success records that clutter your history and bloat your Postgres database.
The best way to fix this within n8n is to use a “Router and Processor” setup. You create one simple workflow that acts as a gatekeeper; it receives the webhook, filters out the heartbeats, and then triggers a second workflow for real data. By setting the gatekeeper workflow to “not save successful executions,” the heartbeats vanish from your history, while the second workflow keeps a clean record of only the actual syncs.
If you want to save even more system resources, you can use an external proxy like Hookdeck or a small piece of custom code in front of n8n. This acts as a shield that inspects the Asana payload and drops the heartbeat pings before they ever reach your n8n server. This prevents n8n from having to process the request at all, reducing CPU and memory usage.
Finally, you should enable automatic database pruning in your Docker settings. Currently, your system is keeping every single execution record forever, which will eventually slow down your database or run out of disk space. Setting a retention limit (such as 7 or 14 days) ensures that old data is deleted automatically, keeping your Azure VM healthy and fast.
Welcome @Nikita_Kohli!
To actually configure the “don’t save” part that @kjooleng mentioned: open the gatekeeper workflow, click the three dots (workflow settings) in the top-right, then under “Execution Data” set “Save Successful Executions” to “Never”. That workflow-level setting means heartbeat runs vanish immediately and never touch your execution history table, while your processor workflow keeps its own save settings intact.
Also worth noting: you can set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none at the instance level as a fallback, but the per-workflow setting is cleaner since you only want to suppress the gatekeeper, not everything.
The root of it, as the reply above points at, is that n8n writes an execution record the moment the webhook fires, before your filter decides there is nothing to do, so Asana’s heartbeats each leave a stored no-op run and 206 webhooks turn that into thousands of useless records bloating Postgres.
Two levers. First, turn off saving for successful executions on these specific workflows: in the workflow settings set “Save successful production executions” to off (or “Do not save” for success), so the heartbeat no-ops stop being written while genuine errors still get saved. That kills the storage bloat without losing the runs that matter. Second, if you can detect a heartbeat versus a real change at the very first node, respond 200 and stop early, but note the record is already created by then, so setting one matters more for storage.
Longer term, a periodic prune (the execution data pruning settings, EXECUTIONS_DATA_PRUNE and max age) keeps the table from growing unbounded regardless. For 206 webhooks I would do both: stop saving success on those flows, and set a prune age so anything that does slip in ages out. What is your current EXECUTIONS_DATA_PRUNE setting, if any?
Thank you all so much! This thread was incredibly helpful!
The Router + Processor pattern suggested worked perfectly for my setup. The key was setting the Gatekeeper’s “Save Successful Executions” to Never. I also added EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE to docker-compose as a long-term safeguard.