Skip to main content
Version: 1.0.4

Logs & Diagnostics

The logs​

Logs in the header opens both, in two tabs: System and Executions.

LogWhereContainsPermission
System logsLogs → SystemService-level events, errors, startupView system logs
Execution logsLogs → ExecutionsPipeline runs, per-execution outcomeView execution logs
Node executionsLogs → Executions, expandedPer-node results within an executionView execution logs
Startup detailThe startup screenWhat happened during bootshown automatically
Audit journalSettings → Audit LogSecurity-relevant actionsView the audit journal
Diagnostic reportslog/ in the data directoryStructured NDJSONfilesystem
Licensing is deliberately absent from all of this

A module you do not own is absent, not stopped or failed, and nothing about it is written to the logs or counted as degraded health. If a capability is missing and the logs say nothing at all, check Licensing before treating it as a fault.

Logs can be cleared (needs Clear system logs or Clear execution logs). The audit journal cannot — that is the distinction between diagnostics and accountability.

A systematic approach​

Work outward from the smallest scope that explains the symptom.

A fault-finding chart working down four questions — is the gateway up, are services running, is the connection healthy, is the tag good quality — each with the check to run when the answer is no.A fault-finding chart working down four questions — is the gateway up, are services running, is the connection healthy, is the tag good quality — each with the check to run when the answer is no.
Work top to bottom. The first “no” is your answer.

Common symptoms​

A screen shows no data​

  1. Is the tag good quality? Look at it in the namespace panel. Bad quality is a binding or connection problem, not a screen problem.
  2. Is the connection healthy? The Connections list, or the Status panel.
  3. Is the binding correct? Check the address; use Browse to confirm it exists.
  4. Is it a permission? "Works in the Designer, not in LiveView" is nearly always the project's access policy or the runtime role.

A pipeline is not running​

  1. Is it started? Check the pipeline's state in the workspace.
  2. Is the project enabled? A disabled project stops its pipelines.
  3. Is the trigger firing? For Inject, check the schedule; for REST, check the route; for a tag subscription, check the tag is changing.
  4. Read the execution log and drill into the failing execution.

Values are stale​

  1. Check quality. A stale-after setting turns silence into visible Uncertain.
  2. Check the connection. A down connection means bad quality on everything bound to it.
  3. Check the deadband. A large deadband makes a slow value look frozen.
  4. Check the sampling rate against the device's own scan time.

History has gaps​

  1. Was the connection down? Compare the gap with connection history.
  2. Is the deadband too large? A stable value produces no points unless a store interval is set.
  3. Is the historian healthy? Look for schema-drift, suspension or ownership alarms.
  4. Did retention drop it? Compare the gap's age with the retention window.
  5. Is it an epoch boundary? A retired store's epoch may no longer be readable.

Writes are rejected​

  1. Is the tag writable?
  2. Does the operator's level meet the tag's write level?
  3. Is the device accepting writes? Some registers and OPC-UA nodes are read-only on the device.
  4. Check the audit journal — the rejection is recorded with the reason.

Performance has degraded​

  1. Host resources — the Status panel's system view.
  2. Store-and-forward buffers — a growing buffer means a slow or unreachable destination.
  3. Polling rates — the usual cause is everything polling at 100 ms.
  4. Alarm rate — an alarm flood loads the whole telemetry path.
  5. Screen complexity — many high-rate bindings on one view.

Store-and-forward diagnostics​

The Status panel shows each connection's buffer depth and its quarantine, and is where you retry or drop quarantined items — reading needs View connections, acting needs Edit connections.

A buffer-pressure alarm means a destination has been unreachable long enough to matter. Quarantine means items failed permanently — investigate the cause (usually a schema mismatch, a constraint violation or a credential change) before retrying, or they will simply re-quarantine.

→ Store and forward

Protocol-specific diagnostics​

ProtocolTool
OPC-UAEndpoint discovery, address-space browse, node quarantine
MQTT / SparkplugSparkplug discovery, broker connection state
ModbusOne-shot register read from the connection's editor
SNMPAgent walk from the connection's editor, and the trap feed
SQL / Mongo / QuestDBSchema, table and collection browse from the connection's editor

Each of these answers "is it the device or is it QUBIQ?" faster than reading logs.

Log levels and retention​

Every system-log row carries a level, and the toolbar filters on it.

LevelMeansLook here when
DEBUGDetail for diagnosisYou turned verbosity up on purpose
INFORoutine progressReconstructing what happened, in order
SUCCESSSomething completedConfirming a run finished
RETRYINGAn attempt failed and another one is comingWatching a flaky connection settle
WARN 1.0.4Something went wrong and was handled. Nothing further will happenLooking for problems without wading through INFO or hiding among ERROR
ERRORA failure nothing handledTriage

WARN is what a pipeline node routing its failure out of an error socket writes, along with the report scheduler, the batch-drop summary and a console password reset. Earlier builds showed those rows as RETRYING, which told a reader to expect an attempt that was never coming.

Log retention lives in Settings → System Health (needs Configure system logging).

  • Raise verbosity while diagnosing, and lower it again. Debug logging on a busy gateway generates volume that itself becomes a problem.
  • Diagnostic reports under log/ are rotated NDJSON.
  • The system log is pruned to a ceiling, so it is diagnostics rather than evidence. Anything that must survive a busy day belongs in the audit journal.

Escalating​

When you need help, gather:

  1. What the startup screen reported, if the gateway did not come up cleanly
  2. System logs covering the incident window
  3. The failing execution with its node results, if a pipeline is involved
  4. Connection status for the affected connections
  5. The licence status from /licensing — it is always in the support snapshot, and it settles "did they buy this?" before anyone spends an hour on "is it broken?"
  6. Version and platform
  7. What changed recently — nearly every incident has a recent change behind it

Next​

→ Console recovery