Event log

Task walkthrough: Use the event log. This page is the full configuration and troubleshooting reference.

The event log is the record of everything the platform processed — every event, where it came from, what it did, and whether it succeeded. It's the primary tool for tracing what happened and why across a chain of related actions.

What an event shows

List view: type, environment, status, source, User (who or what triggered it), received time, and processing duration. The type column shows the event's display name — the same name the job editor and the other event forms use, for example Hold Job — with the raw $JOB:HOLD beneath it, so you can read the list without translating codes and still have the exact type to hand. For an action a person took, User shows a human-readable name — the user's display name, or their email if there's no display name — falling back to the user id only when neither is recorded. For a person's own actions that name comes from their signed-in identity, so it can't be spoofed by the request.

Detail view adds: the Event ID, the Correlation ID (select it to see every event from the same action), the service it was Routed To, its Timestamps, the Payload, the State Changes it made (entity, field, previous → new value), and the Error (code + message) if it failed.

Statuses and sources

Field	Values
Status	RECEIVED, PROCESSING, COMPLETED, FAILED. The status filter also offers EXPIRED, but no event has that status in the current release
Source	API, CLI, AGENT, SCHEDULER, WEBHOOK, UI, JOB_EVENT

Events with source AGENT

AGENT means a legacy LSAM machine raised the event itself — a job or process on that machine wrote a file of event syntax into the agent's MSGIN directory. Such an event shows the machine name as its actor, plus the service account whose credential the line carried, as the identity system confirmed it. The event is checked against that account's roles, except for a line that uses the SYSTEM/MESSAGE compatibility pair. The payload holds the line as received, with its trailing credential pair removed and the token masked.

Two things about these events differ from the rest of the log, and both matter when you are trying to find out why an event file did nothing:

• A line refused before it became an event never appears here. A wrong field count, an unknown event type, or a machine with no Default event environment set is refused at the platform edge, so there is no row to find. An event that was accepted and then failed does appear, as FAILED.
• A stored properties value can be a placeholder. For $JOB:ADD, $JOB:ADDHLD, $SCHEDULE:BUILD and $SCHEDULE:BUILDHLD raised by an agent, a properties value is replaced with a placeholder before the event is stored, because event files are hand-written and can carry a password. The original value is not kept, so to run such an event again, raise it again from the machine.

See Events raised by a legacy agent.

A payload is stored as it was authored

An event's payload is kept as the author wrote it, [[…]] property tokens included. For an event raised from outside a job — source UI, API, CLI, WEBHOOK or AGENT — those tokens are resolved each time the event is processed, and the result is never written back. So the row you read shows the intent, not an earlier resolution.

An event whose token could not be resolved shows as FAILED, and its error names the token as authored and the field it sat in — never the value anything resolved to, since more people can read this log than can read the properties behind it. See An event raised from outside a job.

The same holds for an error that came back from somewhere else. An event whose tokens resolved fine and was then refused downstream carries that refusal as its error — and the service that refused it may well quote the offending value back, which would be the resolved property's value. Any value a token resolved to on this event is removed from the error before it is stored, including where the value has been changed in case or percent-encoded on the way, and where one value happens to contain another. So an event's error names what went wrong without reprinting what a property held.

Message-only events

$CONSOLE:DISPLAY exists to make a message visible in the log, and nothing else — there is no downstream action for it to take. It now completes: the event is recorded with its message and shows as COMPLETED. On earlier builds it was accepted and then logged as FAILED, so a message that had in fact been received read as an error.

note

This is the only event type that completes without doing anything downstream. An event type the platform can't act on still reports FAILED — a green row for one of those would say a machine had been taken out of service when it had not.

An event type can fail for two different reasons

Both read as FAILED, and the error tells you which you are looking at:

The error says	What it means	What to do
…is not yet supported / not yet implemented	The type is routed and is meant to work, but has no handler behind it yet. Ten types are in this state: $JOB:RESCHEDULE, $JOB:RESCHEDHLD, $JOB:USER, $JOB:MACHGRP, $SCHEDULE:START, $SCHEDULE:DELETE, $SCHEDULE:CHECK, $SCHEDULE:CHECKALL, $MACHINE:STATUS and $MACHINE:MAXJOBS	Wait for it, and use another route meanwhile
…is not supported on this platform and will not be applied	The type will not arrive. Eight $NOTIFY types are refused permanently: $NOTIFY:COMMAND, $NOTIFY:LOG, $NOTIFY:NETSEND, $NOTIFY:SNMP, $NOTIFY:SPOAL, $NOTIFY:SPOCO, $NOTIFY:TASKS and $NOTIFY:TEXTMSG	Remove the event, or replace it — the message says so. The one exception is $NOTIFY:TEXTMSG, still planned and waiting on an SMS transport

The difference is not cosmetic. A not supported refusal happens before the event resolves a token or reaches any service, so nothing was half-done and the producer is told to stop rather than retrying on a schedule. A Vision card refuses one of the eight when you save the card, and no event picker in the product offers them any more — though an event already saved with one still shows its stored type rather than reading as blank.

$NOTIFY:EMAIL is not in either list: it is carried out, and sends mail. See Sending mail with $NOTIFY:EMAIL.

A $JOB:ADD event reports one outcome per instance

A $JOB:ADD or $JOB:ADDHLD that names a multi-instance job adds several job instances at once, so it records one state change per instance, each under the projected <job>.<instance> name the rest of the run identifies it by. An instance that was refused because it is already running is recorded as such and does not fail the event — the job it asked for is there.

The event FAILEDs when an instance did not land, or landed in a state from which it can never start because its dependencies could not be recorded. A failed event keeps no state changes, so the message carries the whole picture instead: how many of the instances were added, which were not and why, which were added but will never start — those have to be removed and added again — and which were already running. Added instances are named with their IDs, because this is the only record of them the event leaves.

A partly failed add is not safe to submit again

Some instances were added before the failure, so raising the same event again would add the rest and attempt the ones that landed. Read the message, deal with the instances it names, and only then decide whether anything still needs adding.

An add that had nothing to report — a single instance that conflicts, or a fan-out where every instance does — is refused outright, and fails the event with no partial state to reconcile.

Filtering, correlation, and live view

The log shows events for the environment selected in the top bar, so switch environment there rather than on the page — the page no longer has its own environment list.

• Filters: status, event type, source, date range, and User (matches the actor's name or email).
• Event type is a multi-select picker over the catalog of known types, matched exactly. Selecting several matches events of any of them. It is no longer a free-text pattern, so a partial string won't match. The picker lists each type by its display name with the raw $TYPE as a hint, grouped by category in the same order the event forms use — so a type is in the same place here as it is where you authored it. Values sent to the server are still the raw types.
• A type the platform will never support is still filterable. Those events are stored as FAILED rather than refused outright, so they appear in the log and the picker lists them.
• The date range covers both the From and the To day, read in your own time zone rather than the platform's.
• Correlation: every event carries a correlation ID. Select it in the event's detail to open a view of all events that share it — follow a single action through everything it caused.
• Live polling: refresh every 5/10/30/60 seconds (10s default), with play/pause and manual refresh; page size 25/50/100 (50 default).

Good to know

• To trace an incident, start from a failed event and open its correlation view to see the full chain (the triggering action and everything it set off).
• A FAILED event's detail includes the error — the fastest place to see why something didn't process.
• There is no Retry in the event log. To run a failed event again, raise it again from where it came from: the workflow, the self service button, or the machine.

Contact support when

• An event is FAILED with no actionable error, or its State Changes don't match what actually happened in the system.

Include the event ID, correlation ID, type, status, and the error from the detail view.