Engine diagnostics
Open Diagnostics from the sidebar to inspect the running FIX engine across tenants. This page is for simulator operators and platform administrators. Ordinary workspace access does not grant access to diagnostics.
Check the live feed first
The header reports whether the diagnostics feed is connecting, live, stale, or disconnected, together with the age of its last snapshot. A stale snapshot describes the last known state. It does not prove that a FIX session has disconnected.
If the page reports a lost diagnostics connection, select Retry. Wait for a fresh snapshot before using the displayed state to make a recovery decision. If the connection remains unavailable, check sign-in and API connectivity before restarting any FIX session.
Read engine vitals
| Readout | Meaning |
|---|---|
| Uptime | Time since the engine started. |
| Sessions | Logged-on sessions out of the total on the engine. |
| Throughput | Engine message throughput per second, with its recent trend. |
| Timer heap | Pending scheduled work, with its recent trend. |
| Memory | Managed memory in MB, with its recent trend. This is not total host memory. |
Timer heap and Memory receive an amber border when their displayed trend rises. A rising trend is a reason to inspect workload and progress; it is not a failure verdict on its own.
Find a session
The session list starts in By tenant mode. Expand a tenant or switch to By health to see sessions that need attention separately from healthy sessions. Filter by tenant name, sender or target CompID, or FIX version. The desktop list can be resized by dragging its right edge.
Select a session to open its detail pane. Check the tenant and FIX identity before using any controls: this is a cross-tenant view. The pinned summary shows health, logon duration, message counts, and last activity.
| Health | Interpretation |
|---|---|
| Healthy | Logged on, with neither the execution-report queue nor inactivity crossing the configured health threshold. |
| Degraded | Logged on, but queued execution reports or inactivity need inspection. Read the reason beside the status. |
| Offline | Not logged on. This is normal for an unused session. Recent rejected logons are called out separately in the reason. |
Health thresholds are server configuration. The inactivity check uses the configured heartbeat baseline; it does not read each connection's negotiated heartbeat interval.
Inspect the detail tabs
Orders shows the execution-report queue depth and orders with quantity, fill progress, status, and next scheduled work. If reports are accumulating, compare the queue with the receiving client's behaviour and the session's timing and rate controls. Use Blotter In and Blotter Out to inspect the actual FIX messages.
Timers shows pending scheduled work with countdowns and the associated ClOrdID, where present. Compare these with the timing configured in Sim Config. An empty list means no pending timers are reported for that session.
Logon shows recent attempts, source addresses, verified or rejected results, and available failure reasons. A session with recent logon failures opens on this tab automatically. Compare its identity and authentication details with the initiator's configuration and the connection troubleshooting guide.
Settings provides live runtime controls for Auto-acknowledge, Auto-accept cancels, Auto-accept replaces, Reject inbound, and Fill rate. Changing a control stages a proposal. Select Confirm to apply it or Cancel to discard it. Check the next live snapshot and any error banner after confirmation.
These settings affect the selected session's runtime overrides. They do not save its Sim Config baseline, and the tab does not display override inheritance. Use Sim Config to inspect saved policy, and Clear live overrides on Session Overview when the saved defaults should apply again.
Restart a session
Use Restart session, then Confirm restart, only after checking the selected tenant and session. The page also offers the restart control beside a non-healthy session's status explanation.
The diagnostics restart disconnects the client and performs a clean reset. It resets FIX sequence state and clears the session's orders, pending fills, runtime overrides, IOIs, queued outbound work, and duplicate client-order-ID tracking. This control has no preserve-state option. Record the evidence you need before confirming it.
After restart, verify that the session returns to the list, the client reconnects, and the logon and message counts reflect the expected recovery. Restart failed means the request did not complete successfully; inspect the current session state before trying again.
Keep a useful incident record
Record the tenant, full session identity, UTC time, feed freshness, health reason, queue depth, relevant ClOrdID, and logon failure reason. The page also displays notifications for logon failures, unexpected disconnections, and health changes. Dismissing a notification removes it from the display; it does not resolve the underlying condition.
If the problem is a suspended tenant or a capacity limit, use Tenant administration. Restarting a session does not change tenant policy.
Updated 2026-09-10 · Edit on GitHub