Building a Distributed Task Notification System for maintenance.queenofsandiego.com

```html

The maintenance tool at maintenance.queenofsandiego.com needed a critical capability: surfacing newly added tasks to the operations team and notifying stakeholders in real-time or via digest. This post details the architecture, implementation strategy, and infrastructure changes deployed to handle task notifications with intelligence around task criticality and team communication preferences.

The Problem: Task Visibility and Notification

When Travis added tasks to the maintenance system via SMS or the web interface, there was no automated way for the operations team (particularly Sergio) to become aware of these additions. The system needed to:

Detect when new maintenance tasks are added to the system
Route notifications based on task criticality and severity
Support both real-time alerts and batched digest notifications
Maintain staging/production separation for the maintenance tool
Integrate with Google Calendar for operator awareness

Industry research on high-performing operations teams (referenced in incident response literature from PagerDuty and Opsgenie) shows that criticality-driven notification pacing reduces alert fatigue while ensuring urgent issues surface immediately. This informed our architectural decision to implement tiered notifications.

Technical Architecture: Four-Layer Implementation

Layer 1: Persistence and State Management

We created MaintenancePersistence.gs as a new Google Apps Script file in the queenofsandiego.com project. This file serves as the single source of truth for maintenance task state and notification history:

// File: /Users/cb/Documents/repos/sites/queenofsandiego.com/MaintenancePersistence.gs
// Handles:
// - Task metadata caching in PropertiesService
// - Last notification timestamp tracking
// - Notification state machine (pending/sent/digested)
// - CloudSQL integration for historical records

This layer uses Google Apps Script's PropertiesService for sub-second state lookups and integrates with CloudSQL for audit trails and historical analysis.

Layer 2: Task Detection and Event Routing

We modified BookingAutomation.gs to include maintenance-specific action routing in its doPost handler:

// In BookingAutomation.gs doPost handler
switch(action) {
  case 'log_maintenance':
    return handleMaintenanceTask(request);
  // ... existing cases
}

The log_maintenance action now triggers a notification evaluation pipeline that checks:

Task criticality level (critical/high/medium/low)
Last notification sent timestamp
Digest window configuration
Recipient notification preferences

Layer 3: Lambda-Based Notification Service

Following existing Lambda deployment patterns in the infrastructure (referencing the tips-box Lambda configuration for IAM role and runtime specifications), we deployed a new Lambda function for notification orchestration. This function:

Subscribes to SNS notifications from the GAS layer
Applies batching logic for non-critical tasks (digest mode)
Sends immediate emails for critical/high-severity tasks
Creates or updates calendar events in the "Jada Maintenance" calendar

The Lambda function integrates with AWS SES for email delivery and Google Calendar API for event management.

Layer 4: Frontend Task Visibility

We updated the staging maintenance HTML interface at /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/maintenance/staging-index.html with:

Task notification status indicators (pending, sent, acknowledged)
Notification history sidebar showing who was notified and when
Criticality badges on task cards for quick visual scanning
Real-time update via Server-Sent Events (SSE) to maintenance.queenofsandiego.com

Infrastructure and Deployment Details

S3 and CloudFront Configuration

The staging maintenance tool is deployed to an S3 bucket with CloudFront distribution. We performed the following configuration steps:

// Staging HTML deployed to S3 maintenance bucket
s3 cp staging-index.html s3://maintenance-staging-bucket/index.html

// Invalidate CloudFront cache post-deployment
aws cloudfront create-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --paths "/index.html" "/assets/*"

The staging environment is isolated from production by using a separate S3 bucket and CloudFront distribution, with email notifications routed to jadasailing@gmail.com for testing purposes.

Google Apps Script Project Structure

Files modified in the queenofsandiego.com GAS project:

MaintenancePersistence.gs (new) - Task state and notification history
MaintenanceCalendar.gs (new) - Google Calendar event creation and updates
BookingAutomation.gs (modified) - Route log_maintenance actions to notification handler
Code.gs - Base project configuration (existing)

Deployment used clasp push after resolving file tracking issues. The MaintenancePersistence.gs file required explicit tracking before successful deployment.

Calendar Integration

We implemented automatic calendar event creation in the "Jada Maintenance" Google Calendar. The MaintenanceCalendar.gs file handles:

Creating all-day events for new maintenance tasks (critical/high severity)
Updating existing events when task status changes
Setting event descriptions with task details and assigned personnel
Using CalendarApp API for event management within the GAS environment

Notification Strategy: Data-Driven Tiering

Our notification model uses criticality-based routing, informed by incident response best practices:

Critical tasks: Immediate SMS + email to on-call personnel + calendar event
High severity: Immediate email + calendar event
Medium severity: End-of-day digest (8 PM) + calendar event
Low severity: Weekly digest (Sunday 6 PM) + calendar event

This approach prevents alert fatigue while ensuring operational awareness. Historical data from high-performing SRE teams shows that fewer, more contextual notifications increase team response velocity compared to constant low-priority alerts.

Testing and Staging Strategy

All notifications during testing and staging send to jadasailing@gmail.com. The staging HTML is isolated at a staging subdomain with its own CloudFront distribution and S3 bucket, preventing cross-contamination with production data.

To test the notification system:

// Add a task via the staging interface
// Monitor jadasailing@gmail.com for notification arrival
// Check "Jada Maintenance" calendar for event creation
// Verify notification state in MaintenancePersistence logs

What's Next

The