Google Apps Script Backend: Execution Budgets and Operating Boundaries
TECH INSIGHT / EXPLAINED
Before building an order engine, build a small backend that reads prices periodically and keeps configuration. Google Apps Script lowers the cost of that experiment. A scheduled job, however, has a different operating model from a continuously running server.
Original screenshots and product images
The screenshots and product images from the original post are retained here alongside the explanation.
Separate three responsibilities
A web app handles configuration requests, a time-driven trigger performs short periodic work, and Properties Service keeps small settings and progress markers. Connect read-only prices and status first. Add orders only after authentication, duplicate prevention, and recovery have been verified.
Record whether the web app executes as its deployer or the accessing user. Installable triggers run with their creator's authorization. User Properties therefore do not automatically form a customer-specific store. A shared deployment needs a server-side mapping between authenticated users and the data they own.
Calculate a daily execution budget
The official quotas checked in September 2026 list a six-minute limit per ordinary script execution for both consumer and Google Workspace accounts. Their daily trigger runtime budgets are 90 minutes and six hours respectively. Account conditions and quotas can change; check the official table before deploying.
A five-second job executed once per minute during a hypothetical 390-minute session consumes 1,950 seconds, or 32.5 minutes. Running it 1,440 times across a full day consumes 120 minutes, exceeding the consumer account's 90-minute budget. Short individual runs do not establish that continuous daily operation is feasible.
Two price requests and one balance request per run make 1,170 baseline requests over 390 runs. Add token refreshes, retries, and other scripts' usage. The broker's limits apply independently of Apps Script quotas.
Treat start and stop as state transitions
- Authenticate start requests and serialize duplicate starts with LockService. Check whether the intended trigger actually exists before creating one.
- Keep its ID, handler name, and enabled state together. A stored ID does not prove that recent executions succeeded.
- When stopping, disable the bot first and delete only its own trigger. Deleting every project trigger also stops unrelated work.
- A running job should recheck the enabled state immediately before a new order. Deleting a trigger neither cancels an execution already in progress nor closes existing positions.
Check the API boundary
doPost is only an entry point. Validate allowed actions, body size, JSON structure, and user authorization; distinguish saving settings from starting work. Knowing the deployment URL must not grant control. Test login, redirects, and cross-origin behavior in the actual browser. Automatic redirect following alone does not prove the integration works.
Refresh access tokens using the provider's expiry information, not whether they were issued today. Use a safety margin before expiry and a lock to prevent simultaneous refreshes. Check HTTP status and response fields, and keep token values out of logs.
Expose operational health
Display the last successful run, last error, and last processed item separately from the enabled switch. Review Apps Script execution history and installable-trigger failure notifications. Stale prices or failed authentication should prevent new orders while leaving enough information for an operator to investigate. Consider another runtime when second-level response deadlines or continuous connections are essential.
Execution budgets and duplicate prevention for minute triggers
References
Content and examples reviewed: 2026-09-29
댓글
댓글 쓰기