Console

The console is Hyperspool in a browser, at https://hyperspool.dev. Locally, a release build of spool dev serves it at http://localhost:18753; sign in with the token spool dev prints. It uses the same API as the spool CLI, so anything it shows is also reachable from a terminal.

Paths on this page are relative to the console, so /dashboard is https://hyperspool.dev/dashboard.

Getting around

The rail on the left holds:

Today (/dashboard), with a count of what needs you.
Timeline (/timeline).
Runs (/).
Workflows (/workflows), with a short list of recent workflows under it grouped as Automations, Pipelines and Scripts, and a link to All graphs on the canvas (/canvas).
More: Schedules (/schedules) and Events (/events).
Agents (/agents), with how many are online, and Settings (/settings) at the bottom.

Your org and project sit at the top of the rail. Open it to switch project, or create an organization of your own with + New organization.

The top bar has search (⌘K, which reaches every page), the copilot (⌘J) and your menu: personal tokens, theme, links to the docs and support, Tell us something… for feedback, and sign out. Feedback sends what you wrote, its category, the page you were on and your org and project; from a terminal, use spool feedback.

Signing in

Sign-in is by invitation. Sign in with single sign-on hands off to the identity provider; an address nobody has invited comes back to the sign-in page with a note saying so. A personal access token (hspat_…) works too, behind Use a personal access token instead.

Someone signed in who belongs to no organization lands on a page that offers Create your organization. Each person can own one Free organization, and one they delete still counts for 30 days. To join someone else’s, ask them to add you (spool org member set <email> --role member).

Today

/dashboard answers “what needs me, and what is going on”:

A row of counts: working, need you, and failed and done in the last 24 hours.
Today so far - each run of the day as a bar from when it started to its last move.
Needs you - approvals waiting for an answer, and steps no agent can run. An approval with no required field is answered in one click; otherwise Answer… opens the gate’s form. Reject asks first, because it cancels the run.
Working now - live runs with the step they are on, the agent running it and their last line of output.
Waiting - runs asleep on a timer or waiting for another run, an agent, a lock or a signal, with how long they have waited or when they time out. A signal wait can be answered from its row.
Went wrong - runs that failed in the last 24 hours, with the failing step and message.
Already known - timers, deadlines and scheduled starts in the next three days.

The Today page: counts of what is working, needs you, failed and done; today's runs by workflow; two approvals waiting for an answer; and, under Already known, a timer and a scheduled start coming up.

Timeline

/timeline shows every run in the project over the last 6 hours, 24 hours, 3 days or 7 days, one lane per workflow. A now-line splits the past from what the server already knows will happen: timers, deadlines and schedules. Open a lane to see each run’s steps, or switch the page to List.

Runs

/ lists the project’s runs, newest first, and refreshes itself while runs are live. Filter by status (all, running, completed, failed, cancelled) or by tag. Runs from a connected repo carry a chip with the repo, the branch or tag, and what triggered them; runs from a schedule link to it.

dry runs switches the list to dry runs from Try it, which are kept apart from normal runs and deleted a day after they end. See Try it.

Run page

/runs/<id> opens on a headline that says what the run is doing: “Waiting for approval”, “Asleep until 14:00”, “Waiting for an agent”, “Queued for deploy”, “Held by the deploy rate limit”, “Failed at build”. Beside it are Cancel run… for a live run and Rerun for a finished one, and links to its parent, the run it reran, or the schedule that started it.

Below the headline:

A forecast of the time left, for a live graph or pipeline run whose workflow has at least five ended runs. See step stats and forecast.
Needs you, when the run waits for approval: the gate’s own form with Approve and Reject and stop the run. Reject takes an optional reason, cancels the run and records the reject on the gate; see approvals. A run waiting for any other signal gets a small form to send it, with an optional JSON payload.
On a failed run, the failing step, its error and the tail of its output, with Rerun from <step> and Rerun everything.
Annotations, errors first.
The steps, in one of three lenses: Journal (each step in the order it ran, the default), Waterfall (queue time, work and waits against the clock, with steps slower than usual marked) and Graph (the shape it ran, for runs that have one). A script’s fan-out children are listed under Activities in the journal.
Sections: Logs (every step’s output, live while the run is), Raw (the event log), Input, and State and Artifacts when the run has any.

A step of a finished graph, pipeline or script run offers rerun from here: a new run that starts at that step and reuses what the steps before it recorded. In a graph or pipeline those steps do not run again; in a script the recorded calls return their results, but the code around them runs again. From a terminal: spool run rerun <run> --from <step>.

A deploy-web run waiting for approval: the headline says so, a forecast from the last five runs gives the work left after the gate, and the gate's form asks for a ticket, an environment and a note, with Reject beside Approve.

Workflows

/workflows lists every name runs were submitted under: a pipeline’s name:, a graph’s name, a script’s file name. Each row shows its kind, its last run, its success rate and typical duration, and flags one that is failing or overdue against its usual cadence. Sort by recent, failing, slowest or name.

/canvas lists the graphs stored in the project and creates new ones.

Workflow page

/workflows/<name> is one workflow. The header says what kind it is, where it comes from (stored in the project, or a file in a repo at a commit) and how its recent runs went. For a stored graph it also holds Save draft and Publish. The views:

Canvas - the graph editor for a stored graph; see Authoring on the canvas. A pipeline or a graph from a repo is drawn read only, with Fork to canvas to copy it into the project as an editable graph.
Words - the workflow read as sentences. For a stored graph, the highlighted values edit the draft; adding and wiring steps stays on the canvas.
Runs - this workflow’s runs, and a table of its steps across recent runs.
Code - named for what it shows: Graph YAML for a graph, Pipeline YAML for a pipeline, Script for a script. A stored graph’s draft can be edited here as YAML; see the graph as YAML.
Settings - what starts it (triggers, schedules), when a run may start (run admission, editable for a stored graph), the input it takes, its variables, outputs and credentials, its versions, and Delete.

A workflow page on its Canvas view: a four-step graph, the palette on the left, and the inspector for the selected fetch step on the right.

Step stats and forecast

The Runs view’s Steps table reads the workflow’s most recent ended runs (up to 200) and shows, per step, its usual time, its slow end (90th percentile), how often it failed and how many runs reached it. An approval or wait depends on a person or a timer, so its times are shown as they were rather than as something to expect.

The same numbers drive the run page: a live run gets a band from the typical finish to the slow one, plus the times that are certain (a timer waking, a deadline). A step still waiting for a person turns the band into the work left after it. With fewer than five ended runs there is no forecast. Dry runs get neither.

The Runs view of the deploy-web workflow: each step's typical and slow (90th percentile) time, failures and how many runs reached it, above the list of its runs.

Schedules

/schedules lists schedules and creates them with New schedule; /schedules/<id> shows one, edits it in place (its id and run history stay), pauses and resumes it, and lists its recent runs. Run now fires it once without moving its cadence, also while paused; if runs of it are already going it lists them and offers Run alongside. See Schedules.

Events

/events is the project bus: recent events with their type, subject, payload and the runs each one started, filtered by Triggers, Runs, Forge or Custom, or by a type prefix. Below it:

Webhooks - each webhook’s deliveries from the last 7 days: whether it was verified and accepted, and what every handler did with it (started a run, skipped on its when, failed to evaluate it, refused). This is where to look when a push arrived and nothing ran.
Handlers - what the project’s handlers listen for and what they start.

See Events and handlers.

Agents

/agents shows what can run your work. Hyperspool’s own environments start on demand for shell, polyglot, connector and build work, so those need no agent of your own. What the fleet can do lists each capability as online, on demand or offline, and names any capability whose agents are all down.

Agents you run (see Deploying agents) are listed one per card: their capabilities, the step they are running, scope, build, when they were last seen and their tokens. Show finished also lists on-demand environments that came and went. A token minted and never used shows as issued but never claimed, the usual sign of a half-finished setup. The Shut down and Forget buttons stay disabled on your account; to stop an agent you run, stop its process.

Settings

/settings opens on Connections. Its sections, grouped by what they belong to:

Project: Connections (/settings/connections), in five tabs:
- Repositories - connect a repo so its pushes build; the console side of spool repo connect. See CI from a repo.
- Webhooks - inbound webhooks that put an event on the bus per delivery: create, rotate, delete, and register one on GitHub, Gitea or Forgejo.
- Connected accounts - identities granted through a provider’s consent screen.
- Credentials - typed auth for http and connector steps, and for jobs that take one as an environment variable.
- Secrets - environment variables every steps: and script: job in the project gets.
Values are write-only: nothing shows a secret or credential again. Anyone in the project can read the lists; changes need an admin.
Organization: Projects (create, switch, delete; deleting asks you to retype the slug), Members (org and project roles; adding an address with no account invites it), Usage (what the org holds and is billed on, over 7, 30 or 90 days; admins only), Billing (the plan; owners change it) and Data (download an export of the org; its owner deletes it there). See Exporting and deleting.
You: Account (download your data, delete your account), Tokens (mint, list and revoke personal access tokens; a new one is shown once) and Appearance (theme).

Old paths such as /connections and /members redirect to their place under /settings.

Copilot and the pipeline preview

The copilot (⌘J) opens as a dock beside any page and drafts and edits graphs. Elsewhere in the console it shows a proposal you name and save yourself; on a canvas it writes to the draft on screen, which you can undo and still have to save.

/pipelines takes a pasted pipeline YAML and draws the graph it compiles to, read only. It is not in the rail; open https://hyperspool.dev/pipelines directly.