Understanding Event Time
This section explains how Alert Manager Enterprise (AME) determines and adjusts an event’s Event Time.
Default Event Time
When a Splunk search is scheduled for periodic runs, it’s sent to the scheduler, which prioritizes jobs based on settings in savedsearches.conf and limits.conf.
Once executed, the search job includes metadata with key details, viewable in the Job Inspector or via the /services/jobs/<sid> endpoint.
For a Splunk Alert with an AME Alert Action, the Alert Action uses the searchTelemetry timestamp for maximum precision (note: the Job Inspector UI omits milliseconds).
This timestamp becomes the Event Time, displayed in the first column of the Event Summary and the Alert Time column in the Data tab.
Timezones
Like Splunk, AME stores all timestamps in UTC Epoch format. The displayed time reflects the timezone set in a user’s Splunk preferences.
Selecting -- Default System Timezone -- sets the timezone to UTC.
Why UTC for Default System Timezone?
Converting an operating system’s timezone to IANA format in JavaScript is unreliable, so AME defaults to UTC. Users must manually set their preferred timezone for accurate display.
Overriding the Event Time
The default Event Time (search job timestamp) may not always suit alert management needs. For example, if an event originates from another alerting system and is indexed in Splunk, you might prefer the event’s _time over the job’s timestamp.
To override the Event Time, modify the search with:
| eval ame._time=_time(visible field), or| eval _ame._time=_time(hidden field).
AME then uses this timestamp as the Event Time. The Alert Time in the Data tab remains the original alert firing timestamp.