Airtable Automation Watch - Find Broken Automations

Airtable Automation Watch - Find Broken Automations

Find the Airtable automations that are quietly broken, and the edit that broke them. Automation Watch reads every automation in a base, checks each step against the base's real structure, and compares it with the last run. Leave the token empty and press Start to see a worked example on a bundled sample base; it is free and needs no account details.

• Finds problems Airtable does not show. Text written into a date field, a step writing to a deleted or computed field, a trigger waiting for a dropdown option that no longer exists, a secret pasted into a script, a formula or lookup that has stopped calculating.
• Points at the edit that caused it. When a problem is new since the last run, the change that introduced it is linked and raised to the same severity.
• Sees the whole base. Automations, view filters and sorts, interface dashboards and formulas, so a deleted field comes with the list of everything that used it.
• Read-only, one scope. A personal access token with schema.bases:read and nothing else. It never reads a record and never changes anything.

What does it check?

Rows are written worst first.

Severity	Check	What it catches
critical	Writes to / reads a deleted field	A step still maps a field that no longer exists, so runs fail.
critical	Trigger or step table deleted	The automation points at a table that is gone.
critical	Computed field stopped working	A formula, rollup, lookup or count Airtable marks invalid.
high	Text in a date or number field	For example {Appointment Date} + 2 days written into a date field. Airtable does no arithmetic there.
high	Writes to a computed field	Formula, rollup and similar fields cannot be written.
high	Trigger can never fire	It waits for a dropdown option that was deleted.
high	Sets a deleted dropdown option	The step picks an option that no longer exists.
high	Secret in a script	An API key or token written into a Run script step.
high	Script uses a missing table or field name	getTable("…") or getCellValue("…") with a name that does not exist.
high	Invalid setup or deployment error	Airtable itself reports the automation as broken.
medium	Hard-coded linked record	Every run links the same record by name.
medium	Unpublished edits	The draft differs from what actually runs.
low	Automation off / creates blank records	Housekeeping.

And between runs:

Severity	Change
critical	A field an automation uses was deleted (with every automation, view and dashboard it affects)
high	An automation was turned off or deleted, a step was removed, a trigger now watches another table, a field an automation uses changed type, a dropdown option an automation uses was deleted, or a field or table was renamed while a script still uses the old name
medium	A field mapping, trigger condition, step setting or script changed (scripts come with a line-by-line diff), or a step or automation was added
low	A field an automation uses was renamed (Airtable automations follow renames; tools outside Airtable may not)

How to use it

1. Leave Airtable personal access token empty and press Start to see the sample report.
2. To check your own base, create a token at airtable.com/create/tokens with only the schema.bases:read scope, and add your bases under Access.
3. Paste the token, list your base IDs (or base URLs), and press Start.
4. Schedule it daily or weekly. The first run of a base saves a baseline and already reports problems; every run after that also shows what changed.

Input

Field	What it does
Airtable personal access token	Read-only token with only schema.bases:read. Leave empty for the free sample run.
Bases	Base IDs (app...) or whole base URLs, one per line. Empty = every base the token was granted.
Minimum severity	Drop findings and changes milder than this (default: low).
Snapshot store name	Named key-value store holding one snapshot per base for the next comparison. One name per schedule.
Write a shareable report	One self-contained HTML page per base (default: on).
Maximum bases	Stop after this many bases (default: 50).

Output

• Dataset: one row per finding or change, with severity, the automation and step, what is wrong, how to fix it, before and after values, the edit that introduced it, and what it affects.
• Report: a self-contained web page per base, linked from each row. It needs no Airtable access to read, so you can send it to whoever owns the base.
• OUTPUT record and a bases dataset: one summary per base with counts by severity.

Sample row

{
  "rowType": "finding",
  "severity": "high",
  "title": "Puts text into a date field (new)",
  "automation": "Create Follow-Up Task for Completed Appointments",
  "where": "step 1 (createRecord)",
  "message": "Step 1 (createRecord) writes \"{Appointment Date} + 2 days\" into Tasks & Follow-Ups.Due Date, a date field. Airtable does not do date arithmetic here, so the value is rejected or the text is dropped.",
  "remediation": "Calculate the date in a formula field (for example DATEADD) and map that field instead.",
  "introducedBy": "Field mapping changed: Step 1 (createRecord) sets Tasks & Follow-Ups.Due Date differently.",
  "baseName": "Hasta OS (sample)"
}

How much does it cost?

Pay per event, at the price shown on this page: one event per base checked, charged only after that base's results are written. The sample run is free. A base that cannot be read (wrong ID, not granted to the token) is not charged. A failed run charges nothing. The run stops cleanly at your maximum cost per run.

Speed

The sample run finishes in under a second. A live base costs about one read per table plus one per automation, paced under Airtable's limit of five requests a second, so a 26-table base with 4 automations takes roughly half a minute.

Monitoring recipe

Schedule it daily or weekly with the same Snapshot store name. Each run compares with the previous snapshot, so the dataset becomes a changelog of your automations. To get alerted only on new rows, point Dataset Diff Monitor at this Actor.

Limitations

• Reads what Airtable's API exposes. Script steps are checked for table and field names and pasted secrets, not executed.
• View filters and interface settings are read for impact lists; they are not linted on their own yet.
• A base's first run has no history, so the "changed" section starts on the second run.
• Rows are not charged; the price is per base checked.

Changelog

• 1.0 (2026-10-31): first release. Automation lint, change tracking with the edit that introduced each new problem, impact across views, interfaces and formulas, HTML report, free sample run.

FAQ

Is my token safe? It is a secret input: Apify encrypts it and it is never written to the dataset, reports or log. It is only sent to Airtable. With schema.bases:read alone it cannot read or change a record.

Does it change anything in my base? No. Every call it makes is a read.

Does it need a paid Airtable plan? No. It works on every plan. Script steps only exist on paid plans, so script checks apply there.

Why are there no changes on my first run? The first run saves a baseline to compare with. Problems in the current base are reported straight away.

Does it use AI? No. Every check is a fixed rule, so the same base always gives the same result.