Troubleshooting Airtable base performance

Imagine you have a base that includes custom API integrations, third-party integrations, and syncs: 

• If the external integrations are set up to make requests to the base 24/7, then the queue may get overloaded with requests.

• If a human user then accesses the base when the queue is overloaded with integration requests, then they might find the base is slow to load tables or may even crash when taking manual actions in the base. This is because the manual request has to wait behind all of the API requests.

• For this reason, it is important to note that Airtable is not intended to be a backend hosting service/real-time database like Heroku, Parse, Firebase, or MongoDB. Instead, Airtable is primarily designed for use cases where all users will be directly interacting within the Airtable UI. 

Let’s consider another base that has a "Tasks" table, and instead of a multiple select field, it uses a linked record field to a "People" table to designate an assignee. 

Now, let’s say we want to add a lookup field to the People table in order to display the linked task statuses, a formula field that joins the array of the task statuses, and a rollup field that aggregates the total number of estimated hours for the linked tasks.

When a new assignee is added to a task, the Linked field on the "Tasks" table, as well as the Linked field, the lookup field, the formula field, and the rollup field on the People table all have to be updated. 

One of the most common causes of performance issues is the volume of API requests. These can be from custom integrations, integration tools (Zapier/Make), or other tools that integrate directly with Airtable (Stacker/Softr).

• Decrease the number of requests being made to the base from integrations.

• Consider the frequency of your integrations and adjust their timing so that requests don’t back up the queue while human users are using the base.

• Consider syncing necessary data to another base and making requests to that base, minimizing using the original base. This approach works better for GET requests.

Like integrations, automations running in near real-time—especially when coupled with integrations—can slow down base performance.

• Remove any unnecessary automations and/or consider configuring your automations to batch updates outside of working hours.

• Adjust your automation triggers where possible. For example, if you use a time-based trigger, consider decreasing the frequency and setting it to run outside your organization's working hours.

• Change automations that trigger "When a record" is updated to utilize the "When a record matches conditions" trigger. Often, this will decrease the number of automation runs needed.

Syncing is a computed action that can slow down base performance. Syncs typically handle larger volumes of data and run consistently.

Remove any unnecessary syncs.

If your ecosystem of syncs is complex, with multiple syncs pulling from a base used by collaborators, consider syncing data into a secondary base that serves as only a sync source to downstream bases—allowing the original base to sync to a single destination.

Formulas, especially time-based formulas that include the NOW() function can be taxing on large bases.

• Remove any unnecessary formula fields.

• Use the TODAY() function instead of NOW(), to decrease the request load caused by time-based formulas to decrease the request load caused by time-based formulas.

• Consider whether your requests impact complex base schema interdependencies and are slowing your base performance.

• Remove unnecessary lookups, rollups, and any formula fields that reference linked records, lookups, and rollups

In addition to what’s noted above, clearing your browser’s cache and cookies is an important part of troubleshooting. Below is a list of browsers, with links detailing how to clear the cache and cookies for each specific browser:

• Chrome

• Edge

• Firefox

• Safari

For our paid clients, we maintain a list of required domains that must be unblocked in order for Airtable to properly function. We provide updates to the list as changes occur.

Note that airtable.com has always been on this list, meaning that all subdomains of airtable.com must be unblocked. This includes the previous srp.airtable.com domain.

Yes, all subdomains must be unblocked. The prefix is random and cannot be predicted. All of the following subdomains must be unblocked:

• abcd.srp.airtable.com

• efgh.srp.airtable.com

• 0123.srp.airtable.com

No. The same data is being transmitted, we are just changing the domain name which it is being transmitted through. Previously this data was received in part through rt.airtable.com.

Check out our Security page for information about Airtable data and privacy.

If you're experiencing any of the errors mentioned, start by clearing your browser's cache. Review your browser's help documentation for more details.

If your connection is unstable or you're unable to connect, it is possibly related to one of the following:

• Corporate VPNs

• Security software (performing SSL inspection)

• Firewalls

• Anti-virus software

• Software installed by your IT team

Contact your IT or security department and inform them that you cannot connect to any subdomain under srp.airtable.com. Request they unblock HTTPS and WebSockets from srp.airtable.com and other subdomains in any relevant security software.

If you don't have an IT department or are connecting to Airtable on a home network, you will need to manually adjust the settings on your computer or network to mitigate any possible blocks (e.g., VPN, security/anti-virus software, firewalls, etc.).