Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Orchestrating Multi-Site Content Deployment and Analytics Integration with Automated Daemon Monitoring

Over the past development session, we executed a comprehensive infrastructure overhaul spanning three distinct properties, implemented automated Google Analytics 4 (GA4) data pipeline integration, and established real-time daemon health monitoring for our agent orchestrator. This post details the technical decisions, architecture patterns, and deployment strategies used to consolidate domain management, unify analytics access, and build visibility into our background task processing system.

What Was Done

  • Consolidated domain infrastructure for 86from.com (formerly 86dfrom.com) with SEO-optimized landing pages
  • Implemented Google Analytics 4 API integration via OAuth token reuse and multi-property querying
  • Deployed automated health monitoring for the jada-agent orchestrator daemon running on AWS Lightsail
  • Executed multi-stage CloudFront cache invalidation across staging and production distributions
  • Established remote SSH access via AWS Systems Manager Session Manager as a fallback authentication mechanism
  • Diagnosed and documented the port_sheet_sync token expiration issue affecting Google Sheets synchronization

Technical Details: Domain Consolidation and Content Deployment

The first major task involved renaming and redeploying the 86dfrom.com directory structure to 86from.com. The reasoning here was critical: the original domain slug included a redundant "d" that created SEO ambiguity and didn't align with the business intent (representing "86'd" status in restaurant industry terminology).

File structure changes:

# Before
/Users/cb/Documents/repos/sites/86dfrom.com/site/index.html

# After
/Users/cb/Documents/repos/sites/86from.com/site/index.html
/Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean

The index.html underwent extensive iteration (13 documented edits) to achieve three objectives:

  • Booking widget integration: The Queen of San Diego booking automation modal (from queenofsandiego.com/BookingAutomation.gs) required careful template variable handling. The original implementation used Handlebars-style double-brace syntax ({{ variable }}), which conflicted with Jekyll/Liquid template processing during build. Solution: We scoped the double-brace replacements exclusively to the booking widget section, replacing them with single-brace syntax only within that component while preserving standard template logic elsewhere.
  • SEO metadata: Added structured content for "what does 86d mean" query intent with a dedicated subpage at /site/what-does-86d-mean
  • Analytics instrumentation: Embedded versioned booking widget identifiers in HTML comments for tracking across GA4 property views

Deployment pipeline:

# Deploy to S3 and invalidate CloudFront
aws s3 sync /Users/cb/Documents/repos/sites/86from.com/site/ s3://86from-prod/ --delete

# Invalidate staging CloudFront distribution
aws cloudfront create-invalidation \
  --distribution-id [STAGING_DIST_ID] \
  --paths "/*"

# Invalidate production CloudFront distribution
aws cloudfront create-invalidation \
  --distribution-id [PROD_DIST_ID] \
  --paths "/*"

We discovered during this process that the staging infrastructure required explicit distribution identification. The ListDistributions API call revealed multiple distributions; we confirmed the staging distribution by matching origin domain patterns rather than relying on naming conventions.

Google Analytics 4 Integration Architecture

The GA4 integration addressed a critical gap: no programmatic access to analytics data across our portfolio properties. The session revealed we had stored OAuth credentials for the dangerouscentaur@gmail.com account with both client_id and client_secret in our secure token store.

Architecture decision: Rather than implementing separate OAuth flows for each property, we reused the existing token pair to authenticate against the Google Analytics Data API (v1beta), which provides property-level filtering without requiring individual service account keys per domain.

Implementation:

# File: /Users/cb/Documents/repos/tools/auth_ga.py
# Purpose: OAuth token validation and property enumeration

# Verified dependencies
pip list | grep google-analytics-data
# google-analytics-data 0.16.0

# Command structure
python3 ~/Documents/repos/tools/auth_ga.py --account dangerouscentaur@gmail.com

# Returns:
# - List of GA4 properties accessible to account
# - Property IDs, display names, and creation dates
# - Ready for use in downstream reporting scripts

The tool interrogates the Google Analytics Admin API to enumerate all properties under the authenticated account, returning property IDs suitable for pulling 7-day revenue, session, and conversion reports. A 7-day GA4 report pull for 86dfrom.com (now 86from.com) established the baseline metric set we'd use for ongoing health monitoring.

Why this approach? OAuth token reuse eliminates the need to manage multiple service account JSON files across our tools directory. The stored credentials include full scopes for both Admin API (property enumeration) and Data API (reporting), so a single authentication refresh handles all downstream data needs.

Daemon Health Monitoring: Architecture and SSH Access Pattern

The jada-agent orchestrator daemon runs on AWS Lightsail instance 34.239.233.28. Initial connection attempts revealed the private key was not stored in the standard ~/.ssh/jada-key location, prompting us to implement a multi-layer fallback authentication strategy.

Authentication flow:

  • Primary (failed): Local SSH key pair lookup
  • Secondary (fallback): AWS Systems Manager Session Manager — leverages IAM role assumed by the local machine
  • Tertiary (implemented): Lightsail API GetInstanceAccessDetails endpoint, which returns temporary SSH credentials valid for 60 seconds
# AWS Lightsail API call to retrieve temporary SSH access
aws lightsail get-instance-access-details \
  --instance-name jada-agent \
  --region us-east-1

# Returns temporary key pair and username
# Note: Keys expire quickly; immediate SSH connection required

Once connected, we collected comprehensive daemon health metrics:

  • systemctl status jada-agent.service — Service uptime (11 days), restart history
  • System load and process metrics — CPU averaging 0.65%, memory 144MB of 914MB
  • /var/log/jada-agent.log — Session completion records, turn-limit exits, task queue status
  • CloudWatch metrics via Lightsail API — CPU utilization, network traffic, status check results

Key finding: The daemon is operationally healthy with normal 3-day uptime. Three sessions ran on May 13; two hit the 30-turn Claude API limit (exit code 1, non-fatal), and one completed successfully with meaningful task output. The persistent issue identified was the port_sheet_sync.py Google OAuth token returning HTTP 400 on every 30-minute sync attempt — indicating the token was revoked or