Skip to main content
The deployment failed, and Fjall could not match the failure to a named error code. The cause could not be attributed automatically. It may sit in your AWS account, in your application’s code, or on Fjall’s side. The record is not empty. It carries the failure detail sentence, the phase the failure was located in, and, on the deployment page, a masked excerpt of the first error window from the captured output. The full event stream stays available on the deployment’s detail page.

​
Read the phase suffix first

A bare unclassified means the pipeline phase could not be located either. When the phase is known, the code carries it as a suffix, and that suffix is the fastest way to narrow the search. Every suffix resolves to this page. unclassified.image_build points at your Dockerfile and build inputs, unclassified.cloudformation points at the stack update.

​
Superseded rollouts: unclassified.ecs_stabilise

unclassified.ecs_stabilise is the one code on this page with a precisely known cause. Do not read the log excerpt for it, read this section instead.
Fjall watches one specific ECS deployment for the revision it just shipped. unclassified.ecs_stabilise means the service’s primary deployment changed to a different one while that rollout was still in flight. Something else took over the service, so the verdict Fjall reached is about a rollout that no longer exists. The detail on the record says so directly, in the sentence ECS replaced the in-flight deployment before it completed. The detail is a semicolon-joined list of reasons, so ECS’s own rollout-state reason can precede that sentence and a stopped-task count can follow it. Match on the sentence, not on the whole field. Two things cause it:
  • CloudFormation rolled the stack back. The stack update failed elsewhere and AWS restored the previous task definition, which starts a new ECS deployment on top of the one Fjall was watching.
  • A second deploy started. A concurrent fjall deploy, a CI run, or a rollback superseded this one.
The code is deliberately unclassified because the outcome is genuinely unknown from this deploy’s point of view. The revision it shipped may have been healthy, and the service may now be running a perfectly good version. A health-check failure, a tripped circuit breaker, or stopped tasks would each have been classified under their own ECS code before this one was reached.

​
How to fix a superseded rollout

  1. Find the deployment that superseded this one. Run fjall deployments list and look for a deployment overlapping this one’s window.
  2. Check what is actually running now. fjall releases <app> lists the recorded releases and marks the current one, and fjall status <app> reports deployment health.
  3. If a CloudFormation rollback caused it, read the stack events on the deployment’s detail page. The rollback has its own root cause, and that cause is the real failure.
  4. Once the service is quiet, deploy the revision you intended:

​
Why the other codes are unclassified

Fjall classifies failures by reading structured sources it already holds: 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 the failure is recorded as unclassified and located to a phase instead. These records carry no remediation bullets, because there is no known shape to write remediation for. The detail sentence and the log excerpt are the evidence.
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

  1. Read the failure detail and the masked log excerpt. They quote the first error the pipeline hit, which is usually the root cause.
  2. Narrow your investigation to the phase in the suffix, using the table above.
  3. Open the deployment on fjall.io to read the full event stream and log output around the excerpt.
  4. Use the Explain action on the deployment’s detail page for an AI readout of the failure.
  5. Fix what the readout points at, then deploy again.

​
What Fjall shows you

On the deployment’s detail page on fjall.io:
  • The title Deployment failed and the code, including any phase suffix
  • The per-occurrence detail sentence
  • A line stating that the cause could not be attributed automatically
  • The provider’s verbatim reason, when one was captured and differs from the detail
  • A link back to this page
  • The masked log excerpt behind a show-details toggle, when an excerpt was captured
The CLI prints the same fields in its Error Detail block after a failed fjall deploy, without the excerpt. The deployments list shows the title on the deployment’s row.

​
Next Steps

Deployment error codes

Every code Fjall ships, with its cause and remediation.

Deployment safety

How Fjall contains and reports failed deployments.

fjall deploy

Deploy an application and read the CLI’s failure output.

fjall releases

Check what is currently running after a superseded rollout.