Applications
Understand deployment status and recover a failed release
A commit is a saved revision of your code. A deployment is an attempt to build and run a commit. The application can keep serving an older successful commit even when the latest deployment fails. Check Active and Last deployment separately.
Before you start
- Select the application and intended stage. Note the commit you expected to deploy and the time it was pushed. Open Deployments; scrolling loads more history in batches rather than showing every old deployment immediately.
Nothing started after a push
- 1Confirm the push went to the repository and branch configured for this stage.
- 2Check that automatic deployment is enabled and the workspace GitHub connection still permits the repository.
- 3Check the workspace subscription and available capacity. A suspended subscription can prevent a new deployment.
- 4Check for queued or already-running work before starting a duplicate manual deployment.
- 5If all settings look correct, provide support with the application, stage, commit and push time. Do not send repository tokens or environment secrets.
Deployment is queued
Queued means the request exists but has not yet started building. Review the status for capacity, another deployment or a required operation. Do not repeatedly submit the same commit to make it move faster. If it appears stuck, report the deployment identifier and time to support.
Build failed
- 1Open the failed history entry and its build output.
- 2Read from the first meaningful error. A missing dependency, unsupported runtime, wrong project directory or incorrect build command can produce many later errors.
- 3Compare the error with the repository's setup instructions and lockfile.
- 4Fix code in the repository, or correct the application's build configuration as appropriate.
- 5Deploy the corrected commit and verify that its identifier appears in the new history entry.
Build succeeded but app is unhealthy
Check the start command, listening port, required environment values and database connection. An application can compile while its runtime cannot connect to a required service. Review runtime logs and perform a real request. Do not remove a working previous release until the replacement is healthy.
An automatic investigation is shown
Read the banner's current state. An active investigation means GD is checking the failure. If a newer commit superseded it, review the newer deployment rather than treating the old investigation as current. A completed investigation may request a code or configuration correction. Follow the report and redeploy; closing an informational banner does not fix or erase the failure. Notification delivery depends on available contact details and preferences.
Logs or history cannot load
Use Retry after the connection or session recovers. A history-loading error is different from the application's own health. If the public app works but history fails, report both facts. Do not redeploy merely to resolve a panel loading error.
Expected result
The intended commit is the active healthy release, the relevant deployment is successful, and an application-specific action works. If only an older release is healthy, report the newer deployment as unresolved.
If something does not work
- If an action is unavailable, check your role and the exact resource or request status before retrying. Preserve the safe error and reference for an authorised operator; do not repeat a payment or provisioning action whose result is uncertain.
Open the relevant page, then confirm the workspace or administrative context before making changes.
Open ApplicationsRelated guides and references
For signed-in procedures, open Help in your workspace and search by the task name. Administrative guides require the internal-documentation permission.