Get an Airtable Alert When a Project Record Goes Stale

An Airtable stale-record alert can check when meaningful project fields last changed, notify the owner, and record that the alert was sent. A daily check finds overdue records, but each record gets only one alert until someone updates it again.

A stale-record alert needs a definition of progress

An Airtable alert when a record has not been updated should measure project progress, not every edit to the record. A correction to an email address or an automation writing an alert timestamp does not mean the work moved forward. Decide which fields count as a meaningful update before building the reminder.

For a project table, those fields might be Status, Next action, and Progress notes. Add an Airtable Last modified time field called Project last updated, and configure it to watch only those fields. Keep the alert timestamp out of its watched fields. Otherwise, sending an alert could make the project look newly updated and hide the fact that it is still stalled.

Choose a quiet period that fits the work. A project reviewed daily might need a shorter interval than work that normally waits for outside approval. Also decide which statuses should be excluded. A completed project should not generate a stale alert simply because nobody has edited it.

This is different from an alert for any changed value. If you need to react when a particular field changes, the approach in the Google Sheets column-change guide is a better match.

The last-modified field and alert timestamp have different jobs

An Airtable last modified reminder automation needs one field to measure inactivity and another to remember whether an alert has already gone out. Add Project last updated as a Last modified time field watching the progress fields you chose. Add Stale alert sent at as a date-and-time field that starts empty. Keep an owner email field available for delivery, along with the project name and status.

Suppose a project is considered stale after three days without a meaningful change. Its owner has an email address, its status is not Done, and Project last updated is older than three days. If Stale alert sent at is empty, the record needs an alert. Once the email is sent, the automation fills in Stale alert sent at. The next daily check sees that timestamp and leaves the owner alone.

If someone later changes Progress notes, Project last updated moves forward. The old alert timestamp stays in place, but the project is no longer stale. If another three days pass without progress, the newer project update is later than the old alert, so the record becomes eligible again. There is no need to clear the alert field by hand.

A scheduled check finds stale records without sending daily reminders

A scheduled Airtable automation can look for stale records each day without emailing each owner every day. Create a formula field called Needs stale alert that returns a value only when the record is old enough, has an owner email, is not Done, and has not been alerted since its latest meaningful update.

For the three-day example, the formula can be written as follows:

IF(AND({Project last updated}, {Owner email}, {Status} != "Done", DATEADD({Project last updated}, 3, 'days') <= NOW(), OR(NOT({Stale alert sent at}), {Project last updated} > {Stale alert sent at})), "Alert", "")

Build an Airtable view that shows records where Needs stale alert is Alert. Schedule an automation to run daily and find records in that view. For each record found, send a message to Owner email with the project name, last project update, and a link to the record. Then update that record's Stale alert sent at field with the alert time.

Check that your automation can process each found record individually and map its own owner and record ID into the email and update actions. If your available setup cannot do that, use an automation platform that can loop through the found records. Check the tools' current documentation and limits before relying on the workflow.

The alert should tell the owner what needs attention

A useful stale-project alert names the project, states when its progress fields last changed, and links back to the record. Ask the owner to review the next action or update the progress notes, rather than implying that the project is late. Inactivity and a missed deadline are different problems. If the real requirement is to keep a calendar aligned with deadlines, use the Airtable deadline-sync guide instead.

Notify the owner listed on the record, not a fixed team inbox, unless shared triage is your actual process. If the owner is stored as an Airtable collaborator, check how your chosen email action accepts recipients. An Owner email field can make the destination explicit. Leave records with no usable owner email out of the sending view and review them separately, rather than silently trying to send an incomplete alert.

Keep the message short enough to act on from an inbox. The record should remain the place where the owner updates status and notes. If you also share project status with clients, the guide to sharing Airtable status without exposing other clients helps separate an internal reminder from a client-facing view.

A test should cover the first alert and the next quiet period

Test an Airtable stale-record automation with records that should alert, should not alert, and have already been alerted. Make a temporary project with a known owner email and progress fields you can safely edit. For testing, choose a short quiet period in a copy of the formula rather than changing dates on a live project. Run the automation's test steps or scheduled check and inspect both the message and the updated Stale alert sent at value.

Run the check again without changing a watched progress field. The same project should not produce another email. Then edit a watched field. Project last updated should move forward, making the record ineligible until the quiet period passes again. Also test a Done project and a project with no owner email. Neither should send a message.

Watch for a partial failure: the email might send, but the action that writes Stale alert sent at might fail. A later check could then send a duplicate. Review automation run history when an owner reports repeated alerts. An alert for automation failures, as described in the Zapier failure-alert guide, addresses that separate monitoring problem.

The simple option is enough for a small project table

A native Airtable automation is a reasonable starting point when the project record, owner email, and progress fields all live in Airtable. The daily schedule provides a regular check, while the alert timestamp prevents routine repeat emails. The owner does not need another app just to receive a reminder.

Check the view and automation history periodically. A view can reveal records excluded because their owner email is blank, their status is unexpected, or their last-modified field has no useful value. A project created but never edited may need special handling if its tracked last-modified field is empty. In that case, add a Created time field and use it as the starting point when there has been no tracked update.

Use an outside automation tool if the notification must go through another service, the recipient rules are more complex, or your Airtable setup cannot process all matching records as intended. Keep the same decision rule whichever tool sends the message: the project must be stale, have a valid recipient, and have no alert recorded since its latest meaningful update. Check Airtable's current automation documentation and your account's limits before putting the workflow into regular use.