How long your automation keeps its history, and what disappears

September 3, 202616 min readUpdated September 13, 2026

A client rings in November about a booking made in August and says the confirmation never arrived. You open the automation that sends confirmations, scroll back to 14 August, and find nothing. The workflow still runs every morning. The record of what it did that day was deleted weeks ago, on a schedule nobody in your business chose. Automation run history retention on the platforms small firms use is counted in weeks rather than years, and the questions that need those records arrive later than that.

Whether your automations work at all is a separate problem. This is about the quarter afterwards, and whether you can show what they did.

Three things are being kept here, on three different clocks: the run history inside the automation platform, the data sitting in that platform's own tables, and the records your automation created in the apps at either end. Only one of the three has a deletion schedule the vendor writes down.

Every page quoted below was read on 18 August 2026. These figures change without notice, so check the vendor's page rather than this one.

Why is the record gone by the time somebody asks for it?

Because the asking runs on a slower clock than the deleting. A card chargeback, a client disputing what they agreed to, a supplier querying an invoice, an accountant working back through last quarter: none of those reliably lands inside thirty days. Retention windows on the mainstream platforms start at seven days. Nobody set the two clocks against each other.

The shape is always the same. An approval that the second approver never found the email for surfaces a month later, and by then the run has left the window. On Make's forum in March 2026 a user asked for the logs of a scenario that had run on 4 February and got "lLog detail doesn't exist" back. The thread was answered by community members rather than by Make staff, and it did not end in a recovered log.

The platform did exactly what its documentation says it does, on a schedule nobody in the business had ever read.

Which three records are we actually talking about?

Run history, platform storage, and the records in your connected apps. Run history is deleted on a documented schedule. The platform's own tables and data stores follow separate rules, mostly undocumented as retention. The records the automation created elsewhere usually survive, because they live under those systems' rules instead of the automation vendor's.

Zapier draws the first line itself, in its help centre section on deleting Zap runs: "Deleting the Zap run only removes the record of the run. It cannot undo the action." The history describes events that happened somewhere else.

The middle layer is the murky one. Make's page on deleting user data lists what you can remove by hand, including "Data stores", and names no automatic deletion schedule. Zapier's downgrade page says "you will not lose any existing data", then limits adding new data over the plan's cap, which is a storage rule rather than a retention one. I found no documented age-based expiry for either. That is an absence in the documentation rather than a promise things are kept forever.

The third layer is reasoning, since no vendor documents what your other software does. The confirmation email sits in a sent folder, the invoice in your accounting package, the booking in the calendar. Those are usually where the usable evidence still is.

How long is automation run history retention, platform by platform?

Weeks, not years, at every tier below enterprise, and two of the four vendors publish figures that disagree with their own other pages. The table below comes from vendor documentation read on 18 August 2026. The row that surprises people most is the self-hosted one, where a deletion job runs on your own database by default.

	Default retention	Changeable, and where	What triggers deletion	Export route
Zapier	Pages conflict: "a maximum of 60 days" on one, "29-69 days" on another	Enterprise only, and only downwards, to "7-30 days long"	Age, plus a display cap of 10,000 runs	Export my data, emailed as a ZIP; run data behind a CSV of download links
Make	Free 7 days; Core, Pro, Teams 30 days; Enterprise 60 days	Only by changing plan	Age, by plan	History tab, export scenario history as CSV
n8n Cloud	Starter 7 days / 2.5k runs / 2.5 GB; Pro 30 / 25k / 25 GB; Enterprise unlimited / 50k / 50 GB	By plan	Whichever of age, count or storage is reached first	None documented
n8n self-hosted	Pruning on by default: 336 hours (14 days) and 10,000 executions	Fully, through environment variables	Age or count, whichever comes first	Your own database backup
Power Automate	Pages conflict: "28 days" on two, "Run retention in storage" of "30 days" on a third	Dataverse copy only: 28, 14, 7 or Disabled, solution cloud flows	Age, through a time-to-live value on the record	Per flow: Run history, See all, Download CSV

Read the table with one question in mind: which limit is nearest to you today. On an entry plan the answer is a week. Make Free stores seven days and n8n Starter stores seven days, an evidence window shorter than most people's holiday.

The second thing to notice is the direction of travel. Nobody sells longer history as a feature. Zapier's only retention setting shortens the window, and it sits on Enterprise. Make's only lever is the plan: there is no setting to delete logs on your own schedule, which matters if personal data from customers is sitting in the history.

What the platforms charge, and what each counts as a run when it bills you, belongs to what automation costs a small business.

If you would rather have somebody map which of your processes need to be provable, that is the process audit. $299 and three business days, for a written map of your processes with what each is worth. You keep the map whether or not you hire us, and the fee comes off the project.

Why does Zapier publish two different numbers?

Because two of its help pages answer the question differently and both are live. The Zap history article promises "a maximum of 60 days of Zap run data in your Zap history", with a display limit of 10,000 runs. The retention article says "Zapier will retain Zap history for 29-69 days." Neither says thirty days, which is the figure most people repeat.

The retention page hands the explanation for that range to a link. I opened that legal page twice in August 2026 and got a title and a heading with no body both times. The reason the window is a range is documented somewhere I could not read.

What that page does document is who can change it. Customisation is an Enterprise feature, the range offered is "7-30 days long", and the wording is blunt: "Zap history deletion is permanent and may take immediate effect."

The gap between the pages is not academic. Ask the forum how long history is really kept and the answers come from partners rather than staff, and none of them settles it. Treat the shorter number as the one you can rely on.

What deletes the history first: age, count, or size?

Whichever of the three you reach first. n8n writes this down more plainly than anyone else, and the same race runs on other platforms under other names. A window in days is the limit you were told about, and often not the one that bites.

Here is n8n on its pricing page, answering its own question about how many executions it keeps and for how long:

"We keep your most recent executions so you can inspect and debug them. Each plan has a limit on the number of saved executions, a limit on the total storage they use (in Cloud), and a retention window in days. We keep executions until you reach the first of those, then remove the oldest. Reaching a limit does not stop your workflows from running. It only changes how much history is retained."

Read the last two sentences again. Reaching the retention limit costs you no runs and no orders; it costs you the ability to show what happened afterwards.

The Enterprise row carries the trap. n8n lists retention there as unlimited, alongside caps of 50,000 saved executions and 50 GB. On a busy account the count arrives long before the time does, so unlimited retention means however long 50,000 runs take to pile up.

Does self-hosting mean you keep everything?

No. On a self-hosted n8n instance, pruning is enabled by default at 336 hours, which is fourteen days, and at 10,000 executions. Your server, your database, and a deletion job you did not switch on. Anyone who assumed that self-hosting settled the question has a deletion job running on their own server tonight.

Setting	Default	What n8n says it does
`EXECUTIONS_DATA_PRUNE`	`true`	"Whether to delete data of past executions on a rolling basis."
`EXECUTIONS_DATA_MAX_AGE`	`336`	"The execution age (in hours) before it's deleted."
`EXECUTIONS_DATA_PRUNE_MAX_COUNT`	`10000`	"Maximum number of executions to keep in the database. 0 = no limit"
`EXECUTIONS_DATA_HARD_DELETE_BUFFER`	`1`	"How old (hours) the finished execution data has to be to get hard-deleted."
`EXECUTIONS_DATA_SAVE_ON_ERROR`	`all`	"Whether n8n saves execution data on error."
`EXECUTIONS_DATA_SAVE_ON_SUCCESS`	`all`	"Whether n8n saves execution data on success."

The count is the one that catches people. Set pruning on and the maximum age to 700 hours, and a busy instance still watches its history vanish in under a day, because EXECUTIONS_DATA_PRUNE_MAX_COUNT defaults to 10,000 and the count wins the race long before the age does. Set the count to 0 and the age becomes the only rule.

He set the dial he could see and lost the data to a dial he could not. That applies to hosted plans too, where you have no dials at all.

Two exemptions are worth knowing. Executions with "new, running, or waiting status aren't eligible for pruning", and annotated executions are "never pruned". Annotating a run is the documented way to keep one past the window, so mark the runs that matter in the week they happen.

Where does Power Automate keep run history, and for how long?

Twenty-eight days on two Microsoft pages, thirty on a third, all live in August 2026. A longer store exists in Dataverse. It covers only solution cloud flows, the admin centre offers shorter values rather than longer ones, and Microsoft writes that this copy is not completely lossless.

The troubleshooting page is unambiguous: "By default, flow run data is stored for 28 days." It adds the instruction that matters: "To maintain a flow run history for over 28 days, you need to manually capture the run history before it's deleted."

The limits page, more recently dated, lists "Run retention in storage" as "30 days". Same product, two live pages, two numbers. I am not going to resolve that by picking one, because the disagreement is the finding. Nobody in your business chose this schedule, and nobody at the vendor is reconciling the pages that describe it.

The Dataverse option is narrower than it sounds. Microsoft writes: "Only solution cloud flows, with their definitions in Dataverse, can have their run history stored in Dataverse." The default there is 28 days again, and an administrator can set 28, 14, 7 or Disabled.

Then the caveat. Microsoft notes that the data stream behind those longer-lived records "isn't transactional, and hence isn't 100 percent lossless". The portal's own flow execution history, by contrast, "is transactional, and therefore provides a lossless view of runs". The copy you keep for longer is the less complete of the two.

Desktop flows are the mirror image. Their run history sits in Dataverse tables and accumulates until somebody deletes it, which is why Microsoft's page on the subject warns that bulk deletes are irreversible. One product, two kinds of history: one vanishes on a schedule you did not set, the other grows until you set one.

What happens to your history when you cancel or downgrade?

Less is documented than you would expect. Zapier's cancellation page does not mention Zap history at all, and neither does Make's. I looked for it on both. n8n's terms are the only ones I found that put a number on it, and elsewhere the answer has to be assembled from two pages.

For Make, those two pages are the cancellation page and the pricing table. The organisation converts to Free at the end of the cycle, and Free stores seven days, so cancelling can cut your history from thirty days to seven. Make writes that consequence in no single sentence I could find, so treat it as a deduction.

n8n is the clearest of the set. Customer Content is "usually deleted 6 months after the deactivation of your account with us", after thirty days of email warning.

Deliberate deletion is faster and final. Zapier says it "will permanently delete your Zap content, Zap runs, and Zap workflows", and that this cannot be undone. The rule is dull and cheap: export before you cancel. The same applies when a build changes hands, and who holds the export belongs on the list in the automation handover checklist.

What does an export actually give you?

Less than the word suggests, and the platforms differ more than the word does. Zapier emails a ZIP containing a list of download links. Make's CSV carries a link to each execution instead of the execution data. Power Automate exports one flow at a time, by hand. For n8n Cloud I found no documented one-click history export at all.

Make's help centre is candid about the contents. The exported file holds status, timestamp, author, operations count, duration, and "the link to examine the execution". Read that last item slowly. Once the underlying log is past its window, the link opens nothing, and the export you filed each month is an index to deleted pages.

Zapier's export is a two-step affair. You request it and receive an email with the history for your accounts. Inside the ZIP is a file named on the pattern task_history_download_urls_[pagenumber].csv, which "contains a list of URLs from where you can download Zap run data". The run data is another download beyond that.

Power Automate's route is per flow: Run history, See all, Download CSV. Microsoft describes the contents as a run's status, start time, duration, inputs and outputs. That is the fullest export here, and the most laborious.

What should you export, and how often?

Once a month, for the automations that touch money, promises or personal data, into somewhere that is not the automation platform. Ten minutes per platform covers most small businesses. The value shows up on exactly one day, which is the day somebody disputes something.

List the automations that matter. The ones that move money, make a promise to a customer, or handle personal data. Usually three to six.
Write down each platform's window and the date you checked it. Seven days and sixty days call for different habits.
Export ahead of the shortest window. A seven-day window needs a weekly export, on a fixed date.
Store it off the platform. Your own drive, with the accounting records, where it survives a cancellation or a plan change.
Keep the connected-app record where it is stronger evidence. The sent email, the invoice PDF, the calendar entry. Those usually outlive the log.
Test one retrieval. Pick a date sixty days back and try to answer what a given automation did that day. An export nobody has opened is a habit rather than evidence.

The obvious shortcut is a weekly or monthly scenario that backs up the logs of your other scenarios to a drive or a sheet. That works, with one concession. The backup is itself an automation, and it needs to report what it copied rather than only that it ran. On self-hosted n8n the database backup is the export, and the pruning settings decide what is left to back up.

Which automations deserve this, and which do not?

Most of them do not. Applying the habit to everything turns a ten-minute routine into an hour nobody keeps up. An internal notification, a lead copied into a spreadsheet, a job that renames files overnight: nobody will ask you to prove what those did in August. Three questions separate the ones that earn an export.

Did money move, or fail to move? Payments, refunds, invoices, payouts.
Was a promise made to a person? A booking, a quoted price, a delivery date.
Was personal data handled? Anything a customer could ask you to account for.

Three ordinary disputes show what that catches. In November somebody says no reminder ever arrived, which is the weak point in cutting appointment no-shows. A customer arguing a payment demand was unjustified is the record behind automated invoice chasing. And when supplier bank details change, the paper trail is the point of the controls around supplier bank changes.

Whether a process should be automated at all is a different question with its own five tests, in when not to automate.

What is the rule, in one line?

If an automation touches money, a promise or personal data, treat automation run history retention as a display setting rather than as your record. The record is whatever you exported and stored somewhere the vendor cannot reach.

None of this is a legal argument. Nothing here establishes how long you are obliged to keep anything, and your accountant has the answer for your trade and jurisdiction. The operational fact stands on its own: the question arrives after the evidence has been deleted.

So the honest version of "it is all in the system" is a date. Ask your platform what its window is, ask how long your disputes take to surface, and see which is bigger. Where the second wins, you have a retention decision to make.

Working out which of your processes need to be provable is part of what the process audit puts in writing.