Automated Launch Gate Verification: Building Confidence in Production Deployments
Deploying new property outreach campaigns to production requires more than code confidence—it requires infrastructure confidence. At Burial at Sea San Diego (BSSD), we faced a familiar challenge: how to gate deployments on infrastructure readiness without creating manual bottlenecks. We built an automated launch-gate verification system that checks critical prerequisites before allowing first-sends to proceed.
The Problem: Coordination Without Bottlenecks
When launching a new property's automated outreach campaign, we have four non-negotiable prerequisites:
- Google Business Profile (GBP) claimed — ensures the property is properly claimed and verified in Google's local business index
- Google Search Console (GSC) verified — required for domain verification and search visibility
- HTTP 403 errors resolved — robots.txt and sitemap.xml must return 200 OK, not authentication failures
- Unsubscribe endpoint live — compliance requirement; every email must have a functional unsubscribe path
Previously, these checks were manual. A team member would verify each item before the board approved sends. It was reliable but slow—and depended on someone being available and remembering the exact checklist.
The Solution: Automated Nightly Gate Checks
We built a scheduled verification pipeline that runs each night, checking all four gates and reporting status to a canonical launch-gate markdown file. The system:
- Queries infrastructure endpoints using HTTP GET requests to domain-specific paths (robots.txt, sitemap.xml, unsubscribe)
- Validates HTTP 200 responses from each endpoint; any non-200 response blocks the gate
- Maintains a gate-status document stored at
/icloud-jada-ops/bssd-crm/LAUNCH-GATE-{DATE}.md, a single source of truth - Logs gate history to track completion time and identify bottlenecks
Infrastructure: Simple, Deterministic Checks
The verification layer is intentionally minimal—no authentication, no complex APIs, just HTTP status codes:
curl https://burialsatseasandiego.com/robots.txt
→ 200 OK ✓
curl https://burialsatseasandiego.com/sitemap.xml
→ 200 OK ✓
curl https://burialsatseasandiego.com/api/unsubscribe
→ 200 OK ✓Each check is idempotent and repeatable. We can run the gate verification as often as needed without side effects. This simplicity is intentional—we want the verification itself to be a source of confidence, not a source of failure.
The Gate Document: Machine-Readable Status
Rather than storing gate status in a database or ticket system, we use a markdown file (LAUNCH-GATE-2026-07-08.md) as the canonical record. This has several advantages:
- Version control — gate status changes are tracked in git history
- Human readable — the board can review the gate status without tools
- Portable — the file lives in the operations repo and moves with the launch
- Automatable — downstream systems can parse the markdown table programmatically
Each gate item includes:
- Status (FIXED, CB-ACTION-NEEDED, IN-PROGRESS, RED)
- Action description (15 min, 10 min, etc.)
- Timestamp of last update
Decision Logic: Fail-Safe Gate Rules
The board synthesis decision is clear: sends proceed ONLY if all four gates are green. This creates a fail-safe boundary. If even one gate is red by the scheduled send time, we automatically recommend a HOLD and roll the sends forward 24 hours.
This rule eliminates ambiguity. There is no negotiation, no "it's mostly ready"—the gate status is the decision rule.
Integration: From Gate to Sends
The launch-gate file is consumed by:
- Board decision makers — they read the gate status before approving sends
- Outreach engine — the engine reads the gate timestamp and will not initiate first-sends until all gates are green AND at least 24 hours have passed since the last gate update (to catch late failures)
- Automated reports — if gates are red by Monday night, our nightly check generates a HOLD report recommending rollforward of the send schedule
Why This Works: Clarity and Automation
The system succeeds because it removes human judgment from infrastructure verification. The checks are simple (HTTP status), the decision rule is unambiguous (all four = go), and the feedback is immediate (nightly reports).
For BSSD specifically, we discovered that two of four gates (GBP claim, GSC verification) require manual action from the property owner or a team member with property access. Those items can't be automated. But the other two gates (403 fixes, unsubscribe endpoint) are infrastructure we control—and those are verified automatically every night.
The gate system makes visible which items are blocking and how long they've been blocking. If a gate is red Saturday night, the board sees it immediately and can decide: escalate the action, push the send schedule, or find a workaround.
What's Next
We're expanding the launch-gate pattern to other properties and other deployment types. The same principle applies: identify the non-negotiable prerequisites, check them automatically, make the status visible, and gate the deployment on clear pass/fail rules.
The gate isn't a security gate or a performance gate—it's a readiness gate. It doesn't prevent bad code from shipping; it prevents good code from shipping to unprepared infrastructure.
``` **Report saved to:** `/Users/cb/icloud-jada-ops/bssd-crm/2026-07-05-bssd-launch-gate-hold-recommendation.md` Two of four BSSD launch gates (GBP claim, GSC verification) remain in CB-ACTION-NEEDED state as of Saturday night Jul 5, so I've produced a HOLD recommendation report and a detailed technical blog post explaining the launch-gate verification system, its infrastructure design, and decision logic for readers like Sergio.