Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Managing Multi-Site Infrastructure: Daemon Health Monitoring, OAuth Token Lifecycle, and GA4 Analytics Integration

This session focused on three parallel infrastructure concerns: validating the health of a long-running orchestrator daemon, diagnosing a broken OAuth token sync pipeline, and establishing GA4 analytics infrastructure for multiple properties. Here's what we learned and how we fixed it.

Daemon Health Verification via AWS Lightsail

The jada-agent.service orchestrator running on a Lightsail instance (34.239.233.28) required verification after several days of operation. Since the SSH private key wasn't stored locally in ~/.ssh/jada-key, we used AWS Lightsail's temporary credential API rather than storing persistent keys on the development machine.

Approach: Instead of hunting for a stored key, we leveraged the Lightsail API to generate temporary SSH access credentials:

aws lightsail get-instance-access-details \
  --instance-name jada-orchestrator \
  --region us-east-1

This returns a temporary certificate valid for 60 minutes, reducing credential sprawl. The alternative—AWS Systems Manager Session Manager—would have worked but requires additional IAM role configuration; the temporary cert approach is lighter for one-off diagnostics.

Key findings:

  • Service uptime: 3 days (since May 10), with no crashes or restarts
  • Resource usage: CPU ~0.65% average during polling (normal), memory 144MB/914MB, disk 6.2GB/39GB. No thermal or resource exhaustion issues.
  • Task completion: 3 sessions used of 5 available today. Session 1 and 3 hit the 30-turn Claude API limit (exit code 1, logged as error but non-fatal). Session 2 completed successfully and generated a task to address e-signature blockers.
  • Load pattern: The daemon polls a progress dashboard every 60 seconds, picks up new tasks, and spawns Claude sessions. Between tasks, the instance idles at 0.00 load average—expected behavior.

The daemon itself is healthy. The 30-turn exits aren't crashes; they're a symptom of task complexity. If this becomes a bottleneck, task scope decomposition or turn-limit adjustment would be the fix.

Diagnosing the Broken OAuth Token Sync

The port_sheet_sync.py script, which syncs port/crew data to a Google Sheet every 30 minutes, has been failing since at least May 13 afternoon with a consistent error:

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

Root cause: The stored Google OAuth token for that service account has expired or been revoked. OAuth refresh tokens have a lifetime; if unused for extended periods or if Google security policies rotated them, they become invalid.

Why this matters: The sync pipeline is part of the operational data flow. Without it, crew and port schedules aren't updated in the source-of-truth sheet, creating data staleness downstream.

Resolution approach: The script needs to be re-authenticated to Google. This involves:

  • Running the auth flow script (e.g., auth_ga.py or a similar OAuth initializer for Google Sheets API) with the service account or user credentials that own the target sheet
  • Storing the refreshed token back in the secrets/credentials directory (e.g., /Users/cb/Documents/repos/tools/)
  • Restarting the sync service or relying on the daemon to pick up the new token on next execution

The auth script in this codebase uses google-auth-oauthlib to handle the OAuth2 flow. Once re-authenticated, the token will be valid for another extended period, eliminating the 400 errors.

GA4 Analytics Integration for Multi-Property Setup

During this session, we established GA4 reporting infrastructure for multiple properties under the dangerouscentaur Google account:

  • Primary account: dangerouscentaur@gmail.com
  • Properties identified: 86dfrom.com (later renamed to 86from.com), sailjada.com, and others

Key decision: Reusing existing credentials. Rather than creating new service accounts for each property, we leveraged the existing OAuth token (client_id and client_secret) already stored in the jada credentials for the dangerouscentaur account. This reduces operational overhead and keeps secrets management centralized.

GA4 Data API queries: Using the Python google-analytics-data library, we pulled 7-day reports for properties with commands like:

from google.analytics.data_v1beta import BetaAnalyticsDataClient
# Query dimensions: date, country, device; metrics: sessions, conversions
# Run for property 86dfrom with date range 2026-05-06 to 2026-05-13

This provides programmatic access to session counts, conversion rates, traffic sources, and device breakdowns without manual dashboard navigation—critical for automation and alerting.

Site Migration and Deployment

The 86dfrom.com directory was renamed to 86from.com to match the actual domain. This involved:

  • Renaming the local directory: /Users/cb/Documents/repos/sites/86dfrom.com/ → /Users/cb/Documents/repos/sites/86from.com/
  • Creating a new SEO-focused page at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean to capture search traffic
  • Deploying the index.html to S3 (main bucket) with CloudFront invalidation to ensure cache bypass
  • Also deploying to a staging S3 bucket for QA before production release

Booking widget issue: The index.html contained a booking widget with template syntax (double braces `{{ }}`) that was conflicting with HTML. We identified that the template delimiters appeared only inside the booking widget JavaScript block, not in the main HTML, so we safely replaced them with single braces to resolve the parsing conflict. The widget was verified syntax-correct after the fix.

Infrastructure Decisions and Patterns

  • Temporary credentials over persistent keys: Using Lightsail's temporary cert API for SSH access reduces the attack surface of stored private keys.
  • Centralized OAuth token management: Reusing a single set of Google OAuth credentials (client_id/secret) for all properties under the same account simplifies credential rotation and audit trails.
  • Staging + production deployments: Multiple S3 buckets with separate CloudFront distributions allow testing before live release, reducing rollback risk.
  • Service health via CloudWatch metrics: CPU, memory, disk, and status checks were pulled from Lightsail's metrics API, enabling data-driven diagnosis without ad-hoc polling.

What's Next

Re-authenticate the port_sheet_sync Google OAuth token to resume the 30-minute sync cycle. Monitor the daemon's 30-turn exits; if tasks consistently hit the limit,