Use this checklist before a FeatureGate integration serves production traffic. Record the responsible
owner for each section rather than treating the review as a one-time developer task.
Resource model
- The application uses the intended organisation and project.
- Environment names represent real deployed boundaries.
- The production key binds to the production environment.
- The flag key and type are treated as durable application contracts.
- Every required environment has an explicit reviewed configuration.
Credentials
- The key family matches the trust boundary.
- The key has only required scopes.
- Server keys live in a deployment secret manager.
- Server keys cannot enter browser bundles, logs, traces, or error reports.
- Browser keys have exact allowed origins and only intended flags are exposed.
- Key naming identifies the caller and rotation owner without sensitive data.
- The rotation procedure is documented and rehearsable.
Client lifecycle
- Long-running Node.js services create one client per runtime key.
- The client is reused rather than constructed per request.
initialize() has an explicit fail, retry, bootstrap, or degraded startup policy.- Background polling errors reach application monitoring.
- Shutdown calls
close().
- Operators know the polling interval and last-successful-snapshot behaviour.
Decision contract
- Every getter or HTTP evaluation has a safe typed default.
- Object and numeric values receive application-level validation.
- Missing, archived, unconfigured, and type-mismatch behaviour is tested.
- Evaluation details are available for diagnostics.
- Authorization and entitlement enforcement remains independent.
Context and rollout stability
- Context contains only attributes used by active rules.
- Each path has a documented source, type, normalization, and missing behaviour.
- Percentage rollout identifiers are opaque and stable.
- The rollout unit matches the desired user, account, or installation consistency.
- Browser context is treated as user-controlled.
- Logs exclude full context, targeting values, and resolved values.
HTTP resilience
- Related evaluations are batched.
- Request timeout is shorter than the surrounding operation budget.
- The caller applies defaults when the API cannot complete.
- Retries are bounded and limited to transient failures.
429 retry information is respected.400, 401, 403, and 413 do not loop without corrective action.
Snapshot resilience
- The first snapshot is validated before use.
- A last-known-good snapshot is retained after refresh failure.
- Staleness duration is monitored.
- Invalidation is advisory and ETag polling remains authoritative.
- Bootstrap data has an owner and freshness review.
- No snapshot or server key is exposed to a client.
Release ownership
- The flag has an owner, intent, lifecycle kind, and review date.
- The final intended value and guarded code are documented.
- Non-production configuration is validated before production changes.
- The rollout has observation signals and a rollback condition.
- Application outcome monitoring exists outside FeatureGate.
- The cleanup task includes code, tests, targeting, and platform archive.
Operational readiness
- Builders know how to diagnose an unexpected default.
- Key creation, revocation, flag changes, and kill switches are visible in activity.
- Notification recipients and preferences are understood.
- Incident procedures distinguish normal rollback from a kill switch.
- Support escalation includes request ID and key prefix, never the raw key.
Launch review
Perform one production-safe evaluation before broad release. Confirm the response environment, value
type, reason, application fallback, and observability path.
After launch, schedule the first flag review. Production readiness is incomplete when nobody owns
rotation, incident response, and cleanup.
Continue with Run a controlled rollout,
Errors and fallbacks, and
Activity and audit history.