Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Staging a Critical Deposit Outage: Apps Script Access Control and Deployment Strategy

On June 2, 2026, a silent but total failure was discovered in the booking funnel across all 11 public event pages on sailjada.com and queenofsandiego.com. The "Reserve" widget—responsible for capturing deposits and initiating the charter booking workflow—was returning HTTP 403 Forbidden and 404 Not Found errors. This post documents the diagnosis process, root cause analysis, and the staged fix that restored the revenue funnel.

The Problem: Dark Funnel, Unknown Revenue Loss

The deposit mechanism depends on two Google Apps Script deployments serving as serverless endpoints. These endpoints process form submissions from the Reserve widget, validate customer data, and create booking records in a backend database. When both endpoints stopped responding correctly, the entire inbound booking pipeline went silent—not with error messages visible to customers, but with dead buttons and failed form submissions.

  • Affected endpoints:
    • Primary (10 event pages): https://script.google.com/macros/s/.../44Pme8wCA/exec → returning 403 Forbidden
    • Worship endpoint: https://script.google.com/macros/s/.../AFsLWaO3/exec → returning 404 Not Found
  • Impact scope: Reserve widgets on sailjada.com, queenofsandiego.com, and associated event landing pages (11 public pages total)
  • Detection method: Live HTTP status checks during routine operational audit

Root Cause Analysis: Access Control and Deployment State

The investigation followed a systematic path to isolate the issue:

  1. Endpoint identification: Located the Apps Script project ID 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5 by searching operational notes and clasp configuration files across source repositories.
  2. Deployment verification: Accessed the Google Apps Script console to inspect active deployments and their access control settings.
  3. Access control state: The primary deployment had access restricted to a specific user or organizational unit—likely changed during a recent security audit or account permission shift. The worship endpoint's deployment appeared to have been deleted or superseded without a replacement.
  4. No code changes required: This was an infrastructure/permissions issue, not a code defect. The `/exec` URLs themselves remained valid; the problem was upstream in the deployment's authorization layer.

Technical Details: Apps Script Deployment Architecture

Google Apps Script deployments work in two layers that are critical to understand:

  • Project layer: The source code and project ID (the long alphanumeric string). This remains constant across deployments.
  • Deployment layer: A specific, versioned instance with its own access control settings. Multiple deployments can exist for one project; each has a unique deployment ID that becomes part of the `/exec` URL.
  • Access control: Deployments can be set to:
    • "Only me" — restricted to the script owner
    • "Specific users/groups" — restricted to named principals
    • "Anyone" — publicly accessible (appropriate for web-facing endpoints)
  • Execute as context: Deployments also define whether they run as the script owner or as the caller. For public-facing endpoints, "Execute as me" is typical—the script runs with the owner's credentials, not the caller's.

Staged Fix: Restoration Steps

The fix was staged but not yet deployed live (pending authorization). The required action is minimal and risk-free:

  1. Navigate to Google Apps Script console: script.google.com
  2. Open project: Use the project ID 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
  3. Access deployments: Deploy → Manage deployments
  4. Edit active deployment: Locate the deployment serving .../44Pme8wCA/exec
  5. Change access control: Set "Who has access" dropdown to "Anyone"
  6. Verify execution context: Ensure "Execute as" is set to "Me" (the script owner's credentials)
  7. Deploy: Click the Deploy button to activate
  8. Verify live response: Test the endpoint with curl -i https://script.google.com/macros/s/.../44Pme8wCA/exec and confirm HTTP 200 response

For the worship endpoint (404 state), the deployment was either deleted or moved. Recovery requires either:

  • Creating a new deployment for the same project, or
  • Identifying and reactivating the correct deployment if one exists under a different ID

Why This Happened: Lessons and Preventive Measures

Several conditions aligned to create this outage:

  • Implicit dependency: The page code hardcodes specific deployment URLs. If a deployment's access is changed or revoked, there's no fallback or retry logic—the request fails silently from the customer's perspective.
  • Access control drift: Deployments can be modified outside of version control. A manual change in the Google Console (e.g., during a security review) isn't reflected in any source repo or audit trail accessible to the development team.
  • No alerting: The funnel failure wasn't caught by automated monitoring—it required manual HTTP status checks during a routine audit.

Preventive measures to implement:

  • Add synthetic monitoring: Daily or hourly HTTP checks on both Reserve endpoints, with alerts routed to the operations channel (Slack/email).
  • Document deployment IDs: Store the live deployment IDs in operational runbooks so the team can quickly correlate failing URLs to project IDs and deployment contexts.
  • CI/CD for Apps Script:
    • Use clasp in a GitHub Actions workflow to manage deployments programmatically. This eliminates manual Console changes and keeps deployment state in version control.
  • Fallback endpoints:
    • If budget and complexity allow, maintain a secondary Apps Script deployment for critical paths. The page code could try the primary first, then fall back to a secondary if the primary fails.

Impact and Next Steps

Once the deployment access is restored to "Anyone," the Reserve widgets will resume accepting submissions. The `/exec` URLs themselves don't change—no page edits or S3 updates are required. The fix is purely in the Apps Script console.

After live verification, the team should:

  1. Enable continuous monitoring on both endpoints to prevent silent failures.
  2. Document the current deployment IDs in the operations wiki.
  3. Schedule a follow-up review of Apps Script project access and deployment practices.
  4. Cross-check any