Runs
Check an agent's workflows in Settings, start one with Run now, see who it runs as and read every run's steps and result.
Settings shows every run of your agents' markdown tasks and code workflows, read straight from the workflow engine's own history. Each agent's Workflows tab lists what it runs and when, and Activity → Runs lists runs across all the agents you manage.
Use these screens to check that scheduled work fired after a deploy, find which step failed and why, see which account a workflow acts as, or start a report by hand. How workflows are written and scheduled is in Workflows and schedules. Operating them from the server is in Operating runs.
An agent's Workflows tab
Open Settings → Agents → the agent → Workflows (/settings#/agents/<key>/runs). It lists the agent's work "on a timetable, on a webhook or when started", one row per workflow.
Every column on the Workflows tab
| Column | Contents |
|---|---|
| Workflow | Its title and purpose. Run in chat when people given it can run it in chat for themselves, and Personal schedules when they may also schedule it |
| Status | One line, listed below |
| Runs as | The account its runs act as, such as You (the local owner), or why it can't run |
| Run now for a code workflow, View runs, and a menu with Copy run command |
| Status line | What it means |
|---|---|
| "On. Runs every Monday at 09:07 (server local time). Next run …" | Scheduled, with the next run |
| "On. Runs when its webhook receives an event." | Started by its webhook |
| "Runs when someone starts it." | No schedule. It runs only when started |
"Off. Turn it on with enabled: true in …" | A markdown task that its own file switches off |
"Schedules are off here. Set HUBZOID_SCHEDULES=1 to run it …" | Code workflow schedules are off on this machine |
"Paused. Resume it with hubzoid schedule resume." | An operator paused it, or it paused itself after repeated failures |
| "The scheduler stopped. Restart the agent to run it again." | Scheduled runs will not fire until the agent restarts |
| "Can't run: …" | The workflow could not be loaded, with the error |
When code workflows run, and the alerts above the list
Markdown tasks in schedule/ run whenever their file exists. Code workflows run on their schedule only with HUBZOID_SCHEDULES=1, or in a deployment that hubzoid run starts from hubzoid.yaml or with several Hubs. Alerts above the table say when the scheduler stopped, when scheduled runs were missed while the agent was stopped (they are not back-filled), or when a workflow could not be loaded. An agent with no workflows links to the markdown tasks guide and offers Copy create command.
Run now
Run now starts a code workflow immediately, as a team run that acts as the workflow's own account, not as you. It is offered for code workflows that loaded and do not start from a webhook. It needs organization administration or Run and control workflows in the agent. A workflow with inputs opens a form first, which names the account it runs as. Settings says "Run started", or "A run is already in progress." The run is recorded in the audit log as started by you.
Copy run command copies the hubzoid schedule run command for the server. For a markdown task, the command takes the file name without .md:
hubzoid schedule run my-hub monday-brief✓ done in 1 round(s): Published "Monday brief" (support hours, 30-day refund window, $500
large-order approval) from knowledge/house-rules.md.Webhooks
An agent with named webhook workflows shows a Webhooks table below the workflows:
Every column in the Webhooks table
| Column | Contents |
|---|---|
| Webhook | Its name and the public URL to give the sender, with a copy button |
| Starts | The workflows the webhook starts |
| Verification | How a delivery is verified, such as a shared-secret header, a timestamped HMAC or GitHub's signature |
| Last 24 hours | Events by state: waiting, running, succeeded and failed |
A webhook with failures expands to its latest failed events, each with the error and Copy redrive command. Payloads, headers and digests are never shown. Setup is in Webhooks.
Who a workflow runs as
Every scheduled workflow and markdown task runs as an ordinary account. The first match wins:
run_ason the@workflowdecorator, or in the task's frontmatterHUBZOID_WORKFLOW_USERin the hub's configuration, then in the deployment's- the owner recorded at setup,
admin@localhoston a laptop
That account must exist, must not be awaiting approval or blocked, and needs Use this agent plus the capabilities its tools require. Grant them on the agent's Access tab like anyone else's. Hubzoid never falls back to another account. A report someone runs for themselves in chat, or on their own schedule, runs as that person. Who may run, schedule or see each workflow is set under Workflow permissions. See who a run acts as.
A workflow's runs
View runs, or the workflow's name, opens its runs at /settings#/agents/<key>/runs/<workflow>, newest first, headed "Runs of" with the workflow's name. Runs are shown 20 per page.
Every column in a workflow's runs
| Column | Contents |
|---|---|
| Run | A short form of the run id. Opens the run |
| Status | The status tag |
| Started, Duration | When it started and how long it took |
| Trigger | Team schedule, Personal schedule, Chat, Run now, CLI, Webhook or Update now |
| Started by | The person who started it, or the schedule or webhook |
| Runs as | The account the run acted as |
| Inputs | The inputs it ran with, with hidden values masked |
| Result | The run's output, its error, or Private when the result belongs to another account |
Workflow names follow one pattern: monday_brief is a code workflow by its function name, md:monday-brief is the markdown task in schedule/monday-brief.md, and evals is a scheduled eval run.
A run's details
Select a run to open it at /settings#/agents/<key>/runs/<workflow>/<run-id>.
- The header shows "Run of" and the workflow name, the status, the agent and the start time.
- Run id (with a copy button), Started, Completed, Duration and Runs as follow, in your browser's time zone.
- Result shows the output. A failed run shows the error.
- Steps lists each recorded step with its function name, Done or Failed, start time and duration. Expand a step to read its output or error.
- Copy cancel command for a queued or running run, Copy run again command for a finished one, and Back to runs.
Run output and errors are shown up to 8,000 characters, and each step's error up to 4,000. A run id that is not in this agent's history shows "Run not found".
What managers can see
People who manage an agent see each run's workflow, status, timing, trigger, account and a failure summary. What a run produced belongs to the account it acted as.
Who sees results, and the server view
Its result and step outputs are shown only when you are signed in as that account. Everyone else sees Private, and for a failed run only the kind of error. Hubzoid's own configuration errors are shown in full, because they name settings rather than data. Administrator rights alone never reveal a person's run results.
On the server, hubzoid schedule status shows results in full, because whoever runs it can read the workflow database anyway.
Runs across agents
Settings → Activity → Runs (/settings#/runs) lists workflow runs across the agents you manage, newest first.
Every filter, and how a shared link keeps its time range
| Filter | Options |
|---|---|
| Agent | All agents, or one agent |
| Status | Any status, Running, Succeeded, Failed or Cancelled |
| Time range | Any time, Last 24 hours, Last 7 days or Last 30 days |
| Run id | One exact run id |
| Auto-refresh | Reloads the list every 10 seconds |
With auto-refresh off, a time range is fixed to exact start and end times in the address, so a shared link shows the same runs later. With auto-refresh on, the range moves with the clock. Runs are shown 20 per page, filtered on the server.
Statuses
| Engine state | Label | Status filter |
|---|---|---|
SUCCESS | Succeeded | Succeeded |
ERROR | Failed | Failed |
MAX_RECOVERY_ATTEMPTS_EXCEEDED | Gave up | Failed |
PENDING | Running | Running |
ENQUEUED | Queued | Running |
CANCELLED | Cancelled | Cancelled |
Gave up means the engine stopped trying to recover an interrupted run after repeated attempts. Other states, such as DELAYED, appear under their own name.
What stays in the CLI
Apart from Run now, Settings does not change runs. The other controls run on the server, or in chat for people granted Run and control workflows.
| Action | Command |
|---|---|
| Start now | hubzoid schedule run my-hub monday-brief. Add --input key=value for each workflow input |
| Pause a schedule | hubzoid schedule pause my-hub monday-brief. Queued and running runs continue |
| Resume | hubzoid schedule resume my-hub monday-brief. A markdown task that became due while paused runs once. Code workflows do not back-fill |
| Cancel a run | hubzoid schedule cancel my-hub <run-id>. It stops at its next step, and work already done is not undone |
| Inspect | hubzoid schedule list my-hub and hubzoid schedule status my-hub |
How run controls are recorded, and where runs are stored
Starting, pausing, resuming and cancelling are recorded in Activity → Audit log under Access changes, as sentences such as "paused the monday_brief workflow in My Hub". A command on the server shows the actor as a server operator with the account and host that ran it.
Runs come from the workflow engine's own database: .hubzoid/dbos.db per hub, or PostgreSQL when the deployment uses it. Hubzoid keeps no second copy of run history.