Two similar executions can come from duplicate trigger installations, different creators, or repeated event handling. Inspect the execution path before deleting triggers broadly.
Inventory the relevant triggers
Check the script project’s trigger list, function names, event types, and execution times. Look for a simple handler plus an installable trigger calling the same processing logic.
Google notes that one account cannot see triggers installed by another account, even when both can activate them. Ask the appropriate authorized owners to review their installations rather than concluding that one visible trigger proves there is only one.
Separate concurrency from duplicate work
A suitable LockService lock can prevent overlapping executions of a protected code section. The lock is only acquired after tryLock or waitLock; obtaining a lock object alone does not acquire it.
A lock does not by itself stop a second execution from repeating already completed work afterward. Use a durable record or event key and a reviewed processed-state check when operations must be idempotent.
Test safe replay behavior
In a controlled copy, process the same sample twice and verify that the second run does not append another record or send another notification. Test interrupted processing and the resulting recovery state.
Remove only a confirmed redundant installation, preserving the required owner and schedule. Reconcile uncertain external side effects before retrying them; a lock or an execution-success entry is not proof of exactly-once delivery. Keep safe run identifiers and counts so future duplicate symptoms can be traced without logging private source rows or exposing credentials.
References
- Installable Triggers | Apps Script | Google for Developers
- Class LockService | Apps Script | Google for Developers
Reviewed against the linked official product guidance on November 3, 2026. Features, limits, screen labels, and access can vary by account, platform, region, and organization policy.