Monitoring and history

Every run of an automation is recorded. You can watch a run unfold live and review past runs step by step, with the logs and output each step produced.

The dashboard

The Dashboard is the landing page for the automation area. It summarizes recent activity with metric cards—Active Automations, Automations Triggered, Avg. Execution Time, Success Rate, and Cost—and two charts: an Automation Activity Trend over time and an Execution Health breakdown of successes and failures. Use the period selector (Today, Past 7 Days, Past 30 Days, Past 90 Days) to change the window.

Cost is an approximate figure calculated from the tokens the AI work consumed, not an invoice. Whoever supplies the model charges for it on their own terms, so read this as a guide to consumption rather than a statement of what you owe.

The automations list

The Automations page lists every automation, with a search box that filters by name and description, and columns for Name, Status, Enabled, By, Updated, Runs, and Last Run—with a "Showing X–Y of N" count below the table.

• Status is a pill for the automation's publish state—Draft, Published, or Archived. An archived automation always shows Archived here, whether or not it is turned on, since it can't run at all. A published automation with a revision in progress shows the revision as a nested row beneath it, with its own Revision pill.
• Enabled reads On or Off—whether the automation's own triggers may start it.
• By shows an avatar for who created and who last updated the automation; hover it for both names.
• Runs is a count you can click to open that automation's execution history.
• Last Run shows a status-colored square and a relative time, linking to that run; hover it for a summary card of the run's status, mode, and duration.

Select Show Archived to include archived automations in the list. An archived automation's row is muted, its Status column reads Archived, and its Enabled column reads Off whatever its switch says, since it cannot run.

Bulk actions

Select one or more rows with their checkboxes, or select every row on the page, to reveal Enable, Disable, Archive, Restore, and Export buttons above the list. A button appears only when it applies to at least one selected row, and its badge shows how many rows it will affect; hovering a button previews exactly which rows those are—the rows it won't touch fade back. Archived rows drop out of the count for Enable and Disable, since neither applies to them.

Export downloads every selected automation as a single file—see Exporting automations in bulk. Click Import on the same page to bring that file into this or another workspace; see Importing an automation.

If you are approaching or have reached a configured usage cap—on enabled automations, or on runs or steps started per day—the list shows a warning banner once usage crosses 80% of the limit, and the action that would exceed the cap (enabling an automation, or a run starting) is blocked with an explanation instead of silently failing. Contact an administrator to raise the limit.

Recent activity in the editor

Opening an automation in the flow editor shows a live activity strip in the side panel: a last-run badge with a status icon, and a strip of beads—one per recent run, colored by outcome (a running one pulses blue)—with a View all runs link to the full history below. New runs appear and recolor in place as they start and finish, without reloading the page.

Click a bead or the last-run badge to open that run's Workflow view. Hovering either shows a tooltip with the run's number, status, whether it was a dry run, start and end time, duration, and cost. As on the Dashboard, that cost excludes AI work run on your own provider account.

The Executions page

The Executions page lists every run of every automation, newest first, filterable by status and archived state, with a leading Automation column naming which automation each row belongs to. Click an automation's Runs count on the Automations list, or open Runs from within its editor, to narrow the same page to that automation alone—the Automation column drops out, since every row already shares it.

Started At and Completed At show a relative label by default ("15 hours ago"); toggle Full Timestamps in the filter bar to also show the exact date and time alongside it. The toggle is remembered for you and applies across pagination.

Run notifications

Subscribe to be told when an automation's runs finish, from your profile's notification settings, delivered through Brightspot's normal notification channels (email, Slack, the in-CMS bell). By default you're notified only on failure; opt in to also hear about successful runs. Scope the subscription to specific automations, or leave it open to every automation. Each notification links straight to the run, and a failure notification names which step or steps failed.

Viewing a run

A run opens in one of two views, switchable with the Workflow and Steps tabs:

• Workflow shows the flow on a read-only canvas, with each node's status overlaid on its card. While a run is live, the view updates in place as steps progress, so you can watch the flow execute. For the first few seconds after a run starts, before any step has a status yet, the fired trigger shows a pulsing border and a Starting badge instead of sitting blank.
• Steps shows a table of every step, with its status, timing, and links to that step's logs and output.

A running execution can be cancelled with the Stop button on the execution detail pages. The run is marked cancelled the moment you click, no matter how large it is, and nothing further in it begins. Steps that hadn't started then settle to Cancelled over the next few seconds, so you may briefly see a cancelled run with some steps still listed as pending.

A step that was already mid-way through its work is allowed to finish rather than being cut off. This is deliberate: if that step had already changed something on the target system, cutting it off would record it as failed while the change stayed in place, and the run history would understate what the automation did. Letting it finish means the history matches reality. So a stopped run can show one last step completing a moment after you press Stop.

Replaying a finished run

Once a run has finished, the Workflow view offers a Replay button. Clicking it clears the finished state from the canvas and animates the run from the beginning, using the statuses, edge cascades, and log lines the run actually recorded. The run pane rebuilds alongside it, one step at a time, so a failure can be watched arriving rather than reconstructed from a finished table.

Nothing re-executes during a replay. The animation is drawn entirely from history that was already stored, so replaying a run that posted a message or updated an asset does not do either of those things again.

A bar stays across the top for the whole replay, stating that what is on screen is stored history rather than a run in progress, and the canvas is ringed in the same accent so the distinction survives scrolling the bar out of view.

The bar carries two different measures of time, and they deliberately disagree:

• The progress bar tracks the playback itself—how far through the animation you are.
• The clock counts the run's own elapsed time, which is why it can jump. Long gaps and waits are compressed so a replay does not sit idle, and the clock leaping forward is what makes that compression visible instead of silently misrepresenting how long the run took.

You can pause a replay with Pause and pick it up in the same place with Resume. Pausing holds the canvas and the run pane exactly as they are, and the time spent paused does not count towards the run's clock.

While a replay is paused, the progress bar becomes a control for moving to a different moment in the run. Click anywhere along it to jump to that point, drag it to choose a position, or focus it and use the left and right arrow keys. The clock follows as you move, so you can see which moment you are about to land on before you commit to it. Moving backwards replays the run from its start up to the point you chose, so the canvas and the run pane show the run exactly as it stood then rather than a mixture of that moment and where the replay had already reached. The replay stays paused where you land, ready for Resume to carry on from there.

Stop ends a replay early and restores the run's real finished state. A replay left to play out settles on that same finished state on its own.

note

Replay is available only for a finished run. A run that recorded no step transitions has nothing to animate, so the button does nothing for it.

Statuses

As a run progresses, each step moves through statuses shown on its card or row:

• Running—the step is executing.
• Waiting / Awaiting Input—the step is paused, for a timer, an external event, or human input.
• Done—the step completed successfully.
• Error—the step failed.
• Cancelled—the step was stopped.
• Skipped—the flow did not route to the step.

Logs and output

From the Steps view you can open a step's:

• Logs—a timeline of entries, filterable by level: All (the default), System, Debug, Info, Warn, and Error. The timeline includes each step's status transitions and any messages it produced. Status transitions are System entries, but a failed step's error message is an Error one, as is the closing line of a run that failed—so filtering to Error finds the failures without also hiding them.
• Output—the payload the step produced, shown as formatted data, or the error message if it failed.

How the log pages depends on whether the run is still going. A finished run gets numbered pages with a control for how many entries a page holds; a live run gets Load earlier 50 (or whatever the page size is) and Jump to newest instead, so entries arriving while you read never renumber the page under you. Filtering to a level that matched nothing says so and names the filter, rather than claiming the run produced nothing, and offers Show all rows to undo it. A run long enough to exceed what one view can hold shows a banner saying how many entries are on screen out of how many there are—the log is trimmed, not complete.

Secret values are redacted from both logs and output. When a loop runs, logs and output are recorded per iteration so you can inspect any single pass.