# iRules event-order explainer

> Pick the profile stack on a BIG-IP virtual server — client-SSL, HTTP, server-SSL, pool — and see the order the common iRule events fire, from CLIENT_ACCEPTED to CLIENT_CLOSED, as a timeline and a list. All in your browser.

- Tool: https://ronutz.com/en/tools/f5-irules-event-order
- Family: Networking

---

## What it does

Choose the profile stack on a BIG-IP Standard (full-proxy) virtual server, whether it has a client-SSL profile, an HTTP profile, a server-SSL profile, and a pool, and the tool shows the order in which the common iRule events fire, from `CLIENT_ACCEPTED` through `CLIENT_CLOSED`, as both a timeline and a list. It is a model of documented F5 behaviour, computed in your browser; it never connects to a device.

## Why the order depends on the stack

An iRule is event-driven: your Tcl code runs when a named event fires, and which events fire, and in what order, is decided by the virtual server's configuration, not by the script. A full-proxy virtual server processes the client side and the server side as two separate connections, so the events walk through distinct phases: the client connection is accepted, the client-side TLS handshake completes, the HTTP request is parsed, a pool member is selected, the server-side connection is opened, the server-side TLS handshake completes, the request is sent, the response comes back, and finally both sides close. Change the stack and the set of events changes with it.

## What each profile adds

- **No profiles beyond a pool** leaves the connection-level events: `CLIENT_ACCEPTED` at the start, the load-balancing events when a member is chosen, `SERVER_CONNECTED` on the server side, and the `CLOSED` events at the end.
- **A client-SSL profile** adds the client-side TLS events, such as `CLIENTSSL_CLIENTHELLO` and `CLIENTSSL_HANDSHAKE`, before the request is processed.
- **An HTTP profile** adds the request and response events, `HTTP_REQUEST` on the client side and `HTTP_REQUEST_SEND` and `HTTP_RESPONSE` on the server side, so you can act on headers and payload.
- **A server-SSL profile** adds the server-side TLS events for the connection to the pool member.

The tool also places the conditional events, the data-collection paths and the load-balancing failure path (`LB_FAILED`), where they belong in the sequence.

## A note on multiple iRules

When two iRules both handle the same event, the order between them is not the order they are listed; it is controlled by the `priority` command within each event (F5 K12090273), with a default priority applied when none is set. That is a separate axis from the cross-event order this tool lays out.

## Using it

Toggle the profiles on your virtual server and read the resulting event sequence as a timeline and a list. It reflects F5's documented event model (the Master List of iRule Events and the per-event references), so it is a planning and learning aid, not a capture from a live system.

## Standards and references

- [F5 Clouddocs — Master List of iRule Events](https://clouddocs.f5.com/api/irules/Events.html) - event names and triggers
- [F5 Clouddocs — CLIENT_ACCEPTED](https://clouddocs.f5.com/api/irules/CLIENT_ACCEPTED.html) - connection-setup timing (Standard vs FastL4)
- [F5 Clouddocs — HTTP_REQUEST_SEND](https://clouddocs.f5.com/api/irules/HTTP_REQUEST_SEND.html) - server-side send ordering
- [F5 — K12090273: iRule priority command controls execution order](https://my.f5.com/manage/s/article/K12090273) - within-event priority
- [F5 DevCentral codeshare — iRule Event Order (captured sequence)](https://community.f5.com/kb/codeshare/irule-event-order/290961) - empirical event ordering

## Related reading

- [Client Side vs Server Side in iRules](https://ronutz.com/en/learn/irule-clientside-vs-serverside.md): A BIG-IP virtual server is a full proxy: it holds a separate connection to the client and to the pool member. iRule events run in one context or the other, and commands like IP::remote_addr return different things depending on which side you are on. Knowing the boundary prevents a whole class of confusing bugs.
- [FastL4 vs Standard: Which iRule Events You Get](https://ronutz.com/en/learn/irule-fastl4-vs-standard-events.md): A Standard virtual server is a full TCP proxy and exposes the rich set of L7 and SSL iRule events. A FastL4 virtual server is a packet-based fast path optimized for throughput, and it deliberately gives up most of those events. Choosing the profile is choosing which events exist.
- [iRule Event Order: The Connection Lifecycle](https://ronutz.com/en/learn/irule-event-order-explained.md): iRules are event-driven, and the events fire in a fixed order as the BIG-IP processes a connection: accept the client, finish the client TLS handshake, parse the request, pick a pool member, connect to it, finish the server TLS handshake, send the request, read the response, tear down. Knowing that order is the difference between an iRule that works and one that errors.
- [iRule Priority and Multiple Rules](https://ronutz.com/en/learn/irule-priority-and-event-order.md): Event order governs which events fire and when. The priority command governs something different: when several iRules (or several handlers) listen for the same event, which one runs first. The default priority is 500, lower numbers run earlier, and getting this right matters when one rule's output feeds another.
- [iRule SSL Handshake Events](https://ronutz.com/en/learn/irule-ssl-handshake-events.md): The client-SSL and server-SSL profiles add their own iRule events around the TLS handshake. CLIENTSSL_CLIENTHELLO fires before the handshake completes, which is what makes SNI-based profile and pool selection possible; CLIENTSSL_HANDSHAKE fires after. The server-SSL side mirrors them on the connection to the pool.
- [Protocol Profiles: Living TCP, Frozen TCP, and the Two Fast Paths](https://ronutz.com/en/learn/bigip-l4-protocol-profiles.md): The tcp dropdown hides three decisions. F5's 13.0 announcement split the full-proxy family into living profiles it continually updates (read-only, tuned via children) and a frozen legacy trio that still ships. FastL4 trades the proxy for a hardware packet path, and FastHTTP is the narrow HTTP case that must clear every criterion on its list.
- [What Makes an Event Fire: Provisioning and Profiles](https://ronutz.com/en/learn/irule-events-modules-and-profiles.md): An iRule event is only available if two things line up: the module it belongs to is provisioned, and the profile that produces it is attached to the virtual server. Some events need a third ingredient — an explicit collect command. Specify an event whose prerequisites are missing and there is no error; it simply never fires.