Understand Project Status

One of the main product jobs of Flash Launch is to make progress visible.

That sounds simple, but it matters a lot. Shipping problems are often not code problems. They are state problems:

• the site has not been deployed yet
• the database is still provisioning
• DNS is correct but HTTPS is still verifying
• a background job failed and is retrying

If the product only gave you a generic spinner, you would still have to guess. The current platform is trying to do something better: turn infrastructure progress into a small, understandable set of states.

If you have not read the product overview yet, start with What Flash Launch Is.

The three layers of status in Flash Launch

In the current platform, project status is easiest to understand if you separate it into three layers:

You can think of the project page as a status dashboard for these layers.

The main project capabilities that expose status

In the current product, the clearest user-facing status surfaces are:

• Static Site
• Database
• Domain
• Jobs

These show up in the project summary area because they are the parts of the platform where real work is happening.

How to read Static Site status

Static site deployment currently uses a small lifecycle:

The important distinction is that live is not just "upload succeeded." It means the project currently has an active static deployment.

That is why static site status should be read together with deployment history:

• if the status is live, there should be an active version
• if something broke after a later deploy, rollback is part of the recovery path

How to read Database status

The project database lifecycle is similarly compact:

This is why the database tab pairs status with actions:

• Set Up Database when nothing exists yet
• Check Health after activation
• connection info and reveal flows only after the DB is ready

The correct mental model is: database status tells you whether the resource exists and is ready, not whether your application schema or queries are correct.

Why some statuses are user actions and others are system actions

The current setup model separates steps the user initiates from work the platform continues in the background.

That same pattern applies elsewhere in the product:

• uploading a site is a user action
• processing the deployment is a system action
• provisioning a database is a system action after a user request

What Jobs status means

Feature states tell you what the project currently looks like. Jobs tell you what the platform is still doing in the background.

In the current platform, jobs are especially relevant for domain workflows, but the concept is broader.

The job states are:

This matters because a project can be "not done yet" even when no button is currently spinning in the UI. Jobs are how Flash Launch makes asynchronous work visible instead of hiding it.

How feature state and job state relate

A good way to read the page is:

• the feature status tells you the current state
• the jobs list tells you whether that state is still moving

Examples:

This is the difference between "current state" and "remaining work."

How to tell whether a project is launch-ready

The overview page gives you a simple shorthand:

• Static Site should not be not_deployed
• Database should be active if your app needs state
• Jobs should not be stuck in a failing retry loop

That is why the current overview also includes a Getting Started sequence. It treats launch readiness as a checklist of capabilities, not a single magic boolean.

The difference between waiting and broken

One of the easiest mistakes a beginner can make is interpreting every non-final state as failure.

In Flash Launch, these usually mean "wait" rather than "broken":

• deploying
• provisioning
• queued
• running
• retrying

These usually mean "intervene" rather than "wait":

• error
• failed
• repeated retries with the same actionable error

This distinction is one of the most important parts of understanding project status. Not every incomplete state is a problem. Some states are simply the honest shape of an asynchronous system.

How to use the error text and action hints

The current platform does not only expose status labels. It also tries to attach plain-language error messages and next-step hints where possible.

That means status should be read in this order:

1. the badge
2. the last checked or updated time
3. the attached error message, if any
4. the action hint, if any
5. the jobs list for background activity

That order helps avoid wasted time. A badge tells you the broad category. The hint tells you the next move.

A useful status-reading habit

When something looks wrong on the project page, diagnose in this order:

1. Which feature surface is affected: static site, database, or domain?
2. Is the current state incomplete, or actually failed?
3. Is there a job still running or retrying?
4. Is there an explicit action hint telling you what to change?

This is a much better debugging habit than jumping straight into code changes.

Common interpretations that are correct

These are the readings the product is trying to support:

• provisioning means "the resource request has been accepted and is still in progress"
• retrying means "the platform has not given up yet"
• active or live means "this capability is currently usable"
• error or failed means "I should look for the attached message and next action"

If the product keeps those meanings consistent, the dashboard becomes easier to trust.

Current limits of the status model

The status model is intentionally scoped to the currently supported cloud capabilities, so it is useful but not universal.

• Not every platform subsystem is fully live yet
• Some future capabilities still exist more in architecture than in full runtime behavior
• Logs and error aggregation are not yet as complete as the product direction suggests
• Some advanced operational states still collapse into a simpler badge in the current UI

That is normal. The important thing is that the current status system already supports the parts of the product that are real today.

The right mental model

Flash Launch status is not just decoration. It is part of the product.

The platform is trying to do two things at once:

• automate shipping work
• explain enough of that work that the user can still operate it safely

That is why the status system matters. It is how the platform turns hidden infrastructure progress into something a builder can reason about.

Related docs

• What Flash Launch Is
• Deploy a Static Site
• Set Up Your Project Database
• Observability for First Launch
• Debugging First Launch Failures