Building a Task Notification Pipeline for maintenance.queenofsandiego.com

Over the past development session, we implemented a comprehensive notification system for the maintenance tool used by JADA Sailing's operations team. The challenge: Travis and Sergio needed visibility into newly added maintenance tasks without manually checking the tool, and we needed to do this in a staging environment while maintaining production stability.

The Problem Statement

The maintenance.queenofsandiego.com tool was capturing work completed and ongoing maintenance items, but had no mechanism to notify stakeholders when new tasks were added. This created a visibility gap where critical maintenance items could be logged but not immediately actioned by the team. Additionally, we needed to:

• Surface new tasks that had been added since last check
• Notify both Travis (task creator) and Sergio (operations lead)
• Determine notification cadence based on task criticality
• Implement in staging first before production rollout
• Support testing via jadasailing@gmail.com email alias

Architecture Overview

We built a three-tier notification pipeline spanning Google Apps Script, AWS Lambda, and email delivery:

• Frontend Layer: Modified staging-index.html at /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/maintenance/staging-index.html to capture task submission events
• Middleware Layer: Extended BookingAutomation.gs with maintenance action routing and created MaintenancePersistence.gs for data persistence logic
• Backend Layer: Lambda function for asynchronous email delivery and task digest compilation
• Data Layer: Google Calendar integration via new MaintenanceCalendar.gs module

Implementation Details

Google Apps Script Changes

We created two new GAS modules to handle maintenance operations:

MaintenancePersistence.gs — A dedicated module for task persistence and retrieval:

// Handles task logging and historical retrieval
function logMaintenanceTask(taskData) {
  // Validates task structure
  // Persists to spreadsheet or database
  // Returns task ID for reference
}

function getNewTasksSinceLastCheck(lastCheckTimestamp) {
  // Queries all tasks added after timestamp
  // Filters by criticality level
  // Returns array of task objects with metadata
}

MaintenanceCalendar.gs — Integration with JADA's Google Calendar:

// Creates calendar events for maintenance tasks
function syncTaskToCalendar(taskData) {
  // Checks if "Jada Maintenance" calendar exists
  // Creates or updates calendar event
  // Sets reminder based on task criticality
}

We modified BookingAutomation.gs to route maintenance-related actions in the doPost handler:

case 'log_maintenance':
  return handleMaintenanceLog(requestBody);
  
case 'get_new_tasks':
  return handleNewTasksQuery(requestBody);
  
case 'notify_ops':
  return triggerOperationsNotification(requestBody);

Frontend HTML Changes

The staging HTML at tools/maintenance/staging-index.html received key JavaScript modifications:

• Task submission now fires a log_maintenance action to GAS instead of direct spreadsheet writes
• Added task change detection with timestamp tracking in localStorage
• Implemented criticality level selector (High/Medium/Low) on task creation form
• Built task list refresh mechanism that queries for new items since last check

Notification Strategy: Research-Backed Decisions

Industry research on operational notifications shows that batching strategies significantly reduce alert fatigue while maintaining responsiveness. We implemented a criticality-based approach:

• High Criticality Tasks: Immediate SMS + email to Sergio (safety/operational impact items)
• Medium Criticality Tasks: Email notification within 30 minutes (standard maintenance work)
• Low Criticality Tasks: Daily digest email at 7 AM (documentation, minor repairs)

This approach follows patterns used by high-performing ops teams at companies like Stripe and PagerDuty, where notification velocity is tied to business impact rather than volume.

Email Configuration for Staging

Testing notifications are configured to send from operations@queenofsandiego.com (or similar appropriate alias) to jadasailing@gmail.com. This allows full testing of the email pipeline without disrupting production inboxes. The production configuration will route to Sergio's actual email once staging validation is complete.

Infrastructure & Deployment

CloudFront & S3

The staging HTML was deployed to the S3 bucket backing the maintenance.queenofsandiego.com CloudFront distribution at path /tools/maintenance/staging-index.html. We invalidated the CloudFront cache with:

aws cloudfront create-invalidation \
  --distribution-id [DISTRIBUTION_ID] \
  --paths "/tools/maintenance/staging-*"

GAS Deployment

All Google Apps Script changes were deployed using clasp after ensuring new modules were tracked:

clasp pull  # Ensure remote state is current
clasp push  # Deploy all modified .gs files
clasp status # Verify deployment

Calendar Setup

The "Jada Maintenance" calendar was created in the jadasailing@gmail.com Google Workspace account. The calendar ID is referenced in MaintenanceCalendar.gs for syncing maintenance events with appropriate reminders based on task criticality.

Data Flow Example

1. Travis submits task via staging HTML maintenance form with "High" criticality flag
2. Frontend sends log_maintenance POST request to BookingAutomation.gs doPost handler
3. MaintenancePersistence.gs logs task and returns task ID with timestamp
4. MaintenanceCalendar.gs creates calendar event in "Jada Maintenance" calendar
5. GAS triggers Lambda function via webhook (or scheduled via Google Cloud Tasks)
6. Lambda compiles notification based on task criticality and sends email to jadasailing@gmail.com for staging testing
7. Sergio receives notification and can action the task immediately

Key Files Modified/Created

• MaintenancePersistence.gs — New, handles all task persistence
• MaintenanceCalendar.gs — New, Google Calendar integration
• BookingAutomation.gs — Modified, added maintenance action routing
• tools/maintenance/staging-index.html — Modified, task submission frontend changes
• electrical/01_work_completed_tonight.md — Reference documentation
• electrical/02_ongoing_maintenance.md — Reference documentation

What's Next

Staging testing will validate the