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

```html

The Problem: Silent Booking Funnel Failure

On June 2, 2026, all eleven event pages across sailjada.com and queenofsandiego.com experienced a complete failure of the "Reserve" deposit widget. The symptom was a two-endpoint outage:

Primary endpoint (10 event pages): returning 403 Forbidden
Worship endpoint (1 page): returning 404 Not Found

Both endpoints were Google Apps Script deployments. The 403 indicated access control had been revoked; the 404 suggested the deployment itself had been deleted or was unreachable. Because these are the only funnel entry points for booking deposits, the outage was effectively a total revenue stop—with no alerting in place, the silent failure meant we had no visibility into how many bookings were being lost.

Investigation: Cross-Repository Audit

The root cause required tracing the deployment chain across multiple repositories and configurations. Here's the systematic approach:

Step 1: Locate the Apps Script Project

The first challenge: the deployment ID embedded in the page HTML didn't immediately map to a named project. I searched across:

/jada-ops documentation for any reference to the Apps Script project name
/Documents/repos/sites/queenofsandiego.com and /Documents/repos/sites/sailjada.com for clasp configs
~/.clasp.json and project-level appsscript.json files

Result: Located the project ID 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5 and confirmed it matched the live endpoint deployment in the Google Apps Script console.

Step 2: Verify Endpoint Health

I hit both endpoints directly to confirm the failure modes:

# Primary endpoint (10 pages)
curl -i https://script.google.com/macros/s/.../44Pme8wCA/exec
# Returns: 403 Forbidden

# Worship endpoint (1 page)
curl -i https://script.google.com/macros/s/.../AFsLWaO3/exec
# Returns: 404 Not Found

The 403 meant the deployment existed but the access control was set to a restricted audience (likely just the project owner). The 404 meant that deployment was either deleted or never redeployed after a code push.

Step 3: Dry-Run Endpoint Rewrite Path

Before making changes, I validated the fix path by dry-running the rewrite across all eleven event pages in both the source repository and S3:

# Dry-run local HTML files
for page in /Documents/repos/sites/queenofsandiego.com/events/*.html; do
  grep -n "script.google.com/macros" "$page"
done

# Dry-run S3 objects
aws s3 ls s3://queenofsandiego-prod/events/ --recursive | grep "\.html"

This confirmed that both the source repo and the S3 distribution contained hardcoded deployment IDs embedded in inline script tags, making them brittle to deployment changes.

Root Cause: Deployment Access Control

The primary outage (403) stems from a misalignment between who deployed the Apps Script and who has access to execute it. When an Apps Script is deployed, the "Who has access" setting determines which users or scopes can call the endpoint:

Only me — only the deployed-by account can execute (causes 403 for public traffic)
Anyone — any user with the URL can execute (required for public widgets)
Anyone with the link — unauthenticated users with the URL can execute (also suitable for public endpoints)

The deposit widget requires public execution. The 403 indicates the deployment is locked to a single account, most likely because it was deployed locally by a developer without switching the access control.

The Secondary Issue: 404 on Worship Endpoint

The 404 is more severe: it suggests the deployment slot was either deleted or never created. This could happen if:

The deployment was manually deleted in the Google Apps Script console
The project code was updated but never redeployed to that slot
The deployment ID in the HTML is stale and doesn't match any active deployment

Both issues require manual intervention in the Google Apps Script console.

Staging the Fix

The fix path is documented in /jada-ops/DEPOSIT-OUTAGE-FIX-2026-06-02.md and requires two separate actions:

Action 1: Fix the 403 (Primary Endpoint)

Navigate to script.google.com
Open project 1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5
Click Deploy → Manage Deployments
Select the active deployment (likely labeled "Latest version")
Edit the deployment settings:
- Who has access: change to "Anyone"
- Execute as: set to account that owns the project (for proper logging/auditing)
Click Deploy
Verify the endpoint now returns 200 with valid JSON response

Action 2: Fix the 404 (Worship Endpoint)

In the same project console, check if the worship endpoint deployment exists in Manage Deployments
If missing, create a new deployment:
- Type: "New deployment"
- Select type: "Web app"
- Execute as: project owner account
- Who has access: "Anyone"
Deploy and capture the new /exec URL
If the deployment exists but returns 404, the project code may need redeployment

Why This Approach

Rather than redeploying code or changing the Apps Script project itself, we're fixing the access control and deployment slot configuration. This is the minimal-risk path because:

← All posts