Runs and monitoring

Once a site is live, things run on their own: pages render, scheduled jobs fire, API routes answer. This is how you see what happened and track down anything that went wrong.

#What counts as a run

A run is one execution of a workflow: a page render, an API route answering a request, a scheduled job, or a preview/test run you triggered. Every run is recorded on every plan: you can always see what ran, when, and whether it succeeded.

#Where run history lives

There isn't one global "runs" screen; run history sits with the thing that ran, in its studio:

• Workflow: open a workflow and its run panel lists recent executions with their outcome.
• Scheduler: a schedule shows its run history, so you can confirm the nightly job actually fired (and when it last did). A job that ran as a chain shows one row per link, labeled "link 1 of 3" and so on, each with its own outcome and trace.
• Delivery: an endpoint lists the runs it served.

Each entry shows the time, whether it succeeded or failed, and how long it took.

#Reading a failed run

Open a failed run to see why. Alongside the outcome, a run can carry a step-by-step trace: what the workflow did, step by step, and where it stopped. That is what you (or your agent) use to pin down a failure. Hand the details to your agent and it can usually fix the cause.

On the free tier, the detailed trace is kept only for runs you start yourself (a test run or preview). For unattended runs (a scheduled job, a live page serve), the free tier still lists the run and its outcome but doesn't store the step trace. Paid plans keep the full trace for every run. (Very large inputs/outputs are truncated in the stored trace either way.) See Plans and limits.

#Running something on purpose

• Preview / test run. You (or your agent) can run a workflow or endpoint on demand and see the result before it's public. A preview executes the real workflow, so it costs a credit and can have real side effects (like sending email). It's a genuine run, not a dry run.
• Run now (schedules). A schedule has a Run now button that fires it immediately, independent of its clock and of whether it's published. It runs the saved version, so save your edits first. Handy for testing a job without waiting for its next scheduled time.

#A note on times

When a run or a record involves dates and times, the editor shows a timezone control in its header. It governs how times are displayed and entered, so check it's set to the zone you mean before reading a schedule's next-run time or entering one.