Troubleshoot a failed deployment or production release
Use immutable release evidence to distinguish upload, build, promotion, routing, and health failures.
Last updated 2026-08-07
What you'll achieve
- Locate the failed deployment stage
- Keep one release identity throughout diagnosis
- Recover using a previous verified artifact
Preserve release identity
Record the deployment ID, release ID, artifact digest, environment, region, UTC time, and final state. An accepted upload means processing began; it does not mean production is healthy.
Check in order
- Confirm the build completed and produced a verified artifact.
- Confirm the deployment references that exact artifact digest.
- Check whether promotion became Active or remained queued, failed, or degraded.
- Test the BlinkHost hostname before attributing the failure to custom DNS.
- Compare production release metadata with the deployment record.
- Filter logs and traces by release, region, operation, and time.
For a bad active release, select the previous healthy signed artifact and use Rollback Here. Rollback creates a new auditable deployment; it does not rebuild historical source. Do not repeatedly create new deployments after an ambiguous response. If production returns 404 or 500 across releases, preserve the healthy recovery target and escalate with affected hostnames and request IDs—never secrets.
Help improve this page
Sign in to send page-specific feedback. For account-specific help, email support@blinkhost.me.