Airtable revision history, and its limits
Updated · about 7 minutes
What revision history is
Expand any record and the panel on the right shows its activity: comments, and a list of edits to the record’s fields, each with the collaborator who made it, the time, and the value before and after. For a change made by an automation or a sync, the entry names the automation or the sync rather than a person. Airtable calls this record-level revision history, and it is on every plan.
It answers the first question after a mistake, “what did this cell say before?”, and the second, “who changed it?”, for one record at a time. There is no restore button; you read the old value and type it back.
How long each plan keeps it
| Plan | Revision history kept | Snapshots kept |
|---|---|---|
| Free | 2 weeks | 2 weeks |
| Team | 1 year | 1 year |
| Business | 2 years | 2 years |
| Enterprise Scale | 3 years | 3 years |
From Airtable’s help centre, which also notes that the limits do not apply to comments: those stay in the activity feed until deleted. On Free, two weeks is a short window for the kind of mistake that is noticed when the quarterly report does not add up. The retention is also a property of the plan, not the base: a downgrade shortens it.
Six questions it cannot answer
- “Which records changed on Tuesday afternoon?” Revision history is per record. There is no view of it across a table or a base, no filter by time or by actor, no search. If an import touched six hundred records, the history is in six hundred places.
- “What did this table look like at 14:05?” It shows edits to one record, not the state of a table at a moment. Reconstructing a table at a time means reading every record’s history backwards, by hand.
- “Can a script or an integration read it?” No. Revision history is not exposed by Airtable’s API, a limitation the community has asked about for years. Nothing outside Airtable can read, export or copy it.
- “Is it in the restored base?” No. A base restored from a snapshot, or duplicated, has no revision history; Airtable’s documentation says so. The history belongs to the live base only.
- “What about a deleted record?” Its history goes to the trash with it and comes back with it within seven days. After that, the record and its history are gone together; a snapshot has the record’s values at the snapshot’s moment and nothing about who changed them.
- “Is it kept forever on Enterprise?” Three years on Enterprise Scale, and the enterprise audit log is a record of workspace and account events rather than a copy of cell edits. For a regulated record of changes, both have to be supplemented.
Revision history is not base history
Two things in Airtable are called history. The record’s revision history is the per-record list above. The history icon at the top right of a base (the clock next to Share) opens the base’s snapshots and its trash. Snapshots are whole-base copies at a moment, restored as a new base; the trash is seven days of deleted tables, views, fields, extensions and records. Neither says who changed a cell; the record does. The restore guide goes through all three in the order to try them.
Keeping a change history outside Airtable
The questions above have one shape: they are about the base, across records and across time, asked by someone who may not be looking at the record, sometimes months later, sometimes from outside Airtable. Answering them takes a history that is recorded as the changes happen, by something listening to the base, and kept somewhere the plan’s retention does not reach.
Airtable’s API offers the raw material: webhooks that notify a listener when records, fields or tables change, with the values before and after. Building on that is a project; the backup guide estimates it honestly. The things to get right are the ones that make the history useful: who made the change (a person, an automation, a form, a sync, an integration), the state of a table at any moment, a search by record, and a way to put a value back that keeps the edits made since.
AirtableBackup is that listener, run as a service. From the moment a base is connected, every change is saved with the name of who made it and shown three ways: a Timeline of the whole base by day, filterable by actor; the history of one record, found by name or by pasting its Airtable link; and any table as it was at any moment. Each row offers undo, undo of one field, or a restore point. The history is kept whole for as long as the account is active, on any Airtable plan, and it is yours to export. What it is not is a copy of Airtable’s own revision history: that cannot be read by anyone, and the coverage table lists it as a gap for that reason. The two histories run side by side from the day you connect.
Questions
- No. There is no export, and the API does not expose it. The revision history of a record can be read in the record itself, by a person, for as long as your plan keeps it. A change history you can export has to be recorded as the changes happen, by something listening to the base.
- No. Airtable's documentation says that bases restored from snapshots will not have revision history; comments are kept. The same applies to a duplicated base. The live base keeps its history; the copy starts with none.
- No tool outside Airtable can read it, so none copies it. AirtableBackup records every change from the moment a base is connected, with the author, and shows it as a Timeline across the whole base and as the history of any one record; the coverage table says in print that Airtable's own revision history is not copied. The two histories overlap from the day you connect; before that day, only Airtable's exists.
- No. Airtable keeps comments in the activity feed regardless of plan, until someone deletes them. Only the record edits are subject to the retention window.