Dashboard walkthrough

The diagnostics surfaces are gated per-namespace behind the diagnostics_v1 beta flag. This page walks through enabling it and finding the three new UI surfaces.

Enable the beta flag

Diagnostics ship as a beta feature. Backend code paths run for everyone — every OTA aggregates verification results into Postgres regardless of the flag — but the UI surfaces hide unless the flag is on.

To enable for a namespace:

1. Open SCADABLE → Settings for the namespace you want.
2. Under Beta features, toggle Diagnostics v1.
3. Reload any open dashboard tabs to pick up the new surfaces.

If you don't see the toggle, you don't have admin access to that namespace's settings. Ask the namespace owner, or contact SCADABLE support to flip it for you.

Surface 1: Gateway Detail → Diagnostics tab

Open any gateway and you'll see a new Diagnostics tab between Commands and Settings. The tab lists every diagnostic the cloud knows about for that gateway's code project, with the latest run status, whether run_after_ota is on, and a per-row Run button.

┌─ Diagnostics ──────────────────────────────────────────────────────┐
│                                                                     │
│  [+] Run all                                  Last verification: ✓  │
│                                                                     │
│  ┌───────────────────────────────────────────────────────────────┐ │
│  │ Motor Bearing Health                              [Run ▶]     │ │
│  │ Last: pass · 12 ms · 3m ago                                   │ │
│  │ Run after OTA: ✓                                              │ │
│  ├───────────────────────────────────────────────────────────────┤ │
│  │ Network Round-trip                                [Run ▶]     │ │
│  │ Last: pass · 45 ms · 3m ago                                   │ │
│  │ Run after OTA: ✓                                              │ │
│  ├───────────────────────────────────────────────────────────────┤ │
│  │ Thermal Sweep (slow)                              [Run ▶]     │ │
│  │ Last: never                                                    │ │
│  │ Run after OTA: ✗                                              │ │
│  └───────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘

Click any row to open the run drawer:

• The last 20 runs for this diagnostic on this gateway, each with a status pill, duration, timestamp, and triggered_by icon (manual / ota_verify / local_pre_ota).
• The full log_text from the most recent run, monospace.
• The details field, if the diagnostic populated it.
• The Run button at the bottom — same as the row-level button.

The dashboard polls the run row every 1 s while it's pending and shows the final log buffer when status flips. Live tail (streaming DIAG_LOG lines as they're written) is on the v1.1 roadmap.

Surface 2: Release Detail → Post-OTA Verification panel

Open any release that has at least one applied gateway. Below the apply matrix you'll see the Post-OTA verification panel, a per-gateway × per-diagnostic grid:

┌─ Post-OTA verification ────────────────────────────────────────────┐
│  3 of 4 gateways verified · 1 verification failed                  │
│                                                                     │
│  gateway-001  ✓ verified   motor_health ✓  network_roundtrip ✓    │
│  gateway-002  ✓ verified   motor_health ✓  network_roundtrip ✓    │
│  gateway-003  ⚠ failed     motor_health ✗  network_roundtrip ✓    │
│                            "rms too high: 6.20g"                   │
│                            [Auto-rolled back to v0.4.2 →]          │
│  gateway-004  ⏳ verifying  motor_health …  network_roundtrip …    │
└─────────────────────────────────────────────────────────────────────┘

Status colors:

• Green check — verified. All run_after_ota diagnostics passed.
• Yellow warn — at least one pass_with_warn, no failures.
• Red alert — verification_failed. One or more failed/timed out/errored. The auto-rollback link shows where the gateway was rolled back to.
• Spinner — verifying. Diagnostic results are still landing.
• Grey — applied but not in the run_after_ota set (zero diagnostics gating this release for this gateway).

Click any failed cell to open the failure drawer: the full message, the full details, the full log_text, the start + finish timestamps, and a link to jump to the rolled-back release.

If the project is in storm-disabled state, a banner appears at the top of the panel:

┌────────────────────────────────────────────────────────────────────┐
│  ⚠  Auto-rollback disabled for this project (3 verification        │
│     failures across distinct releases in the last 24 h).           │
│     Auto-re-enables in 19 h, or:                                   │
│                                              [Re-enable now]       │
└────────────────────────────────────────────────────────────────────┘

The Re-enable now button immediately lifts the storm-disable flag. Use it after you've fixed whatever upstream produced the bad releases — typically by reverting a buggy diagnostic, fixing a regression, or removing a known-flaky device from the rollout.

Surface 3: gateway-level verification status

The gateway list (Project → Gateways) shows each gateway's release status as a colored pill. With diagnostics enabled, the pill picks up the new states:

• applied — pre-v0.3.0 behavior. The chip applied; no run_after_ota diagnostics gate this release.
• verifying — applied, diagnostics in flight.
• verified — applied, all diagnostics passed.
• verification_failed — applied, at least one diagnostic failed. Hover for the auto-rollback target.
• verification_storm — rolled-back release also failed. Manual intervention required.

Clicking a verification_failed or verification_storm pill jumps to the gateway's Diagnostics tab with the failed run's drawer pre-opened.

What if I want to see results but not auto-rollback?

Disable auto_rollback_on_verification_failure in your namespace beta-features panel. Verification still runs on every OTA, the dashboard still shows the verification panel, and verification_failed still flips the gateway pill — but the cloud no longer rolls back.

This is the recommended setup if you're new to diagnostics and want to observe behavior for a few rollouts before committing to the full automatic recovery loop.

See also

• Post-OTA verification: the lifecycle behind these surfaces.
• Config schema: the YAML you write to populate the rows.
• C API: the firmware functions every row corresponds to.