A scheduled pull into a Google Sheet has stopped updating, or the reporting workbook has become too heavy to open, and nothing on your side changed. The reflex is to blame the connector’s supplier. First check whether the file or the project has hit a limit Google publishes.
The pull stopped, and nobody changed anything
This post reads two Google pages as they stood on 2026-10-11 and runs no tests of its own. Every figure comes from those pages, and anything inferred from a documented limit is labelled as an inference.
There are two families of limit, and they fail differently. The first is a size ceiling on the file: how many cells a spreadsheet may hold. It does not clear by waiting. The second is a set of per-minute request quotas on the Sheets API: how many calls a Google Cloud project, or one user within it, may make in a minute. That one clears on its own. The rest of the post separates the two.
No social media tool is named, ranked or compared here. Add-ons and connectors appear only as a category of caller, meaning anything that writes into a Sheet on a schedule. If your data arrives from exports, what you can actually export before a social tool shuts down covers what those files contain.
The size ceiling: what Google says a spreadsheet can hold
Google’s Drive file-limits help article lists maximum file sizes by type. For spreadsheets, on 2026-10-11, it read: “Up to 20 million cells or 100MB for spreadsheets that are created in or converted to Google Sheets.”
| Item on the page | Wording on 2026-10-11 |
|---|---|
| Sheets created in or converted to Google Sheets | Up to 20 million cells or 100MB |
| Excel file converted to Sheets | Any cell with more than 50,000 characters will be removed in Sheets |
| Connected Sheets, pivot tables | Up to 200k rows |
| Connected Sheets, extracts | Up to 500k rows or 5m cells |
The two Connected Sheets lines describe a different feature with different numbers. They are not the cap on an ordinary spreadsheet.
The page states the cap in cells, not rows, and cells are rows times columns. Our reading is that the count runs across every tab in the file, so a forgotten tab still spends the budget.
Here is an illustration with invented inputs, not data. Suppose a daily export appends one row per post per metric per day, the sheet has 12 columns, and the account publishes 40 posts a day tracked on 5 metrics. That is 200 rows and 2,400 cells a day. Dividing 20,000,000 by 2,400 gives about 8,333 days. Change the inputs and the answer moves fast: 30 columns and 400 posts a day on 5 metrics is 60,000 cells a day, which reaches 20 million in about 333 days. The 100MB half of the limit could bind first, and the page does not say which Google checks first.
The request quotas: 300 a minute, 60 a minute, and a 429
The Sheets API usage limits page describes per-minute quotas that are “refilled every minute”. Its table, as fetched on 2026-10-11:
| Request type | Per minute per project | Per minute per user per project |
|---|---|---|
| Read requests | 300 | 60 |
| Write requests | 300 | 60 |
Google gives its own worked example. If an app sends 350 requests in one minute against the read limit of 300, the additional 50 exceed the quota and generate a “429: Too many requests” HTTP status code response. The page says to use an exponential backoff algorithm, and that after 1 minute you can execute requests again.
Other behaviours on the same page:
- A batch request, including any subrequest, is counted as one API request toward the usage limit.
- All Sheets requests are applied atomically. If any request is not valid, the entire update is unsuccessful and none of the changes are applied.
- When Sheets processes a request for more than 180 seconds, the request returns a timeout error.
- There is no hard size limit for an API request, but the page recommends a 2 MB maximum payload because other processing components may impose limits.
The project versus user split is where shared setups get caught. The 300 is per Google Cloud project and the 60 is per user within it. If several automations authenticate through the same project, they draw on the same 300 together, so a chatty one can leave another with nothing for the minute. The page also notes that API calls by a service account are considered to be using a single account.
Which limit looks like which symptom
Google documents the limits, not the symptoms. Each row pairs a symptom with the documented limit it is most consistent with. Those pairings are our inferences, not statements from Google.
| What you see | Limit it is consistent with | What it does not prove |
|---|---|---|
| Pull fails, then works a minute later; failures come in bursts | Per-minute quota and a 429, which the page says clears after 1 minute | Does not show the vendor is at fault, and does not show it is not. Several callers may share one project’s 300. |
| Pull fails every time on a large write, or after a long run | The 180 second processing limit, or a payload well above the recommended 2 MB | Does not show whether the caller or the sheet is the slow part. |
| Pull fails every time once the file is large, while a fresh sheet works | The file approaching the documented cell cap. This is an inference; Google does not state it as a symptom. | Does not rule out a different error inside the vendor’s own code. |
| Workbook is slow to open | No documented link. The size pages give ceilings, not performance thresholds. | Does not show the file is near the cap. [EVIDENCE NEEDED: a Google source naming a cell count or size at which a Sheet becomes slow] |
One consequence of the atomic rule: a single malformed row in a large batch means no changes land, which can look like total failure. That is not a quota, and the table above will not explain it.
Backoff, batching and the part the owner controls
Google tells callers to catch time-based quota errors and use a truncated exponential backoff. The wait is min((2^n)+random_number_milliseconds, maximum_backoff), with n incremented for each request. The maximum backoff is “typically 32 or 64 seconds”, and clients should at some point be prevented from retrying indefinitely.
If you did not write the caller, you cannot change its retry logic, but you can ask. Three questions for an add-on’s support, framed as questions and not as suspicions:
- Does it batch writes, so that many cell updates go out as one request?
- Does it retry with backoff when it receives a 429, and does it stop after a limited number of attempts?
- Which Google Cloud project’s quota does it draw on, its own or yours?
Google documents a route for asking for more headroom: a quota adjustment request from the Quotas and System Limits page in the Google Cloud console. The page says applying does not guarantee approval.
On cost, the limits page said on 2026-10-11: “All standard use of the Google Sheets API is available at no additional cost. Exceeding the quota request limits is planned to incur charges to your Google Cloud billing account later in 2026.” That wording may have changed since, so check the page directly. The same pattern appears outside Sheets, as in free quotas that a traffic spike empties.
When a Sheet should stop being the reporting database
Move off a Sheet when you can compute that the file will reach the documented cell cap within your planning horizon, or when quota errors recur at your normal schedule instead of at a one-off spike. Neither calls for a specific product, and this post recommends none.
Exporting older rows to a separate archive file, and keeping only the recent window in the live sheet, stays inside both documented limits. This is a general practice, not a verdict on any tool. It works better when columns do not change between exports, which is where a UTM convention that survives a handoff helps: stable tags mean stable columns, and stable columns make the cell count predictable.
Sources, fetch date and what this page is
Limits verified 2026-10-11. Sources fetched that day:
- Google Drive Help, file sizes, redirected then HTTP 200
- Google Sheets API usage limits, HTTP 200
This page is not Watchdog data and is not on the re-verification schedule. Google can change either page at any time, so recheck the limits at Google before relying on them.
followedapp is published by the team behind RecurPost, and RecurPost is a covered vendor under the same rules as every other.
FAQ
How many cells can a Google Sheet hold?
On 2026-10-11 the Drive file-limits article said “Up to 20 million cells or 100MB for spreadsheets that are created in or converted to Google Sheets.” Our reading is that the cap applies to the file across all tabs, so recheck the page before planning around it.
What is the Google Sheets API request limit?
On 2026-10-11 the usage limits page listed 300 read requests and 300 write requests per minute per project, and 60 of each per minute per user per project. A batch request, including its subrequests, counts as one request toward the limit.