How to read a PreFlight failure

A failed check is useful only when it tells you what to do next. PreFlight results are structured so you can move from status to cause to fix without guessing which provider dashboard to open.

Start with status

Success means the expected behavior was observed. Warning means the result needs review, a retry, or a manual confirmation. Failed means PreFlight saw a hard blocker: rejected credentials, missing database side effects, invalid SSL, missing webhook delivery, or exposed backend secrets.

Read the safe error code

Safe error codes are designed for team chat and tickets. They describe the failure without leaking raw credentials or private provider responses. Use them as stable labels when assigning work to another teammate.

Check the fix suggestion

The fix suggestion is the shortest path to the next action. For a Stripe failure, it may point at webhook registration or restricted-key permissions. For Supabase, it may point at RLS, service-role access, storage pressure, or schema-sync drift.

Do not panic on one transient warning

Internet noise happens. A provider endpoint can time out once and recover seconds later. Retry transient warnings before rotating keys or rewriting configuration. If the same warning repeats, treat it as a real reliability issue and inspect provider status, DNS, network rules, and rate limits.

Rerun cleanly

After a fix, rerun the check from the same project so the result history stays connected. For CI or deploy hooks, use an idempotency key on POST requests so retries do not start duplicate checks or duplicate shadow checkout sessions.