Minute Triggers in GAS: Runtime Budgets and Overlap Prevention
TECH INSIGHT / EXPLAINED
A 54-second loop inside a minute trigger can look almost continuous. Its practical constraints are daily runtime and overlapping executions, more than the six-minute per-run limit. Decide the required observation frequency before filling the available time.
Calculate the daily cost of 54 seconds
Across a hypothetical 390-minute trading session, 54 seconds per minute consumes 21,060 seconds: 351 minutes, or 5.85 hours. The official September 2026 trigger budgets are 90 minutes per day for consumer accounts and six hours for Google Workspace. The latter leaves only nine of 360 minutes after this loop. Off-session checks, other scripts, and slow API calls make that a thin operating margin.
Reducing each run to 20 seconds still consumes 130 minutes across 390 runs, exceeding the consumer budget. Five seconds consumes 32.5 minutes. Start with short jobs that finish after doing useful work. Sleeping does not make elapsed execution time free. Running a 54-second loop every minute for an entire day would consume 21.6 hours.
Six seconds of slack does not prevent overlap
Triggers are not a precise real-time scheduler. API latency and start-time variation prevent guarantees of exactly six idle seconds per minute or exactly one iteration per second. Comparing the current seconds field can suppress rapid repetitions, but slow work skips seconds.
Control overlap separately with an inter-execution lock such as LockService. Skip a cycle and record the reason if the lock cannot be acquired. A script-wide lock can serialize all users, so choose scope to match per-user jobs or a shared scheduler. A lock alone does not provide exactly-once external orders.
Separate intent, installation, and health
- Desired state: has the user enabled this job?
- Installation state: does the intended creator-owned trigger exist?
- Health: when did the job last succeed, and what was its last error?
A saved trigger ID proves only that a value was stored previously. It does not prove successful execution. Reconcile trigger records under a lock before creating a missing trigger. Do not assume Session always returns an email; inspect authorization and deployment mode. Installable triggers execute as their creator.
Stop the intended job
Disable the desired state first, then delete triggers matching the recorded ID and handler. Inspect ownership and handler names when cleaning up duplicates from older versions. Deleting all project triggers can remove backups and notifications too. Trigger listings are scoped to the current user's triggers.
Deleting a trigger does not cancel its already running function. Recheck enabled state before new external actions. Distinguish stop requested, trigger cleanup complete, and last execution finished, so the UI does not declare success prematurely.
Make interruption recoverable
Assume execution can end after an external order succeeds but before its result is recorded. Persist an intent ID, processing stage, and external order ID. Resolve unknown orders first on the next run. Do not depend on cleanup always completing after a timeout or network failure.
Evaluate holidays and trading hours using a verified calendar and the exchange timezone. Expose stale last-success timestamps in the UI and an independent monitoring path; review execution history and trigger failure notifications. If continuous second-level response is essential, choose a runtime that supports that requirement.
GAS backend execution budgets and authorization boundaries
References
Content and examples reviewed: 2026-09-29
댓글
댓글 쓰기