A scheduled Google Sheets export stops at the same row or shows old numbers: check limits and state

The limits a scheduled script lives under

Google documents that a single script execution can run for up to six minutes, that total trigger runtime is 90 minutes a day for consumer accounts and six hours a day for Google Workspace accounts, and that a user can have up to 20 triggers per script. URL Fetch calls are limited per day, at different levels for consumer and Workspace accounts. Separately, the Sheets API allows 300 read and 300 write requests a minute per project and 60 per minute per user, with a 429 response and advice to retry with exponential backoff. Google says these quotas can change, so read the current page rather than relying on figures quoted here.

Who the trigger runs as

A time-driven trigger runs as the account that created it, at a slightly randomised time within the requested hour, not exactly on the minute. When the function fails, Google emails the creator a summary, and the project's Executions panel lists failed runs. If the person who created the trigger leaves, loses authorisation or never read those emails, the schedule can stop or fail while the report looks fine. Google's guidance for changing an existing trigger programmatically is to delete it and create a new one.

• Find out who created the trigger and whether they receive the failure emails.
• Open the Executions panel and look at recent failures and their reasons.

Four failure patterns

First, truncation: the script reads only the source's first page, so the sheet stops at a round row count. Second, a half-written report: the script clears and rewrites the live range, and a timeout or quota error leaves part old and part new. Third, overlap: a slow run is still working when the next starts, and rows interleave. Fourth, silence: nothing on the sheet says when data was last refreshed, so a stopped schedule is invisible.

A design that fails honestly

Read every page of the source and compare the number of rows read with the source's own total. Write into a staging range, and swap it into the report only when the counts match. Take a script lock with LockService so a second run waits or exits; remember that a lock only protects code once tryLock or waitLock has actually been called. Stop cleanly before the six-minute limit rather than being killed midway, and record why. Put a small status block on the sheet: data-as-of time, rows read and expected, last result and failure reason. A stale flag computed by a sheet formula from the data-as-of time shows a stopped schedule even when no script runs. A failed run then leaves the previous complete report in place, visibly marked.

• The completeness check must use the source's own total, not a count of the rows the script happened to read.
• The status block must show data age so a stopped schedule is obvious.

What fits, what does not, and how it is accepted

The fixed-price job "Make a scheduled finance export to Google Sheets complete, current and honest on failure" is £245 for one export into one sheet. The price is untested, scope is confirmed after your enquiry, and payment follows the agreed checks and your sign-off. It is accepted when a 250-row synthetic source shows 250 rows, a deadline reached partway leaves the previous report with a visible failure, overlapping runs do not interleave, and the status block shows data age.

It does not redesign the report, build real-time refresh or change permissions on your sheet. This guide is written from vendor documentation read on 11 October 2026 and nothing was run in a live account. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.