Investigate product Events
Investigate active problems, user operations, and EventLog history.
- Author:
- Mqttable
- Updated:
On this page4 sections
Loading...
Investigate active problems, user operations, and EventLog history.
Loading...
Use Events to investigate active problems, user operations, and EventLog history. Events are structured product evidence, not raw Runtime logs.

Start with active problems, narrow the Event stream, then inspect the selected evidence.
Important events shows failures, verified recovery, and important operation results, such as completed runs or configuration changes. Normal scheduler starts, automatic resubscription successes, ordinary publishes, and progress updates do not fill this view. Use Trace for MQTT packet evidence and each workbench for live task progress.
All events includes retained structured evidence and audit records. It does not contain every scheduler tick, packet, or repeated occurrence. A normal task cancellation is an Info result, not an ongoing problem.
Active problems represent failures that still apply to the current operation. A failed run, a single failed publish, or a denied permission remains useful history without permanently increasing the active-problem count.
Recovery needs matching evidence. A successful subscription to one topic does not recover another topic. Saving scheduled-message settings does not prove that runtime timers were synchronized, and synchronized timers do not prove a message was published. A restored notification channel does not imply that missed notifications were resent. Restored Trace parsing does not bring back lost rows.
Stopping or replacing an operation marks its problem No longer applies, not Resolved. Earlier-runtime evidence is Unverified until a current observation establishes its state.
Repeated background failures share one summary. The inspector shows their known cumulative count and first and last observation times. These counts cover the event group, not just the selected time range.
First failures, changed causes, and recovery are recorded immediately. Repeated observations are checkpointed every 60 seconds and before controlled closure or recovery. A crash can lose counts that have not yet been checkpointed. Audit records are not sampled. Trace diagnostics are best-effort, so their counts do not guarantee that every underlying error was captured.