Diagnostics help explain a slow task, missing recordings, or a display that stops updating. Use the measurements to identify which part of the system needs investigation, then check its events and logs.

Diagnostics

Open Settings → Diagnostics. The tabs separate measurements from the connected Engine and checks made by your local Interface:

Diagnostic Rows and Warnings

Engine and interface diagnostics are shown in the Diagnostics table, each as their own row with a measurement.

Search for a measurement or expand its row for details. A dash or blank graph means unavailable or stale, not zero. Show supporting measurements reveals Engine inputs normally hidden from the table.

Each row has a configurable warning setting. Engine diagnostics raise ARGUS warnings that can be viewed in the Node Board or through Events. Local Interface checks raise Interface settings issues.

Administrators can use a row’s settings button to enable diagnostics and, for numeric measurements, choose ABOVE, BELOW, or OUTSIDE RANGE limits. Counter and runtime rows use their own warning controls; local Interface controls apply to that Interface.

All rows turn yellow with a warning icon when a warning is active. Warnings tied to ARGUS events can be selected to open them up in the Node Board, as it is a normal ARGUS event.

Interface-only warnings are kept in the Interface’s settings-issue list. They do not create Engine ARGUS events or RAPID channels. They are usually shown in the Notifications tab in the Interface Navbar with a warning icon. Clock warnings provide a button to open Diagnostics; other settings issues that send a notification provide a button to open Settings.

When the Engine measures something such as its CPU usage, it publishes that reading to a RAPID channel. For example, engine_dartwic_cpu_usage_percent can be viewed in Channels, graphed, or read by a client. The Engine updates these diagnostic channels; applications cannot overwrite their values.

If a diagnostic raises an ARGUS warning, the event links its associated channels when available so you can inspect the measurements behind it, and there is also a button in the Event info panel to view trigger source and open the warning in settings.

Some diagnostic details have no channel of their own, so a warning can also carry evidence only in its description and details. Supporting inputs, such as the values used to calculate a percentage, are published as channels only when needed by an enabled measurement.

Unless saved settings or task configuration change them, the defaults are:

Switching off an Engine measurement stops its diagnostic channel updates and alerts; the underlying service keeps working and collecting its internal counters. Inputs shared with another enabled measurement remain available.

Engine

An internal diagnostic loop runs roughly every half second, sampling resource use and collecting counters from Engine services. This can reveal a recorder falling behind even while current channel values still update. The open settings page refreshes roughly once per second.

Resources

These measurements show whether the computer has enough CPU, memory, and storage for its workload. They help distinguish Engine load from pressure caused by other applications.

Memory and storage sizes display in decimal MB.

RAPID

RAPID holds current channel values and queues recording and notification work for background services. This tab helps explain why live values look healthy while history or downstream updates fall behind.

engine_rapid_publication_overwritten_total counts rejected notifications despite its legacy name.

A queue is a waiting list. A short backlog that drains may be normal; one that keeps growing indicates a slower consumer. Larger buffers absorb bursts but cannot fix a service that stays too slow. See recording capacity.

ARGUS

ARGUS records events and logs. Recording and viewer delivery are separate: an event can appear before it reaches disk, or be recorded even if the viewer misses an update.

Details such as queued_jobs, oldest_pending_ms, and publication_dropped_total distinguish recording backlog from viewer delivery loss.

CAESAR

The CAESAR tab includes task and loop diagnostics. These measurements show whether your code runs as often as requested and finishes each iteration in time. The row names below illustrate a task named sample_control; use your runtime’s name.

Warning behavior depends on timing policy and deadlines. Unpaced workers and sequences need an explicit deadline when applicable. Task health also identifies callbacks still active past their deadline.

A task configured with disable_warnings is omitted from the Settings CAESAR rows. Its task-owned counters and task-health report remain available. For DCode, add the flag to the header; this excerpt omits the body:

task_periodic sample_control 100 normal disable_warnings:

TEMPEST

TEMPEST moves commands and observations between nodes and applications. These measurements distinguish quiet connections from congested delivery or missing peer data.

Mbps warning limits have no default ceiling. Expanded transport details include outbound_pending_bytes and dropped_total.

Dropped display updates do not prove recordings were lost. Diagnostics, acquisition, recording, and 5 Hz channel-display delivery have separate timing and failure paths.

Interface

LOCAL INTERFACE checks this Interface’s connection to the Engine. It currently measures the clock relationship and lists local settings issues; it does not measure general browser CPU or rendering performance.

Clock Comparison

When the Interface clock differs from the Engine clock, data look early or late. The Interface checks its clock against the Engine in the background while connected, even with Settings closed.

Expand the row for details. Its settings button controls warnings and the offset limit, defaulting to one second. Three confirmed violations warn; two confirmed healthy checks clear it. Slow or ambiguous exchanges cannot establish that a clock is wrong, and the check cannot identify which clock is correct.

Local preferences belong to this Interface. Settings issues below the measurement link back to the relevant settings; they are separate from Engine ARGUS events.

Other Diagnostics

Task cards, Network Map, and events/logs provide more specific evidence outside Settings → Diagnostics.

Task Health and Failures

Open Modules and Tasks to inspect a task’s controls, state, and timing on its card.

A task configured for 100 Hz may run more slowly or get stuck. Its channels and health report show actual execution. For sample_control, suffixes below form names such as sample_control_actual_frequency:

Failure Counters

A task can fail during one iteration without stopping entirely. _failed_cycles counts callback exceptions and survives stop/start of that task. It updates after execution. Errors your code catches, start/end failures, and process crashes need separate reporting.

Task Health Reports

A health report helps investigate a stuck or late task. With a connected Python client, use get-registered-tasks:

response = client.operation("dartwic/get-registered-tasks", {
    "query": "sample_control", "scope": "tasks", "limit": 10,
})
response.raise_for_error()
for task in response.payload["tasks"]:
    print(task["name"], task.get("execution"), task.get("health"))

Replace sample_control with your task. Execution fields include failed_cycles, last_cycle_failed, callback_active, and callback_active_ms (including waits).

Unpaced workers and sequences need an explicit deadline when applicable. Your application chooses recovery actions.

Peer Connections

A remote value can remain visible after its source stops updating. In Network Map, check connection state, received snapshots, and advancing source timestamps. Remote channel freshness explains what these establish.

Warnings and Timestamps

Engine warnings appear as ARGUS events; local Interface issues appear in Settings. Use Events and Logs to investigate at the source time. Acknowledgement does not repair the condition. Execution and Timing covers scheduling and locking and allocation limits.