Having trouble? We’re here to help.

First, contact

You may be instructed to use the fugue support command. If so, check out the support documentation. If you’re looking for information about the actions Fugue is taking take a look at notifications.

Below, we’ve provided guidance for possible issues, along with some general troubleshooting tips.

You can also find known issues in our release notes.

Troubleshooting fugue init

Error: Cannot access Conductor AMI

In this case the fugue init command generates the error “You do not have access to the ami-xxxxxxxx conductor.”

Error message:

$ fugue init --ami ami-xxxxxxxx us-east-1

[ fugue init ] Initializing Fugue project with the following configuration:

Fugue Conductor AMI ID: ami-xxxxxxxx.
AWS Credentials: Profile (default)
Region: us-east-1

Validating Fugue Conductor AMI ID ...
[ ERROR ] You do not have access to the ami-xxxxxxxx conductor in region 'us-east-1'.


  • The account associated with the current AWS profile has not been whitelisted for access to the Fugue Conductor AMI in the specified region.
    • You may be using a non-whitelisted AWS account.
    • You may have specified an unsupported region for Conductor installation. (See list of supported regions below.)
    • You may have specified a nonexistent AMI, or a Conductor AMI from a different region.


  • Verify that your AWS account ID appears correctly in your list of Conductors in the Download Portal. If it does not, select the “Edit” button to update the account ID.
  • Ensure whatever profile you use is associated with a whitelisted AWS account. The AWS profile may be set via environment variables FUGUE_AWS_CREDENTIALPROFILE (which takes precedence) or AWS_DEFAULT_PROFILE. It also may be set via config file fugue.yaml by using the field credentialProfile in the aws block.
  • Double-check the AMI ID you entered. You can find the AMI ID for your account and region by logging in to the Download Portal.

You can also check out Hello World, Part 1: Fugue Quick Setup for additional information on setting up your account and the associated environmental variables.

Important Note:

The Fugue Conductor may only be installed in the following regions:

  • us-east-1
  • us-east-2
  • us-west-2
  • eu-west-1
  • us-gov-west-1

Troubleshooting fugue install

Error: `fugue.yaml` doesn’t exist

In this case the fugue install command generates the error “fugue.yaml doesn’t exist.” (Applies to Fugue v2017.11.28 and earlier)

Error message:

$> fugue install

[ ERROR ] config file /Users/test/fugue.yaml does not exist.
You can run "fugue init" to initialize your project.


The fugue.yaml was not created because you haven’t yet run fugue init to specify the profile and Fugue Conductor AMI you wanted to use.


Run fugue init to specify your profile and AMI, and then run fugue install.

You can also upgrade to a more recent version of Fugue. The init command and fugue.yaml file are now optional. You can install with your default AWS profile and configuration, or use environment variables to set non-default values. For more details, see Configure Fugue Settings in the Quick Setup.

Error: `CloudFormation stack` access

In this case the fugue install command generates the errors “User: <arn> is not authorized to perform: cloudformation:DescribeStacks on resource: <arn>” and “AWS CloudFormation stack creation failed.”

Error message:

$ fugue install

[ ERROR ] There was a problem executing this command.

   Reason: An error occurred (AccessDenied) when calling the DescribeStacks operation: User: arn:aws:iam::[AWS_ACCOUNT_NUMBER]:user/test_user is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:us-east-1:[AWS_ACCOUNT_NUMBER]:stack/fugue/*

Error message:

$ fugue install

[ fugue install ] Installing Fugue Conductor

Install Details:
   Conductor AMI ID: ami-xxxxxxxx
   AWS Account: test_user/[ACCOUNT NUMBER]
   Region: us-east-1

[ WARN ] Would you like to proceed with installing? [y/N]: y

Installing the Fugue Conductor into AWS account test_user/[ACCOUNT NUMBER].

FugueSubnet1                         Working...
FugueVpc                             Working...
FugueSubnet2RouteTableAssociation    Working...
FugueVpcGatewayAttachment            Working...
FugueAutoScalingGroup                Working...

Overall Progress  [#........................]    6%
[ HELP ] Exiting the install command while in progress (CTRL+C) will only stop progress tracking and *not* the install itself.
[ ERROR ] AWS CloudFormation stack creation failed.

Note: While the CLI currently indicates that (CTRL+C) will not stop the installation, we do not recommend using this command as it will interrupt the successful creation of credentials. In the event (CTRL+C) is used you can manually create your credentials using fugue support reset-secret. These recommendations will be updated in a future release.


  • In the first example, the profile you are using does not have the appropriate access to CloudFormation. Fugue requires CloudFormation access to create the infrastructure needed to run the Fugue Conductor.
  • In the second example, the AWS account you are using does not have sufficient permissions to install the infrastructure needed for the Fugue Conductor. In addition to CloudFormation, the account you use to install Fugue must have permissions to create, delete, and update all the infrastructure needed for the Fugue Conductor which includes any selected services and infrastructure you want Fugue to manage.


Update the profile you are using to install Fugue with the appropriate permissions for the services you are attempting to access or create (e.g. for CloudFormation you need to include: Describe, Create, Delete and Update)

Note: Details about Fugue’s policy on AWS Permissions IAM are available here.

Error: `A previous Conductor installation failed to uninstall`

In this case the error when using the fugue install command is “A previous Conductor installation failed to uninstall.”

Error message:

$ fugue install -y

[ ERROR ] There was a problem executing this command.

   Reason: A previous Conductor installation failed to uninstall.

   Details: The following resource(s) failed to delete: [FugueResourceEventsTopic].


Sometimes CloudFormation doesn’t delete correctly on uninstall, leaving the stack running in us-east-1.


Access the AWS console and go to CloudFormation in us-east-1 and delete the stack named FUGUE.

Troubleshooting fugue run

Error: `(403) Forbidden`

In this case the fugue run command generates a “(403) Forbidden” error.

Error message:

$ fugue run alarm.lw -a alarm
[ fugue run ] Running alarm.lw
Run Details:
    Alias: alarm

Compiling Ludwig file /Users/test/fugue/alarm.lw

[ OK ] Successfully compiled. No errors.

Uploading compiled Ludwig composition to S3...

[ ERROR ] There was a problem executing this command.

   Reason: An error occurred (403) when calling the HeadBucket operation: Forbidden

Error message:

fugue run HelloWorld.lw -a hello
[ fugue run ] Running /Users/test/fugue/HelloWorld.lw

Run Details:
    Account: default
    Alias: hello

Compiling Ludwig file /Users/test/fugue/HelloWorld.lw
[ OK ] Successfully compiled. No errors.

Uploading compiled Ludwig composition to S3...
[ ERROR ] unable to create S3 bucket fugue-xxxxxxxxxxxx-us-east-1 in region us-east-1: error 403


  • This error occurs when the account you are using doesn’t have access to the S3 bucket configured under compositionBucket in the fugue.yaml file or in the FUGUE_CONDUCTOR_COMPOSITIONBUCKET environment variable.
    • This can occur for a number of reasons. It can occur when the fugue.yaml file or FUGUE_CONDUCTOR_COMPOSITIONBUCKET environment variable is configured to use your default AWS profile instead of a named profile. If you switch the default profile in ~/.aws/credentials and then use the same folder and fugue.yaml file or FUGUE_CONDUCTOR_COMPOSITIONBUCKET value to install Fugue in the new default account it will not generate a new bucket name and will attempt to use the old bucket.
    • Another less common scenario is one where the bucket name auto-generated by Fugue already exists and is owned by a different account.


Create a new S3 bucket in the account you are using and then change the compositionBucket field in the fugue.yaml file or the value of the FUGUE_CONDUCTOR_COMPOSITIONBUCKET environment variable to point to that S3 bucket.

Error: `Fugue has timed out`

In this case the fugue status command indicates a “Fugue has timed out” error.

Error message:

$ fugue status

[ ERROR ] Fugue has timed out waiting for a response from the server.


  • Fugue Conductor and client versions are matched pairs which is why we release them together. If your Conductor and client are from different releases you may experience this error.
  • This also may be caused by delays in AWS queues and signifies nothing.


Use the fugue --version command to determine your versions of the client and CLI, along with the version of your Fugue Conductor AMI. This will allow you to determine if you are working with a matched pair. You can verify the pair via the Download Portal, or for additional assistance reach out to

Troubleshooting fugue update

Error: “ECS Services cannot be modified in-place”

The following error message shows in the output of fugue status [alias|FID]. The fugue status output will show a “Last Message” of FAILED.

Error message:

LastMessage: "400 Encountered an error while planning [There were multiple errors:\n\
  \tError processing ECS Service [my-service]: ECS Services cannot be modified in-place.\
  \ Please remove the Service first, by removing it from the composition and updating\
  \ the Fugue process [cd553a6a-793f-4344-98f6-8217dc17c26f], then create it again.]:\
  \ Planner returned an error"


This error message is encountered after using fugue update to add an ELB to an existing ECS service. With the exception of the mutable fields taskDefinition and deploymentConfiguration, ECS service properties cannot be changed once the service has been created, so an ECS service’s load balancer must be declared at service creation time. Attempts to update any process with an ECS service by adding an ELB will fail with the above error.


If you want to preserve the name of the ECS service:

  • Remove the service from the composition
  • Run fugue update on the process
  • Add the service back into the composition
  • Run fugue update on the process again

This will delete the ECS service and recreate it with the load balancer attached.

Note: You can comment out lines of Ludwig by prepending a # to each line.

If you don’t need to preserve the ECS service’s name:

  • Change the name of the service in the composition
  • Run fugue update on the process

This will delete the ECS service and recreate it with the new name, with the load balancer attached.

Troubleshooting fugue upgrade

Error: “The Conductor is in the process of installing”

In this case, running fugue upgrade produces the error “The Conductor is in the process of installing.” (Applies to Fugue v2015.05.23 and earlier)

Error message:

$ fugue upgrade ami-xxxxxxxx
[ fugue upgrade ] Upgrading Conductor

[ ERROR ] There was a problem executing this command.
   Reason: The Conductor is in the process of installing.

Explanation: The Conductor has not completed its installation process, and its CloudFormation stack is still in the CREATING or CREATED stage. This can also happen if the Conductor instance has been terminated and its Auto Scaling group is in the process of launching a new Conductor.

One other possibility is that a previous Conductor was not uninstalled properly, leaving behind some artifacts.

Solution: The Conductor takes 5-15 minutes to boot once its instance has been created. To find out whether the Conductor is up and running, follow the instructions here. Once the Conductor is finished booting, you may execute upgrade.

If the Conductor still hasn’t booted after 15 minutes and you are still receiving this error message, you may need to remove artifacts left behind from a previous Conductor. To effectively remove any such artifacts, execute the following command:

fugue uninstall --force


If you use the --force option with the uninstall command while processes are active/running you will receive a warning that any existing processes and infrastructure will be orphaned and will no longer be managed by Fugue.

In addition, if you suspect that the previous Conductor installation has left infrastructure running, please email Fugue Support ( before taking any further action. It is important to address these running workloads before attempting to uninstall a previous installation.

Other Possible Issues

Here are some other possible issues and error messages you may encounter when using Fugue.

RBAC policy error after upgrade

Error message:

[ ERROR ] Due to an attached RBAC policy, command 'ops' is not allowed for user 'alice'.

Explanation: You may encounter RBAC errors if you attach a policy to the Fugue Conductor and then upgrade the Conductor. For example, if you attach a policy that enables alice to have access to allAccountActions, then upgrade to a Conductor AMI that supports newer actions (such as the ops command, above), alice will not have access to the new actions. The proper order for upgrading the Conductor is:

Solution: Re-attach the RBAC policy:

fugue policy rbac-attach <policy_file>

This recompiles and reapplies the RBAC permissions so that allAccountActions and other Fugue.System.Policy types include actions available on the new Conductor. As long as you attach the same policy as before, each user and secret will remain the same.

Error: “This client and the Conductor are incompatible” on any CLI command

Error message:

[ ERROR ] This client and the Conductor are incompatible: client API version 4.0.4 is incompatible with server API version 3.2.4.

Explanation: The Fugue CLI and the Fugue Conductor form a matched set. If you’ve installed a version of the CLI that is not compatible with your current version of the Conductor, or vice versa, you’ll see this error message upon executing any CLI command.

Solution: Visit the Download Portal to confirm that you have installed the correct version of the CLI and the correct AMI ID of the Conductor. Recall that to upgrade Fugue, the new CLI needs to be installed before you execute the upgrade command. If you encounter problems, reach out to

Error: “Fugue requires an English UTF-8 console environment” on any CLI command

Error message:

Fugue requires an English UTF-8 console environment.

Explanation: This error indicates that the character encoding for the shell in use is not U.S. English UTF-8. In order to execute any Fugue command, the encoding must be U.S. English UTF-8.

Solution: You can change the default character encoding in your shell by executing export LANG=en_US.UTF-8, which changes the environmental variable $LANG to use U.S. English UTF-8. You can also add the line export LANG=en_US.UTF-8 to your .bash_profile or .bashrc file, or wherever you keep your shell configuration. This will automatically set your shell’s character encoding to U.S. English UTF-8.

Error: “Command is not supported” on any CLI command

Error message:

I'm sorry Dave. I'm afraid I can't do that.
[ ERROR ] This command is not supported by the Conductor currently installed.

Explanation: This error indicates a mismatched Fugue CLI and Fugue Conductor. The CLI and Conductor form a matched set, so if you upgraded the CLI to a newer version but did not upgrade the Conductor to the corresponding AMI ID, the CLI may support a command that the Conductor does not. In this case, attempting to run an unsupported command produces the above error message.

Solution: Visit the Fugue Download Portal to find the corresponding Conductor AMI ID for your version of the CLI, and then run fugue upgrade --ami <ami_id> with that AMI to upgrade the Conductor. See upgrade for more details.

Error: “AWS CloudFormation stack creation failed” on Fugue installation

Error message:

Installing the Fugue Conductor into AWS account <user>/<account number>.

FugueInternetRoute                   Working...
FugueSubnet2                         Working...
FugueSubnet1RouteTableAssociation    Working...
FugueSubnet2RouteTableAssociation    Working...
FugueAutoScalingGroup                Working...
FugueVpcSecurityGroup                Working...
FugueIam                             Complete
FugueSubnet1                         Working...
FugueResourceEventsTopic             Complete
FugueHealthCheckDb                   Working...
FugueVpcGatewayAttachment            Working...
FugueVpc                             Complete
FugueRouteTable                      Complete
FugueLaunchConfiguration             Working...
FugueVpcGateway                      Complete
FugueInstanceProfile                 Working...
Overall Progress  [#######..................]   31%

[ HELP ] Exiting the install command while in progress (CTRL+C) will only stop progress tracking and *not* the install itself.
[ ERROR ] AWS CloudFormation stack creation failed

In this case, you may have encountered a faulty AZ availability indication – a limitation of the AWS API that can “fool” Fugue’s installation command. To confirm you have this problem, take a look at the fugue CloudFormation stack event log after the failed installation. You should see a message about an invalid AvailabilityZone parameter.

Note: While the CLI currently indicates that (CTRL+C) will not stop the installation, we do not recommend using this command as it may interrupt the successful creation of credentials. These recommendations will be updated in a future release.

CloudFormation events typical of a Fugue installation where available AZs were incorrectly reported by AWS.

Example of erroneous events in this case.

To resolve this issue, follow the simple steps in this example. If you see a different error or are unsure if you are seeing this one, contact us at

Troubleshooting Ludwig errors

Error: “Specify either rootBlockDevice, volumes, and instance stores or blockDeviceMappings, but not both”

Error message:

ludwig (validation error):
  "/opt/fugue/lib/Fugue/AWS/EC2/Instance.lw" (line 284, column 17):
  Validations failed:

    284|   let resource: EC2.Instance {
    285|     keyName: keyName,
    286|     instanceType: instanceType,
    287|     monitoring: monitoring,
    288|     blockDeviceMappings: blockDeviceMappings,
    289|     tags: tags,
    290|     iamInstanceProfile: iamInstanceProfile,
    291|     ebsOptimized: ebsOptimized,
    292|     image: image,
    293|     disableApiTermination: disableApiTermination,
    294|     instanceInitiatedShutdownBehavior: instanceInitiatedShutdownBehavior,
    295|     userData: encodedUserData,
    296|     primaryNetworkInterface: primaryNetworkInterface,
    297|     secondaryNetworkInterfaces: secondaryNetworkInterfaces,
    298|     rootBlockDevice: rootBlockDevice,
    299|     volumes: volumes,
    300|     instanceStores: instanceStores,
    301|   }

    - Specify either rootBlockDevice, volumes, and instance stores or blockDeviceMappings, but not both. It is recommended to avoid using blockDeviceMappings as that field will be deprecated in a future release
      (from Fugue.AWS.EC2.Instance.newOrOldVolumeSupport)

  Stack trace:
    In call to newWithNetworkInterfaces at "/opt/fugue/lib/Fugue/AWS/EC2/Instance.lw" (line 160, column 3)
    In call to new at "MixedEBS.lw" (line 16, column 21)


This validation error indicates that a composition mixes the old style of specifying EBS volumes of EC2 instances (EC2.InstanceBlockDeviceMapping) with the new style (EC2.RootBlockDevice, EC2.InstanceStore, EC2.Volume) in the same binding. A composition may contain EBS specifications in the new style or the old style; it cannot contain both styles in separate bindings, and it cannot contain both styles within the same binding. The latter produces this error on compilation.

This is the binding that caused the error:

myNewStyleInstance: {
    instanceType: EC2.T2_micro,
    subnet: mySubnet,
    securityGroups: [mySecurityGroup],
    image: "ami-e689729e", # Amazon Linux
    rootBlockDevice: myNewStyleRootVolume,
    volumes: [{volume: myNewStyleVolume, deviceName: "/dev/xvdb"}],
    instanceStores: [{deviceName: "/dev/xvdc", virtualName: "ephemeral0"}],
    blockDeviceMappings: [
        EC2.InstanceBlockDeviceMapping {
            deviceName: "/dev/xvda",
            ebs: EC2.EbsInstanceBlockDevice{volume: myOldStyleRootVolume},

Note the use of the rootBlockDevice, volumes, instanceStores, and blockDeviceMappings fields.


Select an EBS specification style and use it consistently within the composition. The new style is recommended because the old style is deprecated. However, Fugue honors the old style for backwards compatibility.

In this example, the user could remove the blockDeviceMappings field (old style), leaving rootBlockDevice, volumes, and instanceStores (new style) to ensure the composition compiles and passes validation.

For more information, and to see code examples of the old style and new style, see Writing Ludwig.

Troubleshooting Tips

This section covers generalized troubleshooting in the Fugue system.

Check the CLI Log

A good place to start troubleshooting is the CLI log. There, you’ll find the full error message, along with the context surrounding it. In this case, during fugue init we’ve given the CLI an AMI ID that does not exist, and we can confirm this by checking the very end of fuguecli.log:

2018-03-16T18:22:07.03 [ fugue.screen ] INFO - Fugue Conductor AMI ID: ami-00000000.
2018-03-16T18:22:07.03 [ fugue.screen ] INFO - AWS Credentials: Environment variables
2018-03-16T18:22:07.03 [ fugue.screen ] INFO - Region: us-east-1
2018-03-16T18:22:07.03 [ fugue.screen ] INFO - Validating Fugue Conductor AMI ID ...
2018-03-16T18:22:07.03 [ fugue ] DEBUG - attempting lookup for 'ami' by environment 'FUGUE_CONDUCTOR_AMI'
2018-03-16T18:22:07.03 [ fugue ] DEBUG - environment lookup failed 'FUGUE_CONDUCTOR_AMI', attempting config lookup
2018-03-16T18:22:07.03 [ fugue.screen ] ERROR - You do not have access to the ami-00000000 conductor in region 'us-east-1'.
Traceback (most recent call last):
  File "site-packages/fugue_cli/", line 242, in invoke
  File "site-packages/click/", line 1060, in invoke
  File "site-packages/fugue_cli/", line 214, in invoke
  File "site-packages/click/", line 889, in invoke
  File "site-packages/click/", line 534, in invoke
  File "site-packages/click/", line 27, in new_func
  File "site-packages/fugue_cli/commands/", line 65, in init
  File "site-packages/fugue_cli/commands/", line 121, in base_init
  File "site-packages/fugue_cli/provider/", line 375, in validate_image
fugue_cli.amis.AMINotFound: You do not have access to the ami-00000000 conductor in region 'us-east-1'.

Should this particular error happen to you, it’s worth checking the Fugue Download Portal to make sure you have the latest AMI ID. If the AMI ID is correct, make sure you entered the region correctly. AMI IDs are only valid for one region, so if the Conductor is configured to run in a different region than your AMI, the same error is triggered.

Increase CLI Verbosity

The CLI log doesn’t append extra information for all errors, but there’s another way to find more information. Any Fugue command can be executed in verbose mode by using the global -v option. The option increases the verbosity incrementally, so -vvv shows more detail than -v. With increased verbosity, the CLI displays considerably more data that may be useful in troubleshooting, including the precise messages the CLI sends to the Conductor and the responses AWS returns.

Check CloudWatch Logs

Fugue’s CloudWatch logs may also provide useful context for troubleshooting. The /fugue/conductor log group contains all Fugue’s log streams, including three of particular note. Audit logs keep track of commands that are run in response to a user action or as part of an enforcement action. They’re more human-readable than other logs, and they’re located in the audit log stream. Broker logs show Fugue’s AWS API calls and are in fugue-broker. Manager logs show detailed plans of action and are in manager. For more information, see Logging & Notifications.

Check Ludwig Compiler Messages

When a composition fails compilation, the Ludwig compiler (lwc) produces a helpful error message. For example, if you were to use the erroneous region AWS.Us-west-3 in a composition, you’d see the following error:

ludwig (scope error):
  "HelloWorld.lw" (line 13, column 11):
  Not in scope:

    13|   region: AWS.Us-west-3,

  Constructor not in scope: AWS.Us-west-3

    perhaps you mean one of:
      AWS.Us-west-2 (from Fugue.Core.AWS.Common)
      AWS.Us-west-1 (from Fugue.Core.AWS.Common)

Along with the useful error message “Constructor not in scope: AWS.Us-west-3,” the compiler suggests two types that you might have meant, AWS.Us-west-2 and AWS.Us-west-1.

If you come across an error message that seems unclear, reach out to

To learn more about Ludwig, see Ludwig Guide. Or watch our short video about lwc, Compiler Errors Are a Feature.

Email Us

Finally, you can always send an email to describing your issue, and we’ll be happy to help you.

Recovery From Provider Downtimes

In the rare event that provider platforms we support experience downtimes, we will place instructions on recovery from those downtimes here. We designed Fugue to be resilient and fail gracefully in the event of dependent service outages. In short, the system is designed to keep running if possible, and save state and “wait out the storm” if it is not. In the latter case, some human intervention may be required to judge when it is safe to resume normal operation.

Entries here should be helpful not only for a particular incident, but also similar incidents that might occur on a smaller scale.

February 28th, 2017: AWS S3 Increased Error Rates

AWS experienced high error rates for the S3 service in the us-east-1 region, which impacted several other services as well.

We found that, as designed, Fugue Conductors put all processes into the Suspended state during this outage. This state means that the Conductor retains all process information, but remains hands-off. This is the safest response to a provider control plane failure, since we cannot be sure of infrastructure state or the consistency of changes we might try to make. You can read more about Fugue’s process model here.

Recovery from this state is simple. You can just use the resume command like this:

$ fugue resume -y (<alias> | <FID>)

This will resume the processes one at time. If you wish, it is safe to resume all processes at once with the following command:

$ for fid in $(fugue status --json | jq -r .[].fid); do fugue resume -y $fid; done

As S3 service recovered, some processes we resumed re-entered suspension due to continued AWS API errors. If this happens in any future incidents, we recommend you wait at least a few minutes — or until there is some more news about the incident — and try again.