n8n disk full: how one Gmail trigger wrote 36 GB of duplicate attachments

Rimas Lukaszewicz · 25 August 2026 · incident response, n8n, automation

A client’s self-hosted n8n went down twice in six days. The disk was 96 GB, 100% full, and 36 GB of it was the same email attachments, written to disk thousands of times by a single misconfigured Gmail trigger. The credentials the client thought were deleted had never been touched. The fix took three steps: disable attachment download on the trigger, clean the temp files manually, restart n8n.

If you self-host n8n, the failure pattern below is worth checking for this week. It produces no errors until the disk is completely full, and n8n’s own data retention settings cannot prevent it.

Key takeaways

A Gmail trigger with download attachments enabled writes files to disk on every poll, even when no workflow node ever uses them.
Those files land in a temp directory that n8n’s execution data pruning does not clean. Retention settings cap history, not trigger output.
A full disk can make n8n’s UI report missing credentials while the backend keeps executing with those exact credentials. Nothing is deleted; restart n8n after freeing space.
Freeing disk space without removing the cause buys days, not a fix. This estate refilled and failed again five days later.

The symptom: “all my credentials are gone”

The client reported that his automations were failing with “no space” errors and that every saved credential had disappeared from the n8n interface. Credential pickers were empty and the credentials tab loaded forever.

That is two problems in one report, and only one of them was real. The disk was full. The credentials were fine.

Diagnosing the server with Claude Code over read-only SSH

I connected to the VPS hosting n8n with a read-only SSH user and pointed Claude Code at the symptoms. It checked RAM, CPU and disk, reported the volume at 100%, and when asked what was filling it, narrowed the growth down to files written by workflows sharing one specific trigger.

The execution data everyone worries about was 0.2 GB. The trigger’s temp output was 36 GB.

Root cause 1: a Gmail trigger downloading the same attachments forever

The original builder of the automations had enabled download attachments on a Gmail trigger. Nothing downstream ever consumed those attachments, but the setting does its work at poll time, before any workflow logic runs. Every poll, once per minute, the trigger fetched the matching messages and wrote their attachments to disk again.

The same trigger configuration was copied across multiple workflows, which multiplied the effect. The same emails, with the same attachments, were downloaded thousands and thousands of times, around the clock, into a shared temp path.

Why n8n data retention could not fix this

The obvious recommendation is to turn on execution data pruning and let n8n clean up after itself. It would not have helped here, and knowing why matters:

Pruning works on execution data, the per-run records n8n stores after a workflow executes.
The attachment files were written by the trigger itself, before any execution existed, into a temp directory that pruning never targets.
Retention therefore caps your history. It does nothing about data a trigger generates at poll time.

Retention is still worth configuring as hygiene. It is not a fix for this class of problem. The temp files had to be deleted manually, and the trigger setting turned off at the source.

Root cause 2: why the credentials looked deleted

The credentials were on disk the whole time. With zero bytes free, n8n could not load them into its runtime state, so the UI showed empty pickers while the backend kept executing scheduled workflows with those same credentials. After the disk was cleaned, a restart reloaded everything and the interface returned to normal.

The rule that came out of it: after any out-of-space event on n8n, restart the container once space is free. Freeing disk space alone does not repair state that failed to load while the disk was full.

The second outage, five days later

The first response cleaned the disk and stopped the immediate errors. It did not remove the cause, because the first pass did not dig deep enough into why the disk was filling. Five days later it was full again, on schedule.

The second pass fixed it properly. Before touching the trigger, I reviewed every workflow using the Gmail trigger with Claude Code to confirm that no business logic consumed the attachments, so disabling the download could not break anything. Then the setting went off, the temp files were removed, and the change was tested end to end. The disk has stayed at 51% since.

Cleaning without fixing the cause bought exactly five days at the observed fill rate.

How to prevent this in your own n8n instance

Check host utilization now. If you self-host, look at disk, RAM and CPU on the machine running n8n before anything forces you to.
Audit trigger settings, not just workflows. Any polling trigger with attachment or binary download enabled should have a consumer. If nothing uses the data, turn the setting off.
Configure execution data pruning, and understand its limits: it will not clean trigger temp output.
After any out-of-space event, restart n8n once space is free, and treat “missing” credentials as a load failure until proven otherwise.
Add monitoring and prioritize your workflows. Decide which automations are business-critical and make sure someone, or something, notices when they stop.

FAQ

Does n8n data retention clean the temp directory? No. Execution data pruning removes per-execution records. Files written by triggers at poll time, such as downloaded email attachments, sit outside its reach and accumulate until removed manually or by a scheduled job you build yourself.

Why did n8n show empty credentials when nothing was deleted? The disk was full, so n8n could not load credential data into its runtime state. The backend, which already held them in memory, kept executing workflows normally. A restart after freeing space restored the UI.

Is it safe to disable attachment download on a Gmail trigger? Only after confirming nothing downstream consumes the attachments. In this incident, every workflow using the trigger was reviewed first to verify the business logic would survive the change.

Rimas Lukaszewicz is Head of Engineering and writes The AI Logic, a weekly newsletter on AI and automation for engineering leaders. The newsletter version of this story, told in first person, is issue #25. The audit that preceded this incident is issue #21. Not sure where AI fits in your business? Find your starting point in 3 minutes.