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

During a June 2026 operations session, we discovered a complete stoppage affecting all booking deposit flows across 11 event pages on sailjada and queenofsandiego.com. The Reserve widgets were returning HTTP 403 and 404 errors, silencing every inbound deposit attempt. This post details the diagnosis methodology, infrastructure state inspection, and the staged fix that restores revenue flow.

The Problem: Silent Booking Funnel Collapse

The symptom was stark: every public event page calling the Apps Script deployment endpoint was receiving either a 403 Forbidden or 404 Not Found response. Users clicking "Reserve" encountered dead buttons. Critically, there was no alerting on this—the funnel was dark, meaning unknown revenue loss.

Two distinct endpoints were affected:

  • https://script.google.com/macros/s/AKfycbxUK...44Pme8wCA/exec — serving 10 event pages, returning 403
  • https://script.google.com/macros/s/AKfycbx_...AFsLWaO3/exec — worship event, returning 404

The 403 indicated access revocation; the 404 suggested a deleted or undeployed Apps Script resource entirely.

Diagnosis: Tracing the Request Chain

We approached this systematically by following the request path backward:

Step 1: Verify Live Endpoint State

curl -v https://script.google.com/macros/s/AKfycbxUK...44Pme8wCA/exec
# Response: 403 Forbidden
curl -v https://script.google.com/macros/s/AKfycbx_...AFsLWaO3/exec
# Response: 404 Not Found

Step 2: Locate Project ID in Infrastructure

We searched the jada-ops directory structure and source repos for references to the Apps Script project. The key was finding the clasp configuration (Google Apps Script command-line tool uses .clasp.json):

grep -r "1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5" ~/Library/Mobile\ Documents/com~apple~CloudDocs/jada-ops/
grep -r "AKfycbxUK" ~/Documents/repos/

This revealed that the project ID 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5 was the canonical Apps Script resource. The /exec URLs are *deployment* endpoints derived from that project—distinct from the project itself.

Step 3: Inspect Deployment Access Control

The project ID doesn't tell us who can call the endpoint. That's controlled inside the Google Apps Script console via the deployment settings. We couldn't verify the live console state remotely, but the 403 response strongly indicated the deployment had been set to "Anyone with the link" or a restricted audience that no longer included public anonymous access.

Root Cause Analysis

Apps Script deployments have two critical access-control settings:

  • Who has access: "Anyone", "Anyone with the link", "Specific people", or private
  • Execute as: "Me" (the deployer's identity) or "User accessing the app"

A 403 response occurs when the deployment's access control denies the caller. The most likely cause: the deployment was set to "Specific people" or a user-only access model that doesn't include anonymous public traffic.

The 404 on the worship endpoint suggested that deployment was deleted entirely—possibly during a manual cleanup or re-organization of the Apps Script project.

Staged Fix: Access Control Restoration

The fix is a single action in the Google Apps Script console, no code changes or redeployment of our source:

  1. Navigate to script.google.com
  2. Open the project 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
  3. Go to Deploy → Manage deployments
  4. For each deployment:
    • Click the deployment (or "New deployment")
    • Set Who has access = "Anyone"
    • Set Execute as = "Me"
    • Click Deploy

This restores public anonymous access to the `/exec` endpoint without requiring a code change. The deployment ID itself remains stable, so all 11 event pages' hardcoded `/exec` URLs continue to work.

Why This Approach?

Minimal risk: No code changes, no source repo redeploy, no CloudFront cache invalidation. The endpoint URL remains identical; we're only adjusting who can call it.

Revenue impact: This is a complete stoppage affecting every deposit entry point. The fix is reversible in seconds and has zero infrastructure dependencies.

Avoided complexity: We considered re-deploying the Apps Script to create new deployment IDs, but that would require updating all 11 event pages in the S3 HTML/CSS, invalidating CloudFront cache, and re-testing. By restoring access on the existing deployment, we skip all of that.

Infrastructure Context

The deposit flow architecture:

  • Event pages: Stored in S3 buckets (sailjada and queenofsandiego.com CloudFront distributions)
  • Reserve button: JavaScript in the HTML directly calls the Apps Script endpoint via HTTPS
  • Apps Script deployment: Hosted at Google, returning 403 or 404 due to access control
  • No Lambda, no API Gateway, no DynamoDB involved in the deposit flow itself — it's a direct client-to-Google call

This simplicity is a strength: the outage is isolated to Apps Script permissions, not a wider infrastructure issue.

Verification and Next Steps

After the fix is applied in the Google console, we verify by re-testing both endpoints:

curl -v https://script.google.com/macros/s/AKfycbxUK...44Pme8wCA/exec
# Should return 200 (or the Apps Script response, not 403)

curl -v https://script.google.com/macros/s/AKfycbx_...AFsLWaO3/exec
# Should return 200 (or re-create the deployment if still 404)

If the 404 persists, we redeploy the worship endpoint from source. If both return 200, the booking funnel is live again.

This fix should take 2–3 minutes in the Google console and restore revenue flow across all 11 event pages immediately.

```