Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.armature.tech/llms.txt

Use this file to discover all available pages before exploring further.

Every Armature workflow has a schedule that controls when it executes. Schedules range from fully automated cron expressions that fire on a fixed interval to manual-only workflows that run only when you explicitly trigger them. Choosing the right schedule for each workflow keeps your test suite responsive without generating unnecessary noise.

​
Schedule types

​
Cron schedules

A cron schedule runs the workflow automatically at the interval you specify. The editor provides preset options for the most common intervals, and you can enter any valid five-field cron expression for custom timing. Available presets:
LabelCron expression
Manual(no schedule)
Every 15 minutes*/15 * * * *
Every 30 minutes*/30 * * * *
Hourly0 * * * *
Daily at 09:000 9 * * *
To use a custom interval — for example, every six hours at the top of the hour — enter the cron expression directly in the schedule field. Armature displays a human-readable label below the input so you can confirm the expression parses correctly. The editor also shows the next scheduled run time once a schedule is active.
Match your schedule to how often your MCP server changes. A server that receives multiple deploys per day benefits from an every-15-minutes workflow on critical paths. A stable server may only need daily or weekly coverage.
When you select multiple tester models on a workflow, each model runs on the same cron schedule with staggered start times. You can see how many models are in play from the schedule label (e.g. “Hourly · across 3 models”).

​
Manual-only schedule

A manual-only workflow has no cron expression. It runs only when triggered explicitly — either from the dashboard or via the run_workflow_now MCP API tool. Manual-only is the default for regression drafts created from failing runs.
Manual-only workflows still appear in the Workflows list with a schedule label of “Manual”. They count toward coverage reports and can be triggered by editors, admins, and owners via the MCP API.
Use manual-only schedules for:
  • Regression guardrails you want to run on-demand after a deploy.
  • Exploratory workflows you are still authoring and not ready to automate.
  • High-cost or slow workflows where on-demand triggering is more appropriate than continuous scheduling.

​
Pausing and resuming a workflow

Pausing a workflow suspends all scheduled runs without deleting the workflow or any of its run history. The workflow remains visible in the list with a Paused status badge. To pause a workflow, open the workflow editor and toggle the Enabled / Paused switch in the top-right of the editor header. Save the change. To resume, toggle it back to Enabled and save again.
Pausing a workflow does not affect runs that are already in progress. If a run started before you paused the workflow, it completes normally.
When to pause instead of delete:
  • You are refactoring the prompt or criteria and want to avoid false failures during the interim.
  • The MCP server is undergoing planned maintenance and you expect errors.
  • You want to archive a workflow temporarily while keeping its run history for reference.
Deleting a workflow stops runs permanently and removes it from the list, though past runs and traces are preserved. If there is any chance you will want to resume the workflow, pause it rather than delete it.

​
Triggering a manual run

You can trigger a run at any time, regardless of schedule, from two places: From the workflow list:
  1. Find the workflow in the list.
  2. Click the Run history button to navigate to its runs, then use the Run now action at the top of the run history page.
From the MCP API: Use the run_workflow_now tool to dispatch a manual run programmatically. The tool accepts an optional wait parameter — when set, Armature polls until the run reaches a terminal status and returns the result inline. This is useful in CI pipelines or repair loops where you need the outcome before proceeding. 
run_workflow_now(workflowId: "<id>", reason: "post-deploy verification", wait: true)
run_workflow_now requires editor role or higher. Viewers can read run results and compare runs but cannot trigger new runs via the API. See the MCP API overview for the full role matrix.

​
Viewing upcoming and past runs

The workflow detail page includes a History tab that shows recent runs for that workflow — status, model, duration, and start time. Click any run row to open the full run detail with the tool-call trace and per-criterion verdicts. For a broader view across all workflows, navigate to Run history in the sidebar. You can filter by workflow, model, status, and time range to find the runs you care about. From the Monitoring dashboard you can also see the run timeline sparkline and the top failing workflows panel, both scoped to the time range you select.