n8n Scheduled Data Export: Cron, CSV, and Auto-Cleanup

Exports are the kind of automation nobody thinks about until the storage bill spikes or someone asks for "last Tuesday's data" and it's gone. An n8n scheduled data export turns the recurring "pull the rows, save a file, stash it somewhere" chore into a cron job. But the version worth running does three things the popular templates don't: it works for any source, it timestamps for versioning, and it prunes itself so the folder doesn't grow without limit.

Search this and you mostly find Sheets-to-Drive backups or workflow-JSON backups. Those are useful, narrow tools. The general pattern (read any source, write a dated file, store it, clean up the old ones, alert on failure) is the one this post builds, and it's distinct from the instance backup workflow that snapshots n8n itself.

What you can export on a schedule

The same shape covers most recurring export needs:

• A Postgres or MySQL table dumped nightly for an analyst
• A Google Sheet snapshotted weekly for an audit trail
• An API's data pulled daily and archived as JSON
• A filtered slice of a CRM exported for a partner
• Yesterday's orders shipped as a CSV to finance
• Any "email me the data every Monday" standing request

The Scheduled Export Pipeline

Schedule (cron) → Read source → Convert to File (CSV) → Name with timestamp → Store
                                                                                  │
                                                                          Prune old files
                                                                                  │
                                                                          Alert on failure

The two steps after "store" are what most templates leave out, and they're the ones that keep the workflow healthy long-term.

1. Trigger on a real cron

Use the Schedule trigger with a cron expression, not a fixed interval, when timing matters. 0 6 * * * runs at 6am daily; 0 7 * * 1 runs Monday at 7am. One caveat worth internalizing: a Schedule trigger set to a tight interval will silently drop a run if the previous execution is still in flight. For heavy exports, give the cron enough headroom that one run finishes before the next starts.

2. Read the source

This is where the general pattern beats the Sheets-only templates. Swap the read node to match the source: Postgres or MySQL with a SELECT, Google Sheets for a tab, HTTP Request for an API. The rest of the pipeline doesn't care where the rows came from.

-- example: yesterday's orders
SELECT id, customer_email, amount, created_at
FROM orders
WHERE created_at >= NOW() - INTERVAL '1 day';

3. Convert to a file

The Convert to File node turns the items into a CSV (or XLSX, or JSON) binary. Pick the format your consumer actually wants; finance usually wants CSV, a data team might prefer JSON. Set the delimiter explicitly; a European consumer opening a comma-CSV in a semicolon locale gets one mangled column.

4. Name it for versioning

A file called export.csv overwrites itself every run, which defeats the point of a history. Stamp the name with the date so each run is a distinct, restorable snapshot:

const date = new Date().toISOString().slice(0, 10);
return [{ json: { filename: `orders_export_${date}.csv` }, binary: $binary }];

Now orders_export_2026-06-14.csv sits beside last week's, and "give me last Tuesday's data" is a folder lookup.

5. Store and prune

Upload to Google Drive, S3, or wherever the archive lives. Then comes the step nearly every template skips: prune. Without retention, the export folder grows forever until it's a storage problem or an audit liability. List the folder, filter files older than your window, delete the rest:

const keepDays = 90;
const cutoff = Date.now() - keepDays * 864e5;
return items.filter(({ json }) => new Date(json.createdTime).getTime() < cutoff);

The opinionated take: an export workflow without a retention policy is half-built. Storage is cheap right up until it isn't, and an unbounded archive of customer data is a compliance question waiting to be asked. Decide the window when you build it, not after the bill arrives.

Implementation patterns

Pattern 1: Nightly table dump. Cron at 2am, SELECT the table, Convert to File, upload with a dated name, prune past 90 days. The workhorse pattern.

Pattern 2: Weekly stakeholder export. Monday cron, read a filtered slice, email the CSV as an attachment so the recipient never logs in. Lighter retention since the file also lives in their inbox.

Pattern 3: Multi-format archive. Convert the same data to both CSV and JSON, store each in its own folder. Costs one extra node, serves two consumers. The scheduling mechanics here mirror the scheduled tasks and cron guide.

n8n nodes you'll use most

Getting started

1. Add a Schedule trigger with the cron expression for your cadence.
2. Add the read node matching your source and write the query or range.
3. Add a Convert to File node and pick CSV, XLSX, or JSON.
4. Build a timestamped filename in a Code node.
5. Upload to your storage of choice.
6. Add a prune step that deletes files past your retention window.
7. Add a failure branch that alerts you, then run once and check the file lands.

Assembling the read, convert, timestamp, store, and prune chain for each new source gets repetitive. A dashboard template that already reads a source on a schedule and ships a formatted output is a faster on-ramp.

A scheduled export that versions its files and cleans up after itself is the unglamorous backbone of a data team's trust in its own archive. Set the cron, stamp the date, prune the old ones, and the "where's last week's data?" question answers itself. Next, automate the inbound side with the webhook to database workflow, or feed the exported data into a live view with the KPI dashboard automation. The App Analytics Dashboard shows the same scheduled-read-and-log pattern against a live GA4 source. Browse the rest of the reporting templates when the exports are humming.