💡 Automation pause/resume controls in deploy page (vacation mode)

[github-actions[bot]]

Summary

Add pause and resume buttons to the deploy page for each deployed script, allowing users to temporarily disable their automations without navigating the Apps Script editor. Includes an optional "auto-resume" date picker for vacation mode — pause now, automatically resume when you return. This closes the management gap that currently forces non-technical users back to the Apps Script editor for basic lifecycle control, completing the deploy page's promise of a "zero-to-running journey in one page" with a return path for ongoing management.

Market Signal

Every automation platform (Zapier, Make, IFTTT) provides one-click pause/resume as a basic management primitive — it's considered table stakes, not a feature. Apps Script became a Core Service in June 2026, which improves API reliability for trigger management operations and signals Google's commitment to GAS as enterprise infrastructure. The Workspace trend toward autonomous AI agents (Gemini Spark, announced I/O 2026) makes human-controlled pause/resume even more important as a safety mechanism — as automations become more powerful and always-on, users need an easy, accessible kill switch. The vacation mode pattern is well-established: Gmail vacation responder, Slack "away" status, Zapier's "pause all Zaps" feature.

User Signal

The deploy page's value proposition is "complete zero-to-running journey in one page," but the journey currently has no return path for lifecycle management. The PRD's Journey 2 (Morgan returns to edit config six weeks later) shows users coming back — they'd naturally expect pause/resume alongside edit. Discussion #145 tracks a deployed-script status dashboard, signaling recognized demand for post-deployment management capabilities. Currently, pausing a script requires: opening script.google.com → finding the project → navigating to Triggers → deleting the trigger → and then recreating it later. This is exactly the kind of technical friction the deploy page was built to eliminate.

Technical Opportunity

The deploy page already stores project IDs in localStorage (gas_copilot_deployed key) and has OAuth access to the Apps Script API. The Triggers API (projects.triggers.list / .delete / .create) supports full trigger lifecycle management. The implementation pattern: Pause = call triggers.list to find the active trigger, store its config in localStorage, then call triggers.delete. Resume = call triggers.create with the stored config. The SCRIPT_CATALOG already records each script's triggerFn (e.g., storeEmailsAndAttachments, syncAllCalendarsToSheetsGAS), which is the key parameter for trigger creation. For auto-resume, the script's own PropertiesService can store a "resume after" ISO date that a lightweight watchdog trigger checks.

Assessment

Dimension	Score	Rationale
Feasibility	high	Triggers API is well-documented; implementation is 2 API calls (list + delete for pause, create for resume); deploy page already has the required OAuth access and project metadata
Impact	med	Completes the lifecycle management story; builds trust with non-technical users who need to feel in control of their automations; enables vacation mode — a recognized productivity pattern
Urgency	med	Not blocking any user flow today, but becomes more important as users deploy multiple scripts and as the project targets broader adoption

Adversarial Review

Strongest objection: Users rarely need to pause automations. The GAS trigger runs in the background with no cost. And "auto-resume" requires the user to revisit the deploy page on the resume date — if they forget to open the page, the automation stays paused indefinitely.

Rebuttal: Pause is about trust and control, not frequency. The PRD's target user (non-technical, "never opened a terminal") needs to feel in control of their automations. Without pause, the only options are "running forever" or "delete and re-deploy from scratch." Vacation mode is a recognized UX pattern (Gmail vacation responder, Slack status). For auto-resume, the script itself can be enhanced to check a "resume after" date in PropertiesService — no deploy page revisit needed. A lightweight watchdog trigger (running daily) checks whether the resume date has passed and recreates the main trigger automatically. The implementation cost is minimal (2 API calls for basic pause/resume) with outsized trust and control benefit.

Suggested Next Step

Add "Pause" and "Resume" buttons to each deployed script card in the deploy page's returning-user view. Pause: call projects.triggers.list → find active trigger → store trigger config in localStorage → call projects.triggers.delete. Resume: call projects.triggers.create with stored config (function name from SCRIPT_CATALOG.triggerFn, type: CLOCK, everyMinutes from stored config). Phase 2: add optional "Auto-resume on" date picker that writes to PropertiesService for the watchdog to check.