This is the on-call runbook. It covers how to deploy, monitor, respond to
incidents, and recover from failures. When something breaks, jump to
Incident Response and Common Issues & Fixes.
Deployment
Normal Deployment Flow
Work flows in one direction:dev → test → pprd → prod.
1
Merge PR to dev
CI runs lint + typecheck + unit tests.
2
Merge dev → test
CI adds integration tests + Playwright + Lighthouse.
3
Merge test → pprd
CI adds k6 load test + OWASP ZAP.
4
Merge pprd → prod
Requires manual approval, then auto-deploys.
Emergency Hotfix
For critical production bugs that can’t wait for the full pipeline:Rollback
- AWS web & admin
- Render CMS
- Database
Customer and admin apps run on AWS Lambda behind CloudFront through
sst.aws.Nextjs:- Open GitHub Actions → Deploy AWS → Run workflow
- Set
git_refto the last known-good tag or SHA - Run the workflow and verify both
/api/healthendpoints
/api/health endpoints, and redeploy the last known-good ref if production is unhealthy. A successful but bad release takes about 3–5 minutes to replace; use a PostHog flag first when it can contain the issue.Monitoring
Daily Checks (2 minutes)
1
Status page
Check BetterStack status page — all monitors green?
2
Errors
Check Sentry — any new error issues overnight?
3
Jobs
Check BetterStack heartbeats — did all scheduled jobs run?
Weekly Checks (15 minutes)
1
Funnel
Review PostHog funnel — any drop-off increase in booking flow?
2
Error trends
Review Sentry error trends — any new patterns?
3
Performance
Check Lighthouse CI scores on recent PRs — any performance regression?
4
Load
Review k6 load test results — any latency increase?
Alerts
Incident Response
Severity Levels
P0/P1 Response Steps
1
Acknowledge
Post in Slack
#incidents that you’re investigating.2
Diagnose
Check BetterStack and Sentry first, then the affected provider: CloudFront/Lambda in CloudWatch, Cloudflare DNS, Render CMS, or Neon.
3
Communicate
Update the BetterStack status page with an incident message.
4
Fix or rollback
Deploy a fix or roll back to the last known-good deployment.
5
Verify
Confirm Checkly synthetic checks pass.
6
Post-mortem
Document what happened, why, and how to prevent it.
Common Issues & Fixes
Booking creation failing (500)
Booking creation failing (500)
- Check Sentry for the error — usually a DB connection issue or validation bug
- Check Neon DB metrics — is the connection pool exhausted?
- Check if a recent migration broke a constraint
Emails not sending
Emails not sending
- Check Resend dashboard — is the API key valid? Any rate limits?
- Check Sentry for
UPSTREAM_ERRORfrom the email service - Emails are non-blocking — bookings still succeed, emails can be retried
PDF generation failing
PDF generation failing
- Check Cloud Run logs for the PDF render service (
@rgss/invoicing) - PDF failures are non-blocking — invoice is created in DB, PDF can be regenerated
- Manually trigger PDF regeneration via admin panel
Ably realtime not working
Ably realtime not working
- Check Ably dashboard — is the app within message limits?
- Realtime is non-critical — the app works without it (polling fallback)
QStash job not running
QStash job not running
- Check QStash dashboard — is the job scheduled? Any delivery failures?
- Check BetterStack heartbeat — did the job ping on last run?
- Manually trigger the job via the QStash dashboard
Database Operations
Running Migrations
Neon Branch Management
Point-in-Time Restore
If a bad migration or data corruption occurs on prod:1
Open the branch
Go to Neon console → Project → Branches →
prod.2
Restore to a point in time
Click “Restore” → select a point in time before the incident.
3
Verify
This creates a new branch — verify data is correct.
4
Swap the connection
Point the connection string to the restored branch.
5
Re-apply migrations
Apply any migrations that happened after the restore point.
Backup & Recovery
Weekly Backups
Every Sunday at 2 AM UTC, GitHub Actions:- Runs
pg_dumpagainst Neonprodbranch - Uploads compressed dump to Cloudflare R2 (
backups/weekly/) - Retains 8 weeks of backups
- Pings BetterStack heartbeat on success
Restore from Backup
Scaling
The platform is designed to scale without code changes:Production Verification Checklist
- Cloudflare DNS:
theroyalglow.in/wwwresolve to the SST-managed web CloudFront distribution - Cloudflare DNS:
admin.theroyalglow.inresolves to the SST-managed admin CloudFront distribution - Cloudflare DNS:
cms.theroyalglow.inpoints to Render (rgss-cms) - Cloudflare DNS:
docs.theroyalglow.inpoints to Mintlify - Cloudflare DNS:
status.theroyalglow.inpoints to BetterStack - TLS: verify ACM certificates on web/admin and provider-managed certificates on CMS/docs/status
- GMB: website field is
https://theroyalglow.in - GMB: booking action link is
https://theroyalglow.in/?book=1&utm_source=gmb - Google Search Console: verify ownership, submit sitemap
- Sentry: verify source maps are uploading correctly
- BetterStack: verify all monitors are active and alerting
- Checkly: verify all synthetic checks are passing
- Run Lighthouse CI on all key pages — all scores must pass
- Test booking flow end-to-end on prod
- Test Google OAuth sign-in on prod
- Test invoice email delivery on prod
- Seed production data (branch, categories, services, tiers)
