V2 UI Reference: Run Insights Tab

The Run Insights tab is the post-run dashboard for V2 integrations. It reads the most recent IntegrationRun for the current instance (Sync Preview or Full Sync) and presents the run-level summary plus a per-stage breakdown. It is the same on every V2 driver.

What it isn't

Run Insights only shows the latest run. For history, comparison or stage-level error payloads, use the Logs Tab. For per-device problems, use the Problem Devices Tab.

What Run Insights Shows

The tab is split in two:

1. Summary cards at the top: headline counters from the run’s summary_json (status, create count, update count, open problems).
2. Stage progress below: one card per pipeline stage with status, metrics and a summary block populated by that stage.

If no run has been executed for this instance yet, the tab displays an empty state and points back at the action bar to launch a Sync Preview.

Summary Cards

Card	Tone	Source	Meaning
Status	Sky	run.status	One of queued, running, preview_ready, completed, failed. preview_ready means a Sync Preview finished cleanly through decide and is waiting on you to promote it to Apply.
Create	Violet	summary.decisions.create	Number of candidates that resolved to a create decision. In Sync Preview these are not yet committed.
Update	Indigo	summary.decisions.update	Candidates that matched an existing rConfig device and would update it on Apply.
Open Problems	Red when > 0, otherwise teal	summary.problems.open	Count of candidates parked in Problem Devices for review (canonicalize errors, ambiguous matches, conflicts).

A red Open Problems card is the single most important signal on the page: even a “completed” Apply run can leave problems behind that need manual resolution.

Stage Progress

Below the cards, each pipeline stage gets its own card in execution order:

1. validate_setup
2. extract
3. canonicalize
4. reconcile
5. decide
6. preview_results (Sync Preview) or apply (Full Sync only)

Each stage card shows:

• Stage name and status badge (sky border for completed, amber for running, red for failed).
• Metrics grid: up to two columns of key/value pairs from metrics_json, excluding the nested summary block.
• Summary block: additional, stage-specific aggregates. extract, for example, reports pagination stats and memory usage; apply reports a run-summary block of totals.

Common metrics by stage

Stage	Typical keys you’ll see
validate_setup	connection, credentials
extract	processed, missing_policy_actions, extract_pagination_type, extract_page_count, extract_items_extracted, extract_truncated, memory_usage_start_bytes, memory_usage_end_bytes, memory_peak_bytes
canonicalize	processed
reconcile	processed, conflicts
decide	create, update, skip, conflict
apply	applied, skipped, failed, plus a run-summary block of totals

Object values (nested JSON) are rendered as a one-line JSON string so you can scan them without a hover. For the full structure, open the same stage in the Logs Tab where the entire metrics_json and error_payload are available.

Note

Memory metrics are reported in bytes (memory_usage_start_bytes, memory_usage_end_bytes, memory_peak_bytes), not megabytes.

Reading a Failed Run

When run.status = failed, exactly one stage card will be red. That stage holds the failure point:

1. Read its error_summary (one-line, in the metrics block).
2. Open Logs for the same run to see the full error_payload (including up to five chained previous exceptions, when the run was launched with --debug or via the Debug Console with debug on).
3. If the failure is in validate_setup, fix in Setup. If it’s in extract, validate filters via Extract Preview. If it’s in canonicalize, the affected candidates are visible in Problem Devices.

Triage Patterns

Signal in Run Insights	Where to go next
extract.extract_truncated = true	Increase the driver’s pagination cap, or tighten filters. The truncation detail is in the stage summary.
canonicalize.processed is lower than expected, or Open Problems is non-zero	Open Problem Devices: most common causes are missing hostname, missing primary IP, or unresolved Device Profile slug.
Open Problems is non-zero after reconcile	Open Problem Devices: pick the correct target device for each ambiguous candidate, or tighten the reconciliation policy.
decide.conflict > 0	Open Problem Devices, the Conflict group: these block Apply for the affected candidates.
decide.skip is high but no problems	Check the reason field in the decision summary: MISSING_FROM_UPSTREAM and MEDIUM_MATCH_REQUIRES_REVIEW are common, both are intentional.
apply.applied is 0 after a Full Sync where create > 0 was decided	The Apply stage failed: open Logs for the apply stage’s error_payload.

Interaction Notes

• The tab is read-only. There are no buttons inside the panel. Re-runs are launched from the Detail page action bar, not from here.
• The tab refreshes when you switch to it. There is no live polling: refresh the page (or click another tab and back) to pick up a queued run that has just finished.
• For long Full Sync runs, the tab is most useful after the run, not during. Use the Debug Console to watch live progress.

Related Documentation

• Problem Devices Tab: per-device triage for candidates the pipeline couldn’t resolve automatically
• Logs Tab: full run history, stage metrics, and error payloads beyond the latest run
• Debug Console: live, streaming output for watching a run in progress