Event Driven Ansible, read at the source.

Event Driven Ansible entered general availability inside Ansible Automation Platform as the platform component that reacts to events from external sources. A rulebook defines a set of conditions; a source plugin connects to an external system that emits events; when an event satisfies a condition, an action runs. The action is typically a job template on the controller, which dispatches a playbook to an execution environment, which runs the playbook against a target host. The chain is event source, rulebook, action, playbook, target.1

The product surface is genuine. The architecture is non trivial. The commercial reading is straightforward. Event Driven Ansible is part of the Ansible Automation Platform subscription. It is not a separate metered metric. The same managed node count that governs scheduled automation governs event driven automation; the meter does not change because the trigger is asynchronous. For the meter itself, see the managed node counting article.

The buyer side reading is anchored at this point. Anything else the seller side proposal sheet asserts about Event Driven Ansible should be checked against this anchor before signature. For the wider Ansible Automation Platform practice context, see the Ansible Automation Platform practice hub.

The event source is the gateway between an external system and the rulebook engine. Sources are implemented as plugins that the buyer or a third party authors, with a standard catalog of certified sources shipped by Red Hat. Common sources include webhooks from external incident systems, message queues, observability streams, and cloud provider notification channels. The buyer that connects ten sources is not exposed to a tenfold increase in any metered metric, because event sources are not metered.

The rulebook is the declarative file that defines conditions and actions. Rulebooks are authored in YAML, registered with the platform, and evaluated by the rulebook engine. A buyer that maintains a hundred rulebooks across many teams is not exposed to a metric attached to rulebook count, because rulebooks are not metered.2

The action is typically a job template that already lives on the controller. The action triggers when a rule matches an event. The job template dispatches a playbook to an execution environment on an execution node, which runs the playbook against a target system in the existing inventory. The target system is the managed node at the far end of the connection. The managed node is the metric. The metric is unchanged.

Three traps recur on the Event Driven Ansible line in 2026 renewal proposals. The first is the event throughput uplift, where the proposal frames a higher tier of platform entitlement as required because event volume is forecast to grow. Event volume is not the meter. The platform tier turns on the managed node count, not on the count of events processed by the rulebook engine. A buyer that processes ten thousand events per day against fifty managed nodes is on the same tier as a buyer that processes a hundred events per day against fifty managed nodes.

The second trap is the source proliferation uplift, where the proposal frames each new event source as a chargeable addition. Sources are not metered. A buyer that connects a new webhook from an incident system is making an operational decision, not a commercial one. The seller side proposal that prices each source as a line item has misread the meter.3

The third trap is the rulebook engine sizing line, where the proposal frames the host running the rulebook engine as a chargeable addition. The rulebook engine runs on a host that, where the host is RHEL, carries a RHEL subscription on that host. The host does not carry an Ansible Automation Platform tier increment for hosting the engine. This is the same architectural point as the controller and executor reading: infrastructure footprint is not the platform meter. See the controller versus executor article for the wider treatment.

The audit posture on Event Driven Ansible follows from the meter. A compliance inquiry that finds high event throughput against a small managed node count is not a finding of platform under licensing. It is an observation of operational behavior. The platform tier should match the managed node count, which it should, and the event throughput is incidental to the meter. A buyer that responds to such a finding by accepting a higher platform tier has accepted a finding that the meter does not support.4

Where the buyer side response is structured correctly, the response separates the operational reading from the entitlement reading. The operational reading may show that the rulebook engine is busy, that more execution nodes would be useful, that the event source catalog is broad. None of those operational readings moves the meter. The defensible response reconciles managed node count to platform tier and concludes there. For the audit defense engagement, see audit defense; for the pre audit reconciliation, see the ninety day subscription assessment.

The corollary at renewal is that a clean platform agreement that already correctly reads the meter does not require a separate line for Event Driven Ansible. The component is part of the platform. The component should sit inside the platform tier. The component should not appear as a discrete chargeable line on the order form except where the buyer is purchasing optional surrounding content or services that are themselves discrete.

The buyer side reading at renewal proceeds in four steps. First, confirm that the platform tier read against the managed node count is correct. Second, refuse any line item that proposes to meter Event Driven Ansible by event throughput, source count, rulebook count, or rulebook engine host. Third, accept that the rulebook engine and execution nodes are RHEL hosts on the RHEL subscription record, separate from the platform tier. Fourth, sign the platform tier at the managed node count and treat any Event Driven Ansible operational sizing as a topology decision rather than a meter decision.5

Across recent practice engagements, the discipline has produced a recoverable correction on renewal proposals that surfaced event volume or source count as the basis for a tier uplift. Where the proposal already correctly read Event Driven Ansible as platform internal, the correction was smaller and the conversation moved to the multi year structuring. Either way the structural separation between event surfaces and the managed node meter is the reading that holds at signature and at the next audit.

For the renewal engagement, see renewal negotiation; for the wider practice context, see the Ansible Automation Platform practice hub; for direct contact, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.