Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Automating Multi-Site Infrastructure: GA4 Integration, CloudFront Deployments, and Daemon Health Monitoring

This session involved three major infrastructure initiatives: establishing authenticated Google Analytics 4 API access across multiple properties, deploying static site updates through our S3/CloudFront pipeline, and diagnosing a critical OAuth token degradation in our background orchestrator daemon. Here's what we accomplished and why.

Google Analytics 4 API Authentication & Multi-Property Reporting

The primary goal was to enable programmatic access to GA4 data across multiple domain properties without manual dashboard navigation. We created a Python authentication wrapper that handles OAuth 2.0 token lifecycle management.

Architecture Decision: Rather than embedding credentials in application code, we implemented a centralized token storage pattern in /Users/cb/Documents/repos/tools/auth_ga.py that:

  • Validates existing Google OAuth credentials using the google-auth-oauthlib library
  • Reuses stored client_id and client_secret from a secure credentials file to avoid repeated OAuth flows
  • Supports multiple email accounts (e.g., dangerouscentaur@gmail.com) with separate token storage
  • Exposes GA4 properties and accounts via the Google Analytics Data API v1

We verified the setup by pulling a full 7-day report from 86dfrom.com (a recently reorganized property), confirming that the API client can enumerate all GA4 properties under the authenticated account and retrieve metrics without errors.

Why this matters: GA4 requires OAuth 2.0 authentication; unlike Universal Analytics, there are no simple API keys. By centralizing token management, we avoid credential leakage in logs or version control and enable automated reporting pipelines.

Site Rebranding and SEO Deployment Pipeline

During the session, we discovered that the property directory /Users/cb/Documents/repos/sites/86dfrom.com needed to be renamed to align with the correct domain spelling. This triggered a full redeployment chain.

Steps executed:

  • Directory rename: Moved 86dfrom.com to 86from.com to match the actual domain
  • Content creation: Added a new SEO-focused page at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean to capture long-tail search traffic
  • Index.html updates: Applied multiple revisions to the main index file, including a critical fix for JavaScript template syntax (see below)
  • S3 deployment: Synced updated content to the production S3 bucket for the 86from.com domain
  • CloudFront invalidation: Cleared the CloudFront distribution cache to ensure edge nodes served fresh content immediately

Critical bug fix — Template syntax in booking widget: The index.html contained a third-party booking widget with embedded JavaScript that used double-brace syntax ({{ variable }}) for templating. This conflicted with JavaScript template literals and caused parsing errors in the browser console.

Solution: We identified all double-brace occurrences within the booking widget section (isolated in a marked <div>) and replaced them with single-brace equivalents, then validated the extracted JavaScript block independently. The fix was tagged with a version identifier and model ID in a comment block for future auditing.

// Booking widget version: [model-id] - double-brace syntax corrected
// Ensures compatibility with modern JS engine template evaluation

Why separate staging and production: We deployed the corrected index.html to a staging CloudFront distribution first, validated in a pre-production environment, then pushed to the live production bucket. This pattern prevents syntax errors from reaching end users.

Daemon Health Monitoring: jada-agent Orchestrator

The jada-agent daemon (running on AWS Lightsail instance 34.239.233.28) is responsible for executing complex multi-turn agent sessions, tracking task completion, and syncing data with external services. A comprehensive health check revealed both positive signals and a critical OAuth failure.

Access pattern: Since the SSH private key was not stored locally, we used the AWS Lightsail API to generate temporary SSH credentials on-demand:

# Retrieve temporary access credentials via Lightsail API
# (no SSH key pair required for initial connection)
aws lightsail get-instance-access-details --instance-name [instance-name] --region [region]

# Write temporary cert + private key, then SSH in
ssh -i /tmp/lightsail-temp-key ec2-user@34.239.233.28

Health findings:

  • Service uptime: 3 days continuous; load average ~0.00 (daemon idle between tasks)
  • Resource utilization: CPU 0.65% average, memory 144MB/914MB, disk 17% used — all nominal
  • Session quota: 3 of 5 daily sessions used; two runs hit the 30-turn Claude limit (exit code 1, but non-fatal)
  • Task processing: Session 2 completed successfully, processed e-signature blockers and crew page generation tasks
  • Network health: 0 status check failures in the last 2 hours

Critical issue — OAuth token degradation: The port_sheet_sync.py script (responsible for syncing port sheet data to Google Sheets) has been failing every 30 minutes with:

[port-sheet] token error: HTTP Error 400: Bad Request

The Google OAuth token for this script is expired or revoked. Port sheet syncs have been blocked since at least yesterday afternoon.

Key Decisions & Architectural Patterns

  • Centralized credential management: Storing OAuth tokens in a single, permission-locked secrets directory prevents duplication and reduces the surface area for credential leakage.
  • API-based infrastructure access: Using the Lightsail API to retrieve temporary SSH credentials eliminates the need to store long-lived SSH private keys on local machines.
  • Staging pipeline for static sites: Deploying to a staging CloudFront distribution before production provides a validation layer for syntax errors and content changes.
  • Automated daemon monitoring: Regular health checks via SSH (service status, logs, metrics, process counts) catch issues like token expiration before they impact end users.

What's Next

  • Re-authenticate port_sheet_sync: Regenerate the OAuth token for Google Sheets API access and test the 30-minute sync cycle
  • Optimize agent session limits: Monitor whether the 30-turn limit is consistently being hit on complex tasks; consider increasing if necessary
  • Verify 86from.com SEO page: Confirm that the new content page is crawled by search engines and indexed
  • Audit booking widget across all sites: Check for similar double-brace syntax issues in other properties (sailjada.com, queenofsandiego.com)
```