Skip to content
AirtableBackup
Sign up

Guide

How to back up Airtable automations and scripts

Records have a trash and a revision history. Automations have neither. The scripts that run your base are the part of it most likely to be lost by a slip and least likely to be in any backup. Here is what protects them today, what does not, and the routine that keeps a bad edit from being a bad week.

Updated · about 8 minutes

Why automations are the least protected part of a base

An automation is a trigger, some conditions, a list of actions, and, for a script action, a program. In a mature base that is where the logic lives: the welcome email, the status that flips when a date passes, the record that is created in another table, the script that talks to an outside service. It is also the part of the base that Airtable protects least:

  • No trash. Airtable’s base trash holds tables, views, fields, extensions and records for seven days. Automations are not in that list. Delete one and it is gone from the live base.
  • No version history. Edit a script, click Update, and the previous script no longer exists anywhere in Airtable. The automation’s run history shows what happened on each run, not what the code was.
  • No export. There is no “download this automation” button. Copying one between bases means rebuilding it by hand.
  • It is where mistakes multiply. A wrong condition does not damage one record; it runs on every record that matches, and keeps running until someone turns it off. The restore guide covers the records; this one covers the automation itself.

What snapshots do for automations

A snapshot is the whole base, automations included, and restoring one creates a new base in which every automation exists as it did, switched off. That makes snapshots the one native way to recover a deleted or broken automation: restore the snapshot beside the live base, open the automation there, and rebuild it in the live base step by step, copying the script text across.

What it misses. The snapshot has to predate the mistake, and automatic snapshots are taken when Airtable decides; a manual snapshot before you edit is the only way to be sure of the moment. The restore is a whole base, so recovering one automation means a second copy of everything. Retention is by plan: two weeks on Free. And the copy lives inside the same account; if the base or the account is what was lost, so were the snapshots.

Verdict: take a manual snapshot before any automation change you would not like to redo from memory. It costs ten seconds.

The manual copy, and how to make it stick

For scripts, the oldest advice in the Airtable community is still right: keep the code somewhere else. Open the script action, select all, copy, and paste into a file. Where the file goes matters less than that it exists and is dated: a folder in your drive, a note, a git repository if your team has one. Name it after the base and the automation, and keep every version rather than overwriting.

For the rest of the automation, the trigger, the conditions and each action’s settings, the honest tool is a screenshot of each step, or a few lines of text saying what the trigger watches and what each action writes where. It feels beneath the dignity of the work and it is what lets a colleague rebuild the automation in twenty minutes instead of two days.

What it misses. It happens when someone remembers. The copy is as current as the last time somebody did it, and the automation that was changed in a hurry on a Friday is the one that was not copied. Make it part of the change routine below rather than a separate chore.

What the API exposes, and since when

Airtable’s REST API does not expose automations at all: not the list, not the configuration, not the scripts. For years that was the end of the conversation, and it is why the backup services could not back them up however much people asked. Since July 2026 Airtable’s MCP server exposes automation configuration, including the source of script actions, together with interface pages and form definitions. A tool that reads it on a schedule and keeps every version has, for the first time, an automation history that does not depend on anyone remembering to copy and paste.

What it misses. Reading is not writing. The API creates automations only as drafts and refuses script actions, so no tool can put an automation back into a base in place. What a backup can give you is the definition and the script text, versioned, to re-create by hand. That is a long way from nothing: the hard part of rebuilding an automation is remembering what it did, and a dated copy of its configuration and code is the memory.

What the backup services do

Most of them say, correctly, that they cannot back up automations, because the REST API they use does not expose them. On2Air Backups states it plainly. Backup247 does not list them. ProBackup’s help article began listing automations in October 2026; what is captured, and whether a script’s source is among it, is not documented, and the comparison page says so.

AirtableBackup reads each automation’s configuration and the source of every script action every night, together with forms and interface page metadata, and saves a new version whenever something changed, so the history of an automation is a list of dated versions you can open and compare. A restore is the definition and the script text, for the reason given above; the coverage table states it in those words. Interface layouts are not exposed to anyone and are not backed up.

A routine for changing an automation safely

  1. Take a manual snapshot of the base. History icon, Snapshots, Take snapshot. Name it after the change.
  2. Copy the current script into your file, dated, before you touch it. If a backup service is keeping versions for you, check that last night’s version is there.
  3. Switch the automation off while you edit, or edit a duplicate: Airtable can duplicate an automation within a base, and the duplicate starts switched off.
  4. Narrow the trigger for the first run. A view with a filter that matches one test record is the cheapest test harness Airtable has. Point the trigger at it, run once, read the run history, then widen.
  5. Watch the first real run in the run history, and check a few of the records it touched. If a run went wide, switch the automation off before fixing the records; the restore guide has the steps for that.
  6. Copy the new script to your file once it works. The file now has both versions, which is the version history Airtable does not keep.

Questions

Is a deleted automation in the trash?
Airtable lists tables, views, fields, extensions and records as what the base trash holds. Automations are not on the list. A deleted automation comes back only by restoring a snapshot taken while it existed, as a new base, and rebuilding it in the live base from what you see there.
Does Airtable keep old versions of a script?
No. When you edit a script action, Airtable asks whether to update or discard the changes; once updated, the previous version is gone. The run history shows what each run did and any errors, for a period that depends on your plan, but not the code that ran. Keeping a copy of the script outside Airtable is the only version history there is.
Can a backup tool restore an automation into my base?
Not in place, today. Airtable's API creates automations only as drafts and refuses script actions, so what any tool can give back is the automation's definition and its script source, for you to re-create or paste. AirtableBackup keeps both, versioned on every change, which turns a rebuild from an exercise in memory into a copy-and-paste.
What about interfaces and forms?
Interface pages and form definitions have the same shape of problem: no trash, no version history, present in snapshots. Airtable's MCP server exposes interface pages and forms alongside automations, and AirtableBackup saves their metadata nightly. Interface layouts, the arrangement of elements on a page, are not exposed and are not backed up by anything outside a snapshot.