The operational problem
An event is more useful when the operator can identify its source, timing and related infrastructure rather than reading an isolated stream.
What you can monitor
Collect supported normalized events, filter by severity and source, and investigate them alongside assets and incidents.
What is included
- Searchable normalized operational events.
- Filters for source, severity and time with asset context when available.
- Event evidence alongside permitted incident and infrastructure views.
Plan limits and optional services are shown on the pricing page.
Coverage and requirements
Normalized event search is distinct from continuous raw-log archive. Archive volume, retention and implementation need separate review.
A practical workflow
- Choose the Site Edge receiving the supported event source.
- Configure the sender using the displayed receiver address.
- Verify a real event and its timestamp interpretation.
- Search the relevant period while investigating an incident.
How to set it up
- Assign a Site Edge and review the supported receiving protocol and address.
- Configure the source to send events and confirm its timestamp and timezone behavior.
- Send a real test event, verify its source and severity, then review the intended search period.
Incident review: events around a restart
Illustrative event timeline for an operator investigating a server interruption.
- Time window
- Search a narrow period around the reported interruption.
- Source and severity
- Confirm the event belongs to the expected device and read its normalized severity.
- Related evidence
- Compare the event with available asset observations; timing alone does not establish a cause.
AOT-authored example of how to read the product. It contains no customer measurements or promised outcomes.
Reports for the decision
Incident and infrastructure reports present the available event evidence within the selected scope.
Explore report workflows →