---
title: Runs
description: 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.
canonical_url: https://hubzoid.com/docs/settings/runs
last_updated: 2026-10-25
---

# 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](https://hubzoid.com/docs/concepts/workflows-and-schedules). Operating them from the server is in [Operating runs](https://hubzoid.com/docs/guides/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.

![The My Hub agent's Workflows tab. One row, Monday brief, with its purpose, the status On. Runs every Monday at 09:07 (server local time) with the next run, Runs as You (the local owner), View runs and a menu.](https://hubzoid.com/docs-assets/app/agent-workflows-light.webp)

One status line per workflow says whether it will run, and what to do if not.

**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`:

```bash title="Terminal"
hubzoid schedule run my-hub monday-brief
```

```text title="Output"
✓ 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](https://hubzoid.com/docs/guides/webhooks).

## Who a workflow runs as

Every scheduled workflow and markdown task runs as an ordinary account. The first match wins:

1. `run_as` on the `@workflow` decorator, or in the task's frontmatter
2. `HUBZOID_WORKFLOW_USER` in the hub's configuration, then in the deployment's
3. the owner recorded at setup, `admin@localhost` on 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](https://hubzoid.com/docs/settings/agents-and-access#workflow-permissions). See [who a run acts as](https://hubzoid.com/docs/concepts/workflows-and-schedules#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.

![Activity on its Runs tab: workflow runs across the agents you manage, newest first, with filters All agents, Any status, Any time, Run id and Auto-refresh. One row: My Hub, md:monday-brief, run cf4209ea, Succeeded, started 1 minute ago, with its duration and result.](https://hubzoid.com/docs-assets/app/settings-activity-light.webp)

Filter by agent, status, time or run id. Select a run to open its details.

**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.

## Related

- [Operating runs](https://hubzoid.com/docs/guides/operating-runs): Pause, resume, cancel, drain and troubleshoot scheduled work on the server.
- [Markdown tasks](https://hubzoid.com/docs/guides/markdown-tasks): Give the agent work that runs on a schedule.
- [Schedules and reports](https://hubzoid.com/docs/settings/schedules-and-reports): The reports people run and repeat for themselves.
- [People and activity](https://hubzoid.com/docs/settings/people-and-activity): Read run controls and access changes in the audit log.
