💡 Platform feature: automation-health-alerter (proactive email alerts for deployed script failures)

[github-actions[bot]]

Summary

A lightweight monitoring script that checks the health of all user-deployed GAS automations and sends a proactive email alert when a script fails, a trigger stops firing, or execution quotas are near exhaustion. Unlike the existing dashboard idea (#145), this operates independently of the deploy page UI — users receive an email the morning after a failure, not when they happen to visit a dashboard.

Market Signal

As no-code automation platforms mature, reliability monitoring is becoming table stakes. Zapier provides built-in error notifications and task history. Make.com offers execution logs with configurable alert rules. n8n includes workflow execution monitoring. Inbox Zero (10.7K GitHub stars) bundles execution health monitoring as a standard feature. The GAS ecosystem has no equivalent — users must manually check the Apps Script execution log, a developer-facing interface hidden behind the Apps Script editor. With Apps Script now a Workspace Core Service (June 2026), enterprise reliability expectations apply. The new API Quota Tiering Model (May 2026) introduces quota-unit-based measurement for Gmail, Calendar, and Drive APIs, adding quota exhaustion as a new failure mode that users need to know about.

User Signal

The project's target users are non-technical individuals who never open the Apps Script editor. If their calendar-to-sheets sync silently stops working — because a trigger was deleted, a quota limit was hit, or an API change caused an error — they won't notice until the data gap becomes obvious, potentially weeks later. The growing script catalog (3 deployed scripts, more in the pipeline) amplifies this: more scripts means more surface area for silent failures. The only existing related idea (#145) is a deploy-page UI dashboard requiring proactive user visits. Zero open issues mention script reliability monitoring.

Technical Opportunity

GAS provides ScriptApp.getProjectTriggers() to enumerate triggers and PropertiesService to store execution state (last-success timestamp, last-error message, run count). The health-check pattern is architecturally simple: on a daily trigger, verify each monitored script's trigger is still registered and its last execution timestamp is within the expected window. MailApp.sendEmail() delivers the alert. The existing config.gs pattern supports per-script monitoring thresholds. The dependency-injection architecture (all GAS services as parameters) makes this fully unit-testable. The Workspace Events API (GA 2026) could enable real-time failure detection as a Phase 2 enhancement.

Assessment

Dimension	Score	Rationale
Feasibility	high	ScriptApp and PropertiesService APIs are mature and well-tested. The alerter script itself is trivially simple (read properties, compare timestamps, send email).
Impact	med	Essential infrastructure as the catalog grows. Prevents silent failures that erode user trust. But only becomes critical at scale (5+ deployed scripts per user).
Urgency	med	No immediate crisis, but every new catalog script added without monitoring increases the risk of undetected failures. The API quota changes (May 2026) add a new failure mode.

Adversarial Review

Strongest objection: GAS scripts can only access their OWN triggers and execution data via ScriptApp. Cross-project monitoring requires the Apps Script API with additional OAuth scopes, significantly complicating the deployment model. Also, who monitors the monitor?

Rebuttal: The pragmatic MVP uses self-monitoring: each catalog script includes a lightweight heartbeat function that writes execution-success timestamps to PropertiesService at the end of each run. A separate "health-alerter" script (deployed from the same catalog) reads a shared state store (e.g., a Sheets-based health log, or Drive-based JSON) and emails a consolidated daily digest. The cross-project concern is eliminated by design — each script reports its own health, the alerter aggregates. The monitor-the-monitor problem is mitigated by the alerter's trivial simplicity (read + email), and GAS's built-in "Trigger execution failed" email (sent by Google to the script owner) serves as the last-resort backstop.

Suggested Next Step

Design the health-check protocol: define the shared state schema ({script_id, last_success_timestamp, last_error, trigger_count, execution_count_24h}) that each catalog script writes after successful execution, and the alerter script reads. Prototype with calendar-to-sheets as the first monitored script. Evaluate Sheets vs. Drive JSON vs. Properties Service as the shared state store.