Use this before launch and before every big release. Each item links to where it’s set up. It assumes you’ve followed From development to production.

​
Keys and access

  • Only publishable keys in browsers and mobile apps. Secret keys only on servers, in a secret store (Keys and security).
  • One key per app or job, each scoped to what it needs, with allowed addresses where the server’s address is fixed (API keys).
  • Websites allowed to call it lists only your real sites (Environment settings).
  • The public API reference is off unless you mean it to be public.

​
Access rules

  • Every table has every operation either off or set to a deliberate rule. No table relies on “signed in” alone for private data (Access).
  • Tests prove one person can’t see another’s data, and an anonymous caller sees nothing private (Testing rules).
  • Organization rules require $auth.org is set (Teams and organizations).
  • Buckets: private unless public on purpose, accepted types and largest file set (Rules on storage).
  • Channel rules exist for every channel pattern you use (Channel rules).
  • Flows your app calls check who’s asking first.

​
Sign-in

  • Email verification on, password policy and attack protection set.
  • Two-step verification available, and required for admins.
  • Redirect URLs list only your real addresses (Redirect URLs).
  • Social and company sign-in configured with production credentials.

​
Email

  • A production provider connected and tested; Pause delivery off (Delivery).
  • SPF, DKIM and DMARC pass (Deliverability).
  • App details filled in: name, support email, postal address.
  • Sign-in email templates read well.

​
Automation

  • Every flow with side effects is safe to run twice (Reliability).
  • Calls to other services are wrapped in Retry.
  • Webhook receivers verify signatures; no inbound hook uses None.
  • Schedules that sweep use Skip overlap.

​
AI

  • Models are Servers only unless a browser must call them (Providers and models).
  • Customer-facing agents: Hold it to each person’s own access on, a Most cost limit, changes need approval (Approvals and limits).
  • AI tools connected to production use Look only keys (AI tools).

​
Data safety

  • Automatic backups on, with a retention you’ve chosen (Automatic backups).
  • You’ve restored a backup into a non-production environment at least once (Restore).
  • A pinned backup before launch.

​
Monitoring

  • Alarms on error rate, latency, failed jobs, failed webhooks and mail failures, emailing a real inbox (Alarms).
  • A status page, linked from your app.
  • Your app shows the request id in error messages, so support can find the request.
  • You’ve checked Usage & plan has headroom for launch traffic (Plans and limits).

​
Team

  • Two owners; everyone else on the least role (Team).
  • Few people can open production Studio.

​
Incident runbook

When an alarm fires or a customer reports a problem:
1

Acknowledge

Someone owns it. If customers notice, open an incident on the status page straight away, even before you know the cause.
2

Find the scope

Activity → Overview: when did it start, what’s affected? Errors groups failures by cause. Audit log: what changed just before?
3

Stop the bleeding

Undo a recent change (promote the previous version, or edit it back). For runaway email, pause delivery. For a broken integration, disable the webhook or schedule. In the worst case, turn on maintenance mode, which can keep your own servers working.
4

Recover

Fix the cause, then re-run what failed: replay jobs, redeliver webhooks, retry emails (Reliability). Restore data from a backup only if it was damaged.
5

Close

Resolve the incident with a short, honest update. Write down what happened, and add the alarm you wish you’d had.

​
Common incidents