Environment readiness
Diagnose an environment from initial setup through traffic and configuration review.
Environment readiness is lifecycle-first. It identifies the next useful action instead of reducing configuration to a generic health score.
Use it while activating a project or diagnosing why an environment cannot serve a meaningful hosted request.
| State | Meaning | Next action |
|---|---|---|
| No flags | The project has no active decision to serve | Create a flag |
| Defaults missing | No active flag is configured here | Configure a typed fallback |
| Create runtime key | Configuration exists but no active server key does | Create a minimum-scope key |
| Send first request | Key and configuration exist without hosted traffic | Run the generated request |
| Review defaults | Real traffic makes all-off or incomplete defaults relevant | Review configuration |
| Ready | No higher-priority setup action remains | Operate and review normally |
The sequence is derived from real resources and hosted usage. There is no persisted onboarding step that can drift from project state.
Create the first flag after confirming the environment model. An empty project must add at least one environment before flag creation becomes available.
Choose a safe type, lifecycle, and key. The first flag does not need a production rollout yet; it needs a deliberate configuration contract.
A flag definition alone is not evaluable. Initialize at least one flag configuration and choose a typed fallback.
A configured boolean false counts as a valid default. Missing configuration does not. Review the
difference before attempting to fix readiness by changing values.
Choose runtime:evaluate for direct hosted evaluation and runtime:snapshot for snapshot clients.
Store the one-time secret immediately.
A browser client key does not satisfy the server runtime activation step. It uses a different trust boundary, origin policy, and exposure model.
Use a hosted /v1/evaluate request to prove authentication, key binding, configuration, and API
reachability. The console-generated command is designed for this activation boundary.
A local Node.js getter does not create hosted evaluation usage. Snapshot fetching creates hosted API traffic but local evaluations remain unobserved.
A fresh environment whose boolean flags default off is not automatically a review problem. Before traffic, proving integration is the useful action.
After hosted traffic begins, the same all-off or incomplete configuration may affect a real runtime. Readiness can then direct the operator to review defaults.
403.Archived environments cannot create keys or receive normal changes. Restore before continuing setup. Organisation offboarding blocks existing keys even when the environment itself remains active.
Ready does not prove every application process refreshed, every rule is correct, every code path ran, or business outcomes are healthy.
Use application observability, controlled rollout procedures, and periodic lifecycle review after activation.
Related pages: Environments, Quickstart, and Troubleshooting and limits.