Chapter 8. Rulebook activations troubleshooting


Occasionally, rulebook activations might fail due to a variety of reasons that can be resolved. In many cases, log filtering provides information that could be helpful in determining the cause of activation failure.

For improved log filtering, there are two different tracking IDs available for troubleshooting after an action is performed (for example, when you initiate a rulebook activation). Both tracking IDs are universally unique identifiers (UUIDs):

  • Log tracking ID [tid]- Created for each activation and persists across all activation instances. It allows users to track the complete history of an activation and its lifecycle. The Log tracking ID can be retrieved from the activation instance logs under the History tab.
  • X-request-ID [rid] - A standard HTTP header that is returned to the user as part of the HTTP response. If you want to fetch this ID, you must inspect the HTTP response headers. This ID results from actions such as triggering a restart of an activation. It allows tracking of a specific API request from platform gateway to Event-Driven Ansible controller.

You can use both tracking IDs to locate specific log entries in your backend logs (for example, API or worker logs).

Review the list of possible issues that can cause activation failures and suggestions on how you can resolve them.

8.1. Activation stuck in Pending state

Perform the following steps if your rulebook activation is stuck in Pending state.

Procedure

  1. Confirm whether there are other running activations and if you have reached the limits (for example, memory or CPU limits).

    1. If there are other activations running, terminate one or more of them, if possible.
    2. If not, check that the default worker, Redis, and activation worker are all running.
    3. If all systems are working as expected, check your eda-server internal logs in the worker, scheduler, API, and nginx containers and services to see if the problem can be determined. These logs reveal the source of the issue, such as an exception thrown by the code, a runtime error with network issues, or an error with the rulebook code. If your internal logs do not provide information that leads to resolution, report the issue to Red Hat support.

8.2. Activation keeps restarting

Perform the following steps if your rulebook activation keeps restarting.

Procedure

  1. Log in to Ansible Automation Platform.
  2. From the navigation panel, select Automation Decisions Rulebook Activations.
  3. From the Rulebook Activations page, select the activation in your list that keeps restarting. The Details page is displayed.
  4. Click the History tab for more information and select the rulebook activation that keeps restarting. The Details tab is displayed and shows the output information.
  5. Check the Restart policy field for your activation.

    There are three selections available: On failure (restarts a rulebook activation when the container process fails), Always (always restarts regardless of success or failure with no more than 5 restarts), or Never (never restarts when the container process ends).

    1. Confirm that your rulebook activation Restart policy is set to On failure. This is an indication that an issue is causing it to fail.
    2. To possibly diagnose the problem, check the YAML code and the instance logs of the rulebook activation for errors.
    3. If you cannot find a solution with the restart policy values, proceed to the next steps related to the Log level.
  6. Check your log level for your activation.

    1. If your default log level is Error, go back to the Rulebook Activation page and recreate your activation following procedures in Setting up rulebook a activation.
    2. Change the Log level to Debug.
    3. Run the activation again and navigate to the History tab from the activation details page.
    4. On the History page, click one of your recent activations and view the Output.

If your rulebook activation is running but not processing events, the most common cause is a mismatch between the expected event source and the source defined in the rulebook.

Procedure

  1. Check the rulebook source: Review the source plugin defined in your rulebook YAML (for example, ansible.eda.webhook, ansible.eda.kafka).
  2. Verify event input: Confirm that the events you are sending to Event-Driven Ansible controller are compatible with the source plugin defined in the rulebook. If the rulebook expects a Kafka message, it cannot process a generic webhook event.
  3. Confirm activation mapping: If you are using event streams, ensure the correct event stream is mapped to the rulebook during the activation setup. A mismatch here will result in the activation receiving no data.

If your rulebook activation is Running and successfully receiving events, but no actions are being executed, the issue is likely within the logic of your rulebook.

Procedure

  1. Check rule conditions: Review the rulebook YAML to confirm that the conditions (the when statements) are accurately written and precisely match the structure and values of the incoming event payload.
  2. Verify indentation and syntax: Ensure all rulebook syntax and indentation are correct, as a simple error can prevent the rule engine from evaluating conditions.
  3. Validate actions: Confirm that the specified action is a recognized and correctly configured action (for example, run_job_template with the proper arguments).

If you are using event streams to send events to your rulebook activations, occasionally those events might not be successfully routed to your rulebook activation.

Procedure

  • Try the following options to resolve this.

    1. Ensure that each of your event streams in Event-Driven Ansible controller is not in Test mode . This means activations would not receive the events.
    2. Verify that the origin service is sending the request properly.
    3. Check that the network connection to your platform gateway instance is stable. If you have set up event streams, this is the entry of the event stream request from the sender.
    4. Verify that the proxy in the platform gateway is running.
    5. Confirm that the event stream worker is up and running, and able to process the request.
    6. Verify that your credential is correctly set up in the event stream.
    7. Confirm that the request complies with the authentication mechanism determined by the set credential (for example, basic must contain a header with the credentials or HMAC must contain the signature of the content in a header, and similar).

      Note

      The credentials might have been changed in Event-Driven Ansible controller, but not updated in the origin service.

    8. Verify that the rulebook that is running in the activation reacts to these events. This would indicate that you wrote down the event source and added actions that consume the events coming in. Otherwise, the event does reach the activation but there is nothing to activate it.
    9. If you are using self-signed certificates, you might want to disable certificate validation when sending webhooks from vendors. Most of the vendors have an option to disable certificate validation for testing or non-production environments.

You might experience a failed connection to automation controller when you run your activations.

Procedure

  1. To help resolve the issue, confirm that you have set up a Red Hat Ansible Automation Platform credential and have obtained the correct automation controller URL.

    1. If you have not set up a Red Hat Ansible Automation Platform credential, follow the procedures in Setting up a Red Hat Ansible Automation Platform credential. Ensure that this credential has the host set to the following URL format: https://<your_gateway>/api/controller
    2. When you have completed this process, try setting up your rulebook activation again.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat