App lifecycle & status
For citizen developers
Every Greenlight app moves through a governed deployment lifecycle. The dashboard shows the current status on the app’s detail page; the agent surfaces transitions in your chat.
| Status | What it means |
|---|---|
| Registered | The app record and repo exist, but nothing is deployed yet. |
| Building | The pipeline is building the container image. |
| Deploying | Greenlight is rolling the app out to Kubernetes and preparing its URL. |
| Active | The app is running. End users can sign in and use it. |
| Degraded | The app is reachable but failing health checks or crash-loop thresholds. |
| Failed | The build or deploy failed. The agent can read the failure detail and try again. |
| Suspended | The app is paused. The pod is scaled to zero and workload access is revoked, but recoverable app resources are retained. |
| Decommissioned | IT has permanently retired the app. Runtime resources are removed and the repo is archived. |
What you control
You can ask to pause or resume an app you own, and IT can suspend any active or degraded app immediately. Suspension is useful when you’re rebuilding something and want end users not to hit a half-broken state, or when IT needs an app offline during an incident.
You cannot decommission an app yourself. Decommission is an IT action for permanently retiring an app after it has been suspended and reviewed.
What end users see
| Status | What end users see |
|---|---|
| Registered, Building, Deploying, Failed | The app’s URL is not available yet, or the dashboard shows build/deploy failure detail. |
| Active or Degraded | Normal sign-in and usage, though degraded apps may be unstable. |
| Suspended | A short message — “this app is paused.” |
| Decommissioned | The app URL is gone. |
Following the build
The agent reports progress as it works. The dashboard’s app detail page has a Pipeline tab that shows every pull request, its policy-check result, and (on merge) its deploy. You can watch the build land in real time, or come back later and read the history.
If a pull request fails the policy check, you don’t need to do anything. The agent reads the failure and tries again. Repeated failures on the same check are worth flagging — that usually means the agent has misread what the policy expects, and a quick conversation in chat sorts it out.