Run Limits
Every duty carries per-run cost guards — a cap on credits and a maximum runtime, both set in the duty editor's Advanced section — so one stuck or looping run can never burn through your month's credits on its own.
Why per-run guards exist
A duty that gets stuck — waiting on a page that never loads, retrying a failed step, or looping through more items than expected — could otherwise keep spending credits indefinitely. Run limits cap the damage a single bad run can do, independent of how carefully the duty's instructions were written.
Credit cap per run
Set a maximum number of credits a single run of the duty is allowed to spend. If a run hits the cap, it stops there rather than continuing to spend — you get a partial result and a clear stop, instead of an open-ended charge against your monthly credits.
Max runtime per duty
Set how long a single run is allowed to take before it's cut off. This protects against runs that hang rather than fail cleanly — a page that never finishes loading, or a step waiting on something that will never arrive. Once the runtime limit is hit, the run ends.
Where to set them
- Open the duty's editor.
- Go to Advanced.
- Set the per-run credit cap and the maximum runtime.
- Save — the new limits apply from the next run onward.
Plan-level defaults
Even if you never touch Advanced settings, every run already has a plan-level default for both credits and runtime, so no duty is ever truly unbounded. Setting your own per-duty limits lets you tighten those defaults for duties you know should be quick and cheap, or loosen them for duties that legitimately need more room to work.
Choosing sensible limits
Base the cap on what a normal, successful run actually costs — check a few completed runs of the duty and set the credit cap a bit above that, not an arbitrary round number. Do the same for runtime: a duty that reliably finishes in two minutes doesn't need a thirty-minute allowance, and giving it one only delays how quickly you find out something is wrong.
What happens after a limit is hit
A run that stops on a limit is treated as an incomplete run, not a silent success — check its output and run history before assuming the work was finished. If a duty keeps hitting its limit on otherwise normal input, that's usually a sign to revisit its instructions rather than simply raising the cap.