Event Log Reference
The event log on each adapter is the authoritative record of what the platform did to that adapter and when. Read it when an adapter is behaving unexpectedly, when a command did not take effect, or when you need to reconstruct what happened during a window of time.
This page explains the structure of a log entry and how to combine filters to reach the right entries quickly. It does not list every event message, because the text for Protocol events comes from the connector plugin rather than the platform. See Event descriptions come from plugins below.
Anatomy of an entry
Every entry has the same four fields. Read them in order: the first two decide whether the entry is worth your attention; the last two tell you what happened and why.
| Field | What it carries | How to use it |
|---|---|---|
| Severity | How urgent the entry is: Info, Warning, or Error. | Filter to narrow the log to entries that matter during an incident. |
| Taxonomy | Which surface of the adapter produced the entry: Protocol, System, Security, or Audit. | Filter to the surface you suspect. |
| Message | A plain-English line describing the event (labeled Message in the log and detail view). | Read to understand what happened. For Protocol entries the text comes from the connector plugin; Audit and System text is platform-owned. |
| Metadata | Optional structured context (session identifier, target destination, a reason reported by the external system, and so on), shown as Metadata in the detail view. | Expand before acting on any error-level entry. It almost always names the cause. |
What each Severity means for an operator
| Severity | Practical meaning |
|---|---|
Info | Routine activity the platform wants you to be able to reconstruct after the fact: sessions opened, commands accepted, sessions closed cleanly. Skim for context. Do not act on individual entries. |
Warning | An operation completed, but the platform flagged something: a retry succeeded, a non-fatal configuration mismatch, an unusual but non-error condition. Review on the next regular check. A cluster of warnings is often the lead indicator for the error that follows. |
Error | An operation failed. Something you asked for did not complete, or a session transitioned into a failed state. These are the entries an on-call operator acts on. |
What each Taxonomy means
| Taxonomy | What it covers |
|---|---|
Protocol | Everything the adapter does to open, maintain, or close a session with the external system. Connections established or refused, reconnects, sessions ended by the external system, and protocol-level errors the external system reports in the plugin's own vocabulary. |
System | Platform-level events that are not tied to a specific session or a specific operator command. Rare in normal operation. A System-taxonomy error usually means the platform itself hit a condition that needs attention. |
Security | Access and authentication-related events. |
Audit | Operator actions on the adapter, such as enabling or disabling it and updating its configuration. Each action is recorded as a single entry naming the actor and the time. |
Event descriptions come from plugins
For Protocol-taxonomy entries, the Message text is emitted by whichever connector plugin is managing the connection, so two adapters built on different plugins produce different text for the same conceptual situation. Audit and System entries use a fixed, platform-owned vocabulary.
For the exact descriptions a plugin can emit, and the protocol-level errors each one represents, read the plugin's own reference material under Official Plugins.
This is deliberate. Plugin-provided Protocol events let each connector surface the full precision of its protocol in the protocol's own vocabulary. The Portal supplies the schema (Severity, Taxonomy, Message, Metadata); for Protocol events the plugin supplies the content, while Audit and System content is platform-owned.
The practical consequence for you: the event log is a conversation between you and the plugin. Use the Portal to filter and locate; use the plugin's documentation to interpret.
How to investigate
The event log is most useful under pressure. Use these recipes when the Portal is open and you need answers fast.
Start with Severity
Set the Severity filter to Error first. A stream of routine Info entries can bury the one Error line that explains the incident. An empty result under Error is also useful: if nothing is at Error, the problem may be upstream of the adapter (the source has stopped sending) rather than inside it.
Narrow by Taxonomy
With Severity at Error, restrict Taxonomy to the surface you suspect.
| Suspected problem | Filter combination | What the narrowed result tells you |
|---|---|---|
| Connection went down or never came up | Severity = Error, Taxonomy = Protocol | Connections that could not be established, refused connections, dropped sessions. The Details field names the specific cause. |
| An operator command did not take effect | Severity = Error, Taxonomy = Audit | Rejected commands. The Description names the command; the Details name why the adapter refused or could not complete it. |
| Adapter is in Error with no obvious connection or command cause | Severity = Error, Taxonomy = System | Platform-level failures outside any single session or command. |
| An adapter is Active but traffic is not flowing | Severity = Warning, Taxonomy = Protocol | Warnings often precede a traffic-stopping error by a noticeable margin. |
Add a time range when the incident started at a known clock time. A five-minute window around the failure usually carries everything you need.
Expand Details before acting
For every error you intend to act on, expand Details. The Description tells you what happened at the level of the event; the Details tell you why. Acting on the Description alone routinely sends the on-call operator fixing the wrong thing.
Work the timeline
The entry immediately before the first error is often more informative than the error itself. A failure to establish a connection preceded by routine connection info entries reads differently from one preceded by no attempt at all. Expand the log window and read forward from the last known-healthy state.
Cross-reference the plugin documentation
Once you have the Description and Details, look up the plugin that owns the connection in Official Plugins. Plugins document their protocol-level error vocabulary and the remediation for each one.
What is not in the event log
The event log records operational events: connection state changes, operator commands, and system-level errors. It does not show individual protocol messages (orders, executions, market data). Where those are retained depends on the connector: some plugins keep a message log, reachable from the adapter detail page, while others leave the messages in the source or broker they came from. See the Official Plugins documentation for whether your connector keeps one.
See also
- Monitoring: how to read Status, the console, and metrics.
- Official Plugins: per-plugin reference material for the descriptions the log can carry.
- Troubleshooting: platform-level diagnostics beyond the event log.