unclassified.synth, unclassified.image_build, or unclassified.ecs_stabilise. The phase vocabulary is preflight, credentials, synth, bootstrap, image_build, image_push, cloudformation, ecs_stabilise, and platform.
Why this happens
Fjall classifies failures by reading structured error sources, such as CloudFormation stack events and ECS service events. When no structured source survives to the point where the deployment terminates, there is nothing to classify against, so Fjall records the failure as unclassified. The record is not empty. It still carries the failure detail, a masked excerpt of the first error window from the logs, and the full event stream stays available on the deployment’s detail page.Unclassified rates are tracked. When a failure shape recurs often enough, it
earns its own code, and stored failures can be reclassified under it.
How to fix it
- Read the failure detail and the masked log excerpt. They quote the first error the pipeline hit, which is usually the root cause.
- If the code carries a phase suffix, narrow your investigation to that phase. A failure in
image_buildpoints at your Dockerfile and build inputs, whilecloudformationpoints at the stack update. - Open the deployment on fjall.io to read the full event stream and log output around the excerpt.
- Use the Explain action on the deployment’s detail page for an AI readout of the failure.
- Fix what the readout points at, then run
fjall deployagain.
What Fjall shows you
The failure surfaces on the deployment’s detail page on fjall.io, in the CLI’s Error Detail block, and in the deployments list row title. The detail page carries the full event stream alongside the detail sentence and log excerpt.Related
Deployment safety
How Fjall contains and reports failed deployments.
fjall deploy
Deploy an application and read the CLI’s failure output.
fjall releases
Check the state of your deployments from the CLI.
Deploy an application
The full deployment pipeline, phase by phase.