Reading the Dashboard and Monitoring Automation Health

Why the dashboard matters

Automations do their work quietly in the background, which is exactly why you need one place that tells you they are healthy. The Dashboard is the first tab in StretchAutomate and the screen you should check daily. It rolls up your whole automation footprint into a handful of numbers so you can spot a stalled connector or a run that started failing before anyone downstream complains.

The metrics, explained

The dashboard is built from a live overview of your organization's automations. Each number answers a specific operational question:

• Active workflows — how many workflows currently have the status Active and are therefore firing automatically. If this drops unexpectedly, a workflow was paused or archived.
• Total workflows — every workflow you own regardless of status (draft, active, paused, or archived). The gap between total and active is your backlog of drafts and paused automations.
• Total runs — the count of every execution recorded in your Run ledger, simulate and live alike. A healthy, busy workspace shows this climbing steadily.
• Failed / partial runs — runs that finished in a failed or partial state. This is the single most important number to watch: a rising count means steps are not resolving or actions are stuck. Zero (or near‑zero relative to total runs) is the goal.
• Active connections — how many of your linked accounts and credential references are currently active. A connector with no active connection cannot dispatch its actions.

How "failed" is counted: the dashboard's failure metric includes both fully failed runs and partial runs (runs where some steps succeeded and others did not). That is deliberate — a partial run still means something did not complete, and you want it on your radar.

A daily monitoring routine

1. Open the Dashboard first thing. Glance at failed / partial runs. If it moved since yesterday, something needs attention.
2. Drill into the Run ledger. From the ledger, filter to failed and partial runs and open the most recent one. The per‑step trace shows exactly which step broke and why (for example, an unresolved reference or a skipped branch).
3. Check active connections. If an action step is failing across many runs, confirm its connector still has an active connection. An expired or revoked credential reference is a common root cause.
4. Confirm active workflows. If active workflows fell, someone may have paused or archived a workflow. Re‑activate it if that was unintentional.
5. Watch total runs for silence. A workflow that suddenly stops producing runs may have a trigger that is no longer firing — check its trigger configuration.

Realistic example

A support team runs an automation that opens a follow‑up task whenever StretchSupport signals an imminent SLA breach. One morning the dashboard shows failed / partial runs jumped from 2 to 9 overnight. Opening the Run ledger, the operator filters to failed runs and sees each one blocked on the same step: the StretchTasks create_task action reported an unresolved reference to a field that was renamed. They fix the field mapping, re‑simulate, and the next live runs finish clean. The whole diagnosis took three minutes because the dashboard flagged the spike immediately.

Tips

• Treat failed / partial runs as your primary alarm. Everything else is context.
• A large gap between total and active workflows is normal while you are building — but review paused workflows periodically so nothing important is silently switched off.
• Active connections should match the connectors your active workflows actually use. A connector referenced by a live workflow but missing an active connection is a latent failure.
• Pair the dashboard with the Run ledger: the dashboard tells you that something is wrong; the ledger tells you what and where.

Troubleshooting

The dashboard shows zero runs even though workflows are active. Either the triggers have not fired yet, or the workflows have no steps to run. Open a workflow, confirm it has at least one step, and run it in simulate mode to generate a trace.

Failed/partial count keeps rising. Open the newest failed run in the ledger. The most common causes are unresolved references (a step points at data that isn't in the run's context) and action steps waiting on dispatch in live mode. See Retry Policies and Error Handling for the full remediation flow.

Active connections shows fewer than expected. A connection may have moved out of the active status. Open the Connections tab, confirm the connector you need is present and active, and recreate it if its credential reference is stale.