Launch Readiness
Confirm what must be ready before internal or customer launch.
Launch Readiness
Use this page before opening a workspace to internal teams, customer traffic, or a new feature rollout.
Readiness is an operating diagnostic for the selected workspace. A successful P0 app task does not prove billing, ownership, moderation, or provider readiness. Review the current Console results and the owners on this page before launch.
Item States And Overall Status
Items use ready, todo, blocked, attention, optional, and unknown, with required or recommended severity. unknown means the check could not establish readiness; it is not a success. The overall status is blocked when any required item is neither ready nor optional; otherwise an unresolved item makes it attention. Remaining items yield ready.
For billing, when the plan source is a subscription, past_due, expired, and suspended produce a blocked item. canceled produces an attention item. Billing is required, so that attention item still makes the overall result blocked. Keep subscription state, item state, and overall status distinct.
Plan-blocked selections, Secret Key setup, team ownership, webhooks, and occurrence sellability are recommended diagnostics; a recommended blocker can make the overall result attention without increasing required blocking. Assess whether each applies to your launch. A Secret Key is needed for privileged server integrations, not every public-read app; a webhook registration is needed only for workflows that use it.
Readiness Categories
| Category | Ready means | Stop when |
|---|---|---|
| workspace | identity, owner, and team access are clear | no admin owner or stale access remains |
| features | at least one selected feature is effective | selected features are plan-blocked |
| keys | Publishable Key, CORS, and Secret Key ownership are clear | browser origins or key ownership are missing |
| billing | plan and subscription state are usable | subscription is past due, suspended, expired, or unclear |
| content | enabled areas have minimum real content | enabled areas are empty or unowned |
| webhooks | owners know where delivery failures appear | failure ownership is unclear |
| team | tenant-admin memberships have operating owners | no admin exists; a single admin needs attention |
An expired subscription has ended, for example when a scheduled cancellation takes effect at the end of the billing period.
Launch Checklist
- owner and admins are current
- effective features match the launch scope
- required content or commerce records exist
- if admission types are configured, review the recommended occurrence sellability diagnostic
- CORS, keys, and webhooks have owners
- billing state is not blocking
- support and moderation responsibilities are assigned
Stop Conditions
Pause launch when any required item is blocked, when plan-blocked features are still part of the launch promise, or when nobody owns customer-facing failures.
Treat readiness blockers as launch blockers. Fix the owner, feature, key, billing, content, or support gap before expanding exposure.
Next Actions
- If access is unclear, return to Workspace Setup.
- If features are blocked, return to Feature Planning.
- If keys or domains are blocked, return to Integrations & Keys.