Skip to main content
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

Customer and admin apps run on AWS Lambda behind CloudFront through sst.aws.Nextjs:
  1. Open GitHub Actions → Deploy AWS → Run workflow
  2. Set git_ref to the last known-good tag or SHA
  3. Run the workflow and verify both /api/health endpoints
A failed SST/Pulumi update can leave resources partially changed. Inspect the deployment logs and stack state, verify both /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

  • 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
  • Check Resend dashboard — is the API key valid? Any rate limits?
  • Check Sentry for UPSTREAM_ERROR from the email service
  • Emails are non-blocking — bookings still succeed, emails can be retried
  • 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
  • Check Ably dashboard — is the app within message limits?
  • Realtime is non-critical — the app works without it (polling fallback)
  • 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

Never run migrations directly on prod without testing on test + pprd first.

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:
  1. Runs pg_dump against Neon prod branch
  2. Uploads compressed dump to Cloudflare R2 (backups/weekly/)
  3. Retains 8 weeks of backups
  4. 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 / www resolve to the SST-managed web CloudFront distribution
  • Cloudflare DNS: admin.theroyalglow.in resolves to the SST-managed admin CloudFront distribution
  • Cloudflare DNS: cms.theroyalglow.in points to Render (rgss-cms)
  • Cloudflare DNS: docs.theroyalglow.in points to Mintlify
  • Cloudflare DNS: status.theroyalglow.in points 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)
Last modified on September 1, 2026