Orchestrating Multi-Site CI/CD Deployments with Google Analytics Integration and Remote Daemon Health Monitoring

```html

This session involved coordinating deployments across three distinct properties (86from.com, sailjada.com, and queenofsandiego.com), implementing Google Analytics 4 data pipeline authentication, and diagnosing a remote orchestrator daemon's health on AWS Lightsail. The work demonstrates patterns for managing distributed site deployments, OAuth token management at scale, and operational observability in headless daemon environments.

Multi-Property Site Deployment Pipeline

The session began with a significant directory restructuring and SEO content deployment. The directory /Users/cb/Documents/repos/sites/86dfrom.com was renamed to 86from.com to align with DNS records and S3 bucket naming conventions. This change required careful coordination with CloudFront distribution invalidation to ensure cache coherence across the CDN.

S3 deployment flow: Modified /Users/cb/Documents/repos/sites/86from.com/site/index.html and created a new SEO-focused page at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean. Both files were deployed to the production S3 bucket with subsequent CloudFront cache invalidation.
Why separate SEO pages: Rather than bloating the main index with keyword-targeted content, creating discrete content pages allows for cleaner HTML structure, better semantic markup, and independent caching strategies. Each page can have its own meta tags and OpenGraph properties without compromising the main landing page experience.
Staging validation: The booking widget embedded in the HTML was initially failing to parse due to malformed template syntax. Double-brace delimiters ({{ and }}) were appearing both inside and outside the booking widget's JavaScript block, causing the JavaScript parser to fail. A surgical find-and-replace operation replaced the erroneous braces within the widget section while preserving legitimate template syntax elsewhere in the document.

The sailjada.com property received extensive HTML edits—16 separate modifications to /Users/cb/Documents/repos/sites/sailjada.com/index.html—suggesting iterative refinement of layout, styling, or embedded functionality. The queenofsandiego.com site had two modifications to /Users/cb/Documents/repos/sites/queenofsandiego.com/BookingAutomation.gs, indicating Google Apps Script adjustments to the booking automation system.

Google Analytics 4 Authentication and Data Pipeline

A critical component of this session was establishing authenticated access to GA4 reporting for the dangerouscentaur account. This required implementing OAuth 2.0 credential reuse across multiple properties and data export pipelines.

Tool creation: A new authentication utility was created at /Users/cb/Documents/repos/tools/auth_ga.py. This script encapsulates the OAuth 2.0 flow for Google Analytics Data API access, allowing subsequent tools to query property data without re-prompting for authentication.
Credential reuse pattern: Rather than storing separate client IDs and secrets for each site's analytics integration, the session verified that existing client_id and client_secret stored in the jada service account could be reused. This reduces credential sprawl and simplifies rotation procedures across the infrastructure.
Dependency verification: The google-auth-oauthlib library was confirmed installed and ready. This library handles the OAuth consent flow and token refresh automatically, reducing the likelihood of token expiration errors in production.
Why GA4 integration: Legacy Universal Analytics is being sunset. Migrating to GA4 Data API enables programmatic access to reporting data, unlocking possibilities for automated reporting dashboards, anomaly detection, and integration with booking/revenue systems that may be tracked separately.

A 7-day report was pulled from the GA4 property associated with 86dfrom.com to validate the authentication pipeline and confirm data availability. This establishes the foundation for downstream analytics automation tasks.

Remote Daemon Health Diagnostics and Infrastructure Observability

The jada-agent orchestrator daemon running on AWS Lightsail instance 34.239.233.28 was subjected to comprehensive health diagnostics. This required overcoming initial SSH key discovery challenges and implementing a multi-layered approach to system observability.

SSH access strategy: The local private key at ~/.ssh/jada-key was not available on the development machine. Rather than blocking on key retrieval, the session pivoted to AWS Systems Manager Session Manager (SSM) and the Lightsail API's temporary key generation endpoint. This demonstrates a defense-in-depth access pattern: when primary authentication fails, secondary mechanisms (temporary credentials via IAM) provide fallback access without compromising security.
Metrics collection: CPU utilization, network traffic, and status check metrics were retrieved via the Lightsail API (not CloudWatch—Lightsail has its own metrics endpoint). The instance showed healthy baselines: 0.65% average CPU, 144MB of 914MB memory in use, and 0 status check failures in the monitoring window. Load average near 0.00 indicated the daemon was idling between task scheduling cycles.
Service diagnostics: The jada-agent.service systemd unit was confirmed running with 11 days of continuous uptime. Service logs revealed a recurring pattern: two of three session runs today hit Claude's 30-turn conversation limit, causing them to exit with code 1. This is not a crash or error condition—it's the expected behavior when an agentic loop reaches its iteration budget. Session 2 completed successfully, processed blocking issues on the e-signature and crew page, and queued a task for human review.
Task pipeline health: The daemon tracks session usage against a daily limit of 5 total sessions. Today's usage was 3 of 5, with sessions clearing at midnight UTC (expected rollover behavior). No pending tasks remained in the queue as of the diagnostic window, indicating the daemon had fully processed available work.

One critical issue was surfaced: the port_sheet_sync.py script's Google OAuth token has expired or been revoked. Every 30-minute sync attempt since at least midday has failed with "HTTP Error 400: Bad Request". The port sheet syncing pipeline is currently broken and requires re-authentication via the auth_ga.py` tool.



Key Architectural Decisions


Monorepo site structure: All properties (86from.com, sailjada.com, queenofsandiego.com) are colocated in a single monorepo at /Users/cb/Documents/repos/sites/. This allows unified CI/CD orchestration but requires careful cache invalidation strategies to avoid cross-contamination during CloudFront deployments.

Staging bucket validation: Before promoting to production, the staging CloudFront distribution was used to validate booking widget functionality. Only after confirming JavaScript syntax validity was the file promoted to the live environment. This pattern prevents broken UX from reaching customers.

OAuth token lifecycle: Rather than embedding credentials in environment variables or configuration files, credentials are stored in a secrets directory with restricted file permissions. The auth_ga.py script reads these at runtime and obtains fresh access tokens via refresh token flow, ensuring expired credentials automatically refresh without manual intervention.

Daemon observability without privileged logs: Since full application logs weren't available, the diagnostic approach relied on systemd journal, process metrics via /proc, and daemon-exposed task queues. This "black box" strategy is appropriate for production systems where you may not have application-level logging configured.


What's Next


    

      ← All posts