Home Dashboard

The Home screen is the landing page: a live snapshot of the platform for your active organization. It refreshes automatically while the tab is visible, and every figure links to the screen where the underlying work happens.

What it shows

• Waiting on You - what needs you, rather than the organization as a whole: approvals you may decide (only if your role permits it), your own runs still in flight, and your own recent failures. Runs count as yours when you started them; schedule- and webhook-triggered runs belong to nobody. Approvals close to their timeout are called out separately, because once the deadline passes the decision is made for you: the platform expires the request automatically. It does record that - an error event on the run's timeline, and an APPROVAL_EXPIRED notification wherever a destination subscribes to one - but those arrive after the fact. This is the warning that arrives before it.
• Coming Up - active schedules due to fire in the next 24 hours. What is about to happen, rather than what already did.
• Active Runs - runs currently in flight: pending, running, paused, or waiting for an approval. Matches the count badge next to Runs in the sidebar.
• Succeeded / Failed (24h) - outcomes of runs that finished in the last 24 hours, with the selected window's totals beneath.
• Pending Approvals - approval requests awaiting a decision. Click through to decide them - see the approvals guide.
• Run Activity - a per-day chart of finished run outcomes, with the total and success rate of the bars shown. Days are UTC calendar days, so the last bar is "today" in UTC, not necessarily in your timezone - and the caption counts those same calendar days rather than a rolling window, so it can differ slightly from the stat tiles above, which do use a rolling one. Switch the window between 7, 14, and 30 days; the window figures follow it, and the choice is kept in the address bar (?window=30) so a reload or a shared link opens on the same range.
• Run Duration - median and 95th-percentile wall-clock time per UTC day, over runs that succeeded. Failures are excluded deliberately: a run that dies on startup finishes in milliseconds and would drag the median down while the work itself got slower. Days when nothing succeeded have no duration and appear as a gap rather than as zero. This is a separate chart from Run Activity rather than a second axis on it, because counts and seconds share no scale.
• Recent Runs - the latest runs with status, start time, and duration. Click a run to open its full history - see Running Flows.
• Resources - counts of active flows, devices, sites, schedules, webhooks, secrets, variables, and git repositories, each linking to its list screen.

The header shows when the page last refreshed; it polls on its own while the tab is visible. Organization-wide figures are cached briefly and shared between everyone viewing the same organization, so that timestamp reports when the figures were computed rather than when your browser asked for them - they can be a few seconds behind. Anything scoped to you personally is computed for each request and is never shared.

Clicking through to the runs list

Each run tile opens the Runs list filtered to exactly what the tile counted, so the number and the rows always agree - "Failed (24h)" opens the failed runs that finished in the last 24 hours, not every failure ever.

The filter lives in the address bar, so any filtered list can be bookmarked or pasted to a colleague. A time window appears as a chip above the table and can be cleared without losing the other filters.

Worker fleet health is deliberately not here. It describes the whole deployment rather than your organization, and nobody outside the platform administrators can act on it, so it lives in Platform Health below.

Org Health

Organization administrators see one extra section covering their own organization - the same tenant as everything above, but the parts only an administrator can act on. A platform administrator sees it too, describing whichever organization they are currently acting as, not the deployment.

It answers two questions at once. Some figures are alarms and set the badge:

• Approvals - requests awaiting a decision and how long the oldest has waited. If nobody in the organization holds a role that can decide them, the queue cannot drain and the card says so, linking to the member list.
• Schedules - active schedules, and how many are overdue. A schedule counts as overdue only once it is well past due: the scheduler polls on an interval and takes a limited number of schedules per poll, so being briefly late is normal. The card states the grace period it used.
• Inventory Sync - your organization's external inventory providers in sync, failing, overdue, or never synced. The same rollup Platform Health shows for the whole deployment, one organization at a time.

The rest describe how the organization is being used, and deliberately do not set the badge:

• People - members, how many signed in inside the selected window, how many are dormant, and how many were invited but never signed in. Only active accounts count - a deactivated member is not coverage.
• Role Coverage - how many members can administer the organization and how many can decide approvals.
• Where the work comes from - runs started by a person versus runs started by a schedule, a webhook, or a parent flow, with the automated share. Beneath it, the people who started the most runs and how many of their runs failed.
• Flows failing most (24h) - the flows with the most failed runs in the last 24 hours, each shown against how many of that flow's runs finished in that same 24 hours, so "3 of 4" and "3 of 400" do not read the same. Both numbers cover the window; neither is an all-time total.

The badge reads Needs attention when approvals are unattended, schedules are overdue, or a provider sync is failing; otherwise Healthy. Failing runs are not an alarm on their own - a failed run is an ordinary event, and counting it would leave every busy organization permanently flagged.

Windowed figures - sign-ins, contributors, the automation split - follow the same 7/14/30-day selector as Run Activity.

Rows link to the screen that acts on them only where the link can be filtered to exactly what the row counted. Two deliberately do not. The people in "Where the work comes from" are plain text: that count windows on when a run was started, so work still in flight counts as activity, while the runs list can only bound completion - no URL expresses the same set. The inventory figures link to provider configuration only for a reader allowed there; provider configuration is a platform-scoped screen, so an organization administrator sees the numbers without a link that would refuse them.

Unlike the rest of the page, this section is scoped strictly to your own organization: shared-organization rows are read-only for you, so reporting one here would be an alarm you have no way to clear.

Platform Health

Platform administrators see one extra section at the bottom of the page, covering the whole deployment rather than a single organization:

• Subsystems - whether the API can reach PostgreSQL, Temporal, the secret backend, and object storage. Any of these being down breaks runs: a run that resolves a secret fails just as surely as one that cannot be dispatched.
• Workers - online and stale workers across the fleet, and how many runs are pinned to online workers.
• Maintenance Jobs - how many internal jobs are healthy and how many need attention (failed, overdue, or stuck mid-run), naming the ones that do and linking through to the maintenance settings screen - see Maintenance for what these jobs are. They reconcile run state, expire approvals, and prune events, so a quietly failing job is the classic cause of stale data.
• Fleet Load - active runs and 24-hour failures across every organization, plus how many organizations are active.
• Task Queue - how much work is waiting on the shared Temporal queue and how long the oldest item has waited. Worker count says who is listening; backlog says whether they are keeping up.
• Inventory Sync - external inventory providers in sync, failing, overdue, or never synced.
• Busiest organizations - active runs and recent failures per organization, so a single tenant in trouble is visible without switching into each one.

The overall badge summarises it: Unhealthy when a subsystem is unreachable, Degraded when a maintenance job needs attention, an inventory sync is failing, the task queue cannot be read, the oldest queued task has been waiting for more than two minutes, or workers that were online have disappeared. Queue depth alone does not degrade the deployment: a large backlog being worked through promptly is healthy, while a small one that has sat for minutes is not. A deployment with no workers at all is not degraded - it is simply unused.

Apart from the organization list itself, cross-organization figures are counts only: no other organization's run, flow, or resource names appear here. Organization names are shown because a platform administrator can already list every organization.

The external checks (Temporal, secrets, object storage, queue depth) are cached briefly and shared between administrators, so many open dashboards do not multiply the load on those dependencies.

Scope

Run, approval, and resource figures cover your active organization - plus the designated shared organization when the deployment uses one - exactly like the individual list screens. Org Health is the one exception: it is scoped strictly to your own organization, for the reason given above.

Switching organizations with the organization switcher re-scopes the whole page; a platform administrator sees one organization at a time here too, and only the Platform Health section spans all of them.

The page widens with your responsibilities. The dashboard itself needs only read access: any role that can see the list screens sees the same numbers here, and the New Run button is locked when your role cannot start runs. Org Health is restricted to administrators of that organization, and Platform Health to platform administrators - an organization administrator does not see it.