Logs & Diagnostics

The logs

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

Log	Where	Contains	Permission
System logs	Logs → System	Service-level events, errors, startup	View System Logs
Execution logs	Logs → Executions	Pipeline runs, per-execution outcome	View Execution Logs
Node executions	Logs → Executions, expanded	Per-node results within an execution	View Execution Logs
Startup detail	The startup screen	What happened during boot	shown automatically
Audit journal	Settings → Audit Log	Security-relevant actions	View Audit Log
Diagnostic reports	log/ in the data directory	Structured NDJSON	filesystem
Per-service logs 1.0.8	log/services/ in the data directory	Each service's own output, and the supervisor's	filesystem

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.

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 on the binding 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 poll 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

Settings → Store & Forward shows each buffer's depth, fill, growth and quarantine, and is where you read, retry, drop, export or import quarantined writes — reading needs View Connections, acting needs Edit Connection, importing needs Manage Backup & Restore.

Store-and-forward conditions also raise system alarms 1.0.8 in the ordinary alarm list: a buffer filling (80 %) or full, writes in quarantine, buffered history nearing the historian's retention, and — critical — the data disk below its free-space floor. A filling buffer means a destination has been unreachable long enough to matter; the Fills in column says how long you have. 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. Open the write in full with the eye icon to see exactly what was refused.

→ Store and forward

Protocol-specific diagnostics

Protocol	Tool
OPC-UA	Endpoint discovery, address-space browse, node quarantine
MQTT / Sparkplug	Sparkplug discovery, broker connection state
Modbus	One-shot register read from the connection's editor
SNMP	Agent walk from the connection's editor, and the trap feed
SQL / Mongo / QuestDB	Schema, 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.

Per-service logs New in 1.0.8

The supervisor keeps what every service prints, one file per service, in log/services/ in the data directory: QBQ-CoreServer.log, QBQ-Historian.log and so on, plus QBQ-Supervisor.log for the supervisor itself and the message bus's own warnings. Earlier builds printed this to a console that nobody kept — and an installed Windows service has no console at all — so a crash report carried only its last line, which was often the wrong one.

What is written is chosen so the files explain a failure without filling up on a healthy day:

Phase	Written
Starting up — from launch until the service reports ready, or 60 seconds	Every line. Boot is where failures happen.
Running	Only lines that look like a warning or an error.
A panic, fatal error or Python traceback	In full, whatever it contains.
A crash	The last few hundred lines the service printed, including the ones filtered out while it ran, are written after the fact. Those lines are marked with a lower-case letter, so you can see they were recovered.

A line that repeats is written once, followed by repeated N times, and each service has its own rate limit, so one flooding service cannot crowd out the others.

Bounds. Each file rotates at 5 MiB into three compressed archives. Archives older than 14 days are deleted, and the whole folder is capped at 150 MiB, oldest archives first. Writing never blocks a service: if the disk is full or locked, lines are dropped and the count is noted in the log.

Read these first when a service will not start or keeps restarting. They are files on the gateway machine, not something the Logs panel shows.

Log levels and retention

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

Level	Means	Look here when
DEBUG	Detail for diagnosis	You turned verbosity up on purpose
INFO	Routine progress	Reconstructing what happened, in order
SUCCESS	Something completed	Confirming a run finished
RETRYING	An attempt failed and another one is coming	Watching a flaky connection settle
WARN 1.0.4	Something went wrong and was handled. Nothing further will happen	Looking for problems without wading through INFO or hiding among ERROR
ERROR	A failure nothing handled	Triage

WARN is what a pipeline node routing its failure out of an error socket writes, along with 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 Manage Log Config).

• 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 affected service's file from log/services/, and QBQ-Supervisor.log, if a service would not start or kept restarting
6. 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?"
7. Version and platform
8. What changed recently — nearly every incident has a recent change behind it

Next

→ Console recovery