Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Managing Multi-Site Infrastructure: Daemon Health Monitoring, OAuth Token Lifecycle, and Booking Widget Deployment

This session involved orchestrating updates across multiple properties while maintaining observability into our cloud infrastructure. We debugged a critical daemon health issue, addressed token expiration in automated syncs, and deployed enhanced SEO and booking functionality. Here's the technical breakdown.

Daemon Health Monitoring via AWS Lightsail API

The jada-agent.service orchestrator runs on a Lightsail instance at 34.239.233.28. Rather than relying solely on stored SSH keys, we leveraged the AWS Lightsail API to obtain temporary credentials when the local key pair wasn't readily available.

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

This approach yields a temporary certificate valid for 60 seconds, eliminating the need to store persistent SSH keys in version control. The instance itself showed healthy metrics:

  • Uptime: 11 days; service running since May 10 (3 days continuous)
  • CPU utilization: 0.65% average; no spikes detected in the 2-hour window
  • Memory: 144MB / 914MB (16% utilization)
  • Disk: 6.2GB / 39GB (17% used)
  • Load average: 0.00 — appropriate for an idle polling loop
  • Status checks: 0 failures in last 2 hours

The daemon's session behavior revealed normal operation with expected constraints. Three of five available daily sessions were consumed; two hit the 30-turn Claude limit (exit code 1), while one completed successfully without truncation. After the final session, no pending tasks remained, and the daemon resumed its 60-second polling cycle.

Critical Issue: OAuth Token Expiration in Port Sheet Sync

Logs revealed a recurring failure in the automated Google Sheets sync process:

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

This error appeared in every 30-minute sync attempt since at least the afternoon of May 13. The root cause: the stored Google OAuth token for port_sheet_sync.py had expired or been revoked.

Why this matters: Automated port sheet syncs depend on valid OAuth credentials to write to Google Sheets. When the token becomes invalid, the script fails silently (from the user's perspective) but logs the error. This breaks the automated workflow without triggering an alert to the operator unless logs are actively monitored.

Resolution path: The OAuth refresh flow needs to be re-initiated, which requires either a new authorization grant (interactive login) or a valid refresh token. Since the token was stored in a secure location, we confirmed the structure matched the expected format (client_id and client_secret present) but the token itself had expired. Re-authentication via the auth_ga.py script (which uses google-auth-oauthlib) will be necessary.

Multi-Site Content and SEO Deployment

During this session, we reorganized and deployed content across three separate properties: 86from.com, sailjada.com, and queenofsandiego.com.

86from.com Directory Restructuring

The property was initially located at /Users/cb/Documents/repos/sites/86dfrom.com. To align with the actual domain, we renamed the directory:

mv /Users/cb/Documents/repos/sites/86dfrom.com \
   /Users/cb/Documents/repos/sites/86from.com

A new SEO-focused content page was created at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean, expanding the site's search visibility and addressing user intent queries related to industry terminology.

Deployment to the CDN involved two commands:

aws s3 sync /Users/cb/Documents/repos/sites/86from.com s3://86from-prod \
  --delete

aws cloudfront create-invalidation \
  --distribution-id [DIST_ID] \
  --paths "/*"

The S3 bucket 86from-prod serves as the origin; CloudFront caches and distributes content. Full path invalidation ensures new content reaches edge locations within seconds rather than waiting for cache TTL expiration.

sailjada.com Index Updates

The primary sailjada property received multiple edits to /Users/cb/Documents/repos/sites/sailjada.com/index.html. The volume of edits (16 in this session alone) suggests iterative refinement, likely responsive to testing feedback or analytics insights.

Booking Widget JavaScript Syntax Correction

The booking automation modal in the queen-of-sandiego property required debugging. The initial symptom: template syntax errors in embedded JavaScript.

Problem: Double-brace syntax ({{ }}) was present within a booking widget code block. While double braces are valid in some templating contexts (Jinja2, Handlebars), they conflicted with the JavaScript parser when embedded directly in a <script> tag without proper escaping.

Investigation approach:

  • Counted all double-brace occurrences across the file
  • Determined which ones fell outside the booking widget section (leaving those unchanged)
  • Isolated the problematic block and replaced {{ }} with { } only within the widget JavaScript
  • Syntax-checked the extracted JavaScript block independently to confirm valid JSON and control flow

Deployment: The corrected file was pushed to the staging bucket first:

aws s3 cp /Users/cb/Documents/repos/sites/queenofsandiego.com/index.html \
  s3://queenofsandiego-staging/index.html

aws cloudfront create-invalidation \
  --distribution-id [STAGING_DIST_ID] \
  --paths "/index.html"

This staging-first approach allows for QA validation before production deployment, reducing risk of user-facing errors.

Version Tagging in Booking Widget

To track which version of the booking widget is deployed, we embedded a version identifier in the widget's HTML comment:

<!-- booking-widget v2.1.4 model-id: [MODEL_ID] deployed: 2026-05-13 -->

This allows us to correlate user-reported issues with specific widget versions and correlate timing with CloudFront invalidations or pushes to production.

Key Architectural Decisions

  • Temporary SSH credentials via Lightsail API: Eliminates persistent key management; credentials expire in 60 seconds, reducing blast radius if compromised.
  • Staging bucket for validation: Separates testing from production, allowing QA sign-off before user exposure.
  • Full CloudFront invalidation: Guarantees cache freshness; trade-off is temporary increased origin load during invalidation, acceptable for low-traffic properties.