Skip to main content
CloudFormation reported a timeout, a refused connection, or an unreachable network while working on a resource. Fjall groups all three under cfn.timeout, its network category, so the detail sentence on the deployment reads “encountered network issues” rather than “timed out”. The failure came from your AWS account’s configuration, permissions, or limits, not from your application code and not from Fjall. Networking is the usual culprit.

​
Why this happens

Fjall raises cfn.timeout when CloudFormation’s status reason matches a timeout, a refused connection, or an unreachable network. The stalled resource is the most common of the three. Private subnets without a NAT gateway route, or without the relevant VPC endpoints, leave ECS tasks, Lambda functions, and custom resources unable to call AWS APIs, so they never signal readiness.

​
How to fix it

  1. Find the resource named in the failure. Fjall’s stack analysis names the root cause resource on the deployment’s detail page and in the CLI failure block.
  2. Read the provider reason on that page. It quotes CloudFormation verbatim and tells you which of the three conditions fired.
  3. Check the outbound path from that resource’s subnets. Private subnets need a NAT gateway route, or VPC endpoints for the services the resource calls (ecr.api, ecr.dkr, s3 and logs for an ECS task pulling an image and writing logs).
  4. Check the security groups and NACLs at both ends. A refused connection means the packet arrived and was rejected, so read the port rules before you touch routing.
  5. Confirm the target is listening. A database, cache, or sidecar that never started refuses connections from a correctly routed client.
  6. Retry the deploy once the path is fixed:
CloudFormation runs the operation again from a clean state, and the resource stabilises if the network path now works.

​
What Fjall shows you

The failure surfaces on the deployment’s detail page on fjall.io, in the CLI, and in the deployments list row title. The detail page carries the stable code, a per-occurrence detail sentence, the provider’s verbatim reason, the remediation steps, and the root cause resource from the stack analysis. An interactive CLI run prints the failure block under a red heading, Deployment failed for fjall deploy. Running with --non-interactive prints the same fields under an Error Detail divider:
Fjall appends one resource-specific remediation step when the root cause resource is an IAM, Lambda, or ECS resource.

​
Next Steps

Deployment safety

How Fjall protects your stacks during a deploy.

fjall deploy

Command reference for deploying an application.

fjall releases

Inspect the state of your deployments from the CLI.

Deploy an application

The full deploy workflow from build to live.