Deploy failures share a small number of root causes: env mismatch between dev and prod, DNS that hasn’t propagated, cache holding stale assets, and no rollback rehearsed. These prompts surface the typical hits before they go live, and give you a structured post-launch watch so a regression doesn’t go unnoticed for a day. Pair with Claude Code execution prompts for the build side.
Best for
- First production deploy of a new project
- Major version release with breaking changes
- Custom domain migration between providers
- Hosting platform switch
- Site-wide infrastructure changes (CDN, image host, DNS)
- Releases that touch billing, auth, or anything load-bearing
1. Pre-launch checklist
My stack: {framework + hosting}. Generate a pre-launch checklist tailored to this stack:
- build (commands, env, output dir)
- env vars (required, optional, secret-store reference)
- DNS, SSL (certs, redirects, www vs apex)
- sitemap, robots.txt, canonical
- analytics, error tracking, real-user monitoring
- AdSense / monetization status (if applicable)
- legal pages, privacy, cookie banner
≤25 items. Mark each as blocking or non-blocking.2. Env-var diff check
Below are env-var lists for dev + prod. Identify:
- missing in prod that the code requires
- mismatched values likely to break (URLs pointing to the wrong env, feature flags inverted)
- present in prod but no longer used in code
- secrets exposed in non-secret env files
{paste}
Output: 4 lists with severity tags.3. DNS migration plan
Migrating domain {domain} from {provider A} to {provider B}.
Plan:
- TTL pre-lower steps and timing (start 48h before)
- Full list of records to recreate (A, AAAA, CNAME, MX, TXT, CAA)
- Order of operations during the cutover
- Rollback path (and the TTL window that allows it)
- Verification commands (dig, nslookup, online propagation checker)4. Cache invalidation plan
Deploying changes that affect cached assets / pages.
List:
- layers I need to invalidate (CDN, edge, framework page cache, browser via cache headers)
- expected propagation time per layer
- which assets are safe to keep cached
- verification commands for each layer
- fallback if invalidation is slow (purge-by-tag, version-bump asset URLs)5. Smoke-test script
Generate a 10-step smoke-test script for {site} to run post-deploy:
1. homepage loads
2. a key article / detail page
3. sitemap.xml valid + lists expected URLs
4. robots.txt allows production crawl
5. 404 page works
6. login flow (if any)
7. API health endpoint
8. RSS feed (if applicable)
9. hreflang correctly cross-links languages
10. mobile layout doesn't break above the fold
Each step: command or URL + expected result + how to log failure.6. Observability check
For {stack}, list the minimum observability I should have before launch:
- error tracking (frontend + backend)
- structured logging
- uptime monitor (external)
- real-user metrics (web vitals, conversion)
- alert routing (where alerts land, on-call rotation)
Suggest free-tier tools per category and the 5-minute setup steps for each.7. Rollback drill
For my stack {framework + hosting}, design a rollback procedure:
- code rollback (git revert vs previous deploy promote)
- DB migration rollback (forward-only? down-migration? feature flag instead?)
- DNS rollback (TTL constraints)
- cache invalidation after rollback
Document the exact commands. Include a "who has access" line per step.8. Post-launch 24h monitor plan
First 24h post-launch: what to watch and when.
For each metric, give:
- threshold that triggers attention
- first action when threshold is hit
- escalation path if first action doesn't resolve
Metrics: error rate, p95 latency, Search Console errors, hosting platform alerts, AdSense / monetization status, conversion vs baseline.9. Security header audit
For {site URL}, draft a security header set:
- Content-Security-Policy (tight default + necessary allowances for analytics, AdSense, fonts)
- Strict-Transport-Security
- X-Frame-Options / frame-ancestors
- Referrer-Policy
- Permissions-Policy
Output: the exact header config for {hosting platform} + verification command (curl -I).10. Hreflang / i18n verification
My site has {N} languages: {list}. For each page type ({homepage, article, category}), verify:
- hreflang tags cross-link all language variants
- x-default points to the right page
- canonical does NOT cross languages
- sitemap has language-specific entries
- 1 example URL per language to spot-check
Output: a verification checklist + the exact URLs to manually test.11. Status page + incident comms templates
Draft 4 status page / incident comm templates for {site}:
1. Investigating — first 10 min of an incident
2. Identified — root cause known, fix in progress
3. Monitoring — fix deployed, watching for stability
4. Resolved — full post with timeline, root cause, follow-ups
Each ≤200 chars in the status update + a longer email version. Voice: calm, factual, no blame.12. Post-incident root-cause prompt
We had an incident: {one-line description, duration, user impact}.
Walk me through a structured post-mortem:
1. Timeline of events (detection → mitigation → resolution)
2. Direct cause vs root cause vs contributing factors
3. What worked in the response
4. What we should change (process, code, observability)
5. Action items with owners and due dates
Output: a fill-in template I can paste into the post-mortem doc.Common mistakes
- No env-var diff before deploy — half of all “it works locally” failures land here
- Skipping the cache invalidation plan — users see the old version for hours, file bug reports
- No rollback drill before launch — rollback gets debugged for the first time during an outage
- Watching only error rate post-launch — conversion regressions silently outlast a quiet error log
- Forgetting the hreflang check on i18n sites — Google indexes one language and ignores the rest