Tracking is configured on the Application, in the Tracking dropdown on the Application dialog, alongside the Application’s Name, Namespace, and Description. One setting, with three values ordered from lightest to most detailed, governs every port that Application owns. A port editor has no tracking field:

Where to change it. Open the Application, and the Tracking dropdown is the third field on the Application dialog. Pick a level and Save, and it governs every one of the Application’s ports. There is no Tracking field in the port editor. See Applications for the rest of the dialog and for what else the Application governs.

Tracking is filtered by the Selected Application. With a Selected Application set, every count and every row on the Tracking screen is restricted to that Application. With no Selected Application, the screen spans every Application the user has access to. The behaviour matches every other artifact list in the platform.

The filter reflects something stronger than a view preference: a tracked run belongs to the Application whose ports recorded it, the same way a port or a map belongs to it. That ownership is what makes the lifecycle work the way it does. Deleting the Application deletes its tracking data along with its artifacts and its private bus, and a snapshot will not bring it back, because snapshots carry configuration and never tracking history.

The Tracking screen is laid out in three regions, top to bottom, status boxes, a filter strip, and a results grid.

1. Status boxes. Five boxes at the top, each showing a status name and a live count: Successful Running Suspended Exceptions Errors. Clicking a box loads the matching records into the grid below; the same box also exposes an action menu that applies to the entire count at once (see Actions).

2. Filter strip. A row of filters that narrow what the grid shows: Tracking ID, Start Date, End Date, and Message Type. Filters compose with the active status box and with the Selected Application.

3. Results grid. One row per integration run, sortable by start time, with the originating port, message type, and start timestamp visible. Expanding a row reveals the run's full step-by-step history, see Step-by-step drill-down.

Actions are identical whether triggered on a single row or on the whole status box. The box variant applies the action to every record currently in that status, scoped by the active filters.

Expanding a row in the results grid exposes the full step-by-step history of that run, one line per step, in execution order, across every port the run touched. The columns are:

Each step in the drill-down carries a numeric Step ID, and the badge tooltip shows the stage it marks. A full two-way round trip spans two ports joined by the bus: the request enters through a receive port, is published, a send port picks it up and calls the external endpoint, and the reply returns through the send port and back out to the caller. The Step ID sets execution order, so the map and pipeline stages list in the order they run (a receive leg runs its pipeline before its map; a send leg runs its map before its pipeline). Most runs use only a subset.

Every integration run is stamped with a single Tracking ID when it enters the platform. The same ID flows through every port the run touches, which is what lets the screen reassemble one logical run from steps recorded by different ports. Use the Tracking ID filter on the top strip to recall the complete history of one specific run, for as long as that history still exists. Two limits apply: the run must still sit inside the retention window, since the nightly prune job removes anything older, and the Application that owns it must still exist, since deleting an Application deletes its tracking data outright. A Tracking ID that returns nothing has usually met one of the two, not been recorded wrong.