Autonomous Tasks & Self-Healing
Documentation and guides for OutcomeDev.
When you hand a task to OutcomeDev, you should be able to close the tab, put your laptop to sleep, and come back to a result. This page explains the machinery that makes that promise real: how tasks heal themselves when something goes wrong, how the platform manages your sandbox compute automatically, and exactly what you can expect in every scenario.
The Core Promise
Every task you start ends in one of exactly two ways:
- It completes, even if it had to recover from a hung command, a provider outage, or platform maintenance mid-run.
- It fails honestly, after automatic recovery was exhausted: any partial work is pushed to your branch so nothing is lost, the sandbox is stopped so billing stops, and you get a notification explaining what happened.
There is no third outcome. A task can never spin forever, silently burning your runtime budget, waiting for you to notice.
How Self-Healing Works
Your task is protected by four independent layers, each watching on a different timescale. Whichever notices a problem first, acts first.
Layer 1: While you're watching (~3 minutes)
If you have the task page open and the agent goes quiet, you'll see a warning banner after 3 minutes, and about 30 seconds later the platform automatically nudges the agent back to work. You also get a manual Nudge Now button if you'd rather not wait.
Layer 2: The hang watchdog (~5 minutes)
Agents run real commands in a real Linux VM, and occasionally a command hangs (a dev server started in the foreground, a network call that never returns). A healthy agent produces continuous output, so five minutes of total silence means something is stuck. The watchdog terminates the hung process and resumes the exact same session with a note about what happened. The agent picks up mid-task with all of its context, it does not start over.
Layer 3: The recovery service (~10 minutes)
Every task continuously reports a heartbeat while it works. A background service sweeps for tasks whose heartbeat has gone silent, which catches even the rare case where the platform itself restarted mid-task. Stalled tasks are automatically resumed with full conversation context, up to two times. If both resumes fail, the task is closed out honestly: partial work pushed to your branch, sandbox stopped, clear error message, notification sent.
Layer 4: Budget protection (~5 minutes)
Independently of all the above, a resource governor stops any sandbox belonging to a user whose runtime balance has run out, and reclaims idle sandboxes after their grace period. Your spend is bounded no matter what.
You'll see recovery events right in your task timeline, messages like "Watchdog: agent produced no output, terminating hung process" or "Watchdog: no progress detected, automatically resuming the agent", so nothing happens behind your back.
Auto vs Manual Sandbox Mode
Every task has a sandbox, an isolated cloud VM where the agent works. Who manages its lifecycle is up to you, but the default is: nobody has to.
Auto mode (the default)
The Auto-manage sandbox option is checked by default when you create a task. The platform:
- Sets the duration ceiling for you. No "maximum duration" homework; the task runs as long as it needs, bounded automatically by your plan and remaining runtime balance. The ceiling is a safety cap, not a prediction: you're billed for actual usage only, and the self-healing layers stop runaway tasks long before any ceiling matters.
- Keeps the sandbox warm only while you're actually there. If you have the task open when it finishes, the sandbox stays hot for instant follow-ups, and stays hot for as long as you keep the task open. Once you leave, it stops a few minutes later. If nobody has the task open when it completes (a scheduled overnight run, a closed tab), the sandbox stops immediately, zero idle compute.
- Stops the sandbox automatically to save your runtime budget.
- Wakes things back up transparently when you return. Send a follow-up hours later and the platform either wakes the standby sandbox (near-instant) or provisions a fresh one on the same branch (30–90 seconds), your conversation and code continue exactly where they left off.
You never think about sandbox lifecycle. That's the point.
One option stays visible even in auto mode: Persistent Sandbox. Whether a disk should live forever is a statement of intent the platform can't guess, so it's always your call (default off). It composes with auto mode cleanly: compute is still stopped to save budget, but the environment is never deleted, your next message wakes the exact same disk.
Manual mode
Uncheck Auto-manage sandbox to reveal the granular compute controls, including the Maximum Duration picker (useful as a hard per-task spend cap) and:
| Control | What it does | When to use it |
|---|---|---|
| Keep Alive | The VM stays hot until your task's time limit, even after the agent finishes. | Rapid-fire iterative sessions where even a 5-minute warm window isn't enough. |
| Warm Window | The presence-aware post-completion grace period, on or off. | Turn off to reclaim compute the instant a task finishes. |
| Persistent Sandbox | (Also available in auto mode.) The disk is never garbage-collected, a durable "pet" environment you can return to indefinitely. | Long-lived workspaces you'll reuse across days. |
One important guarantee: if you run a task against an existing sandbox you've already set up, auto mode never touches its settings, your durable workspace is never downgraded or deleted by automation.
Manual mode changes lifecycle, not reliability, all four self-healing layers protect manual-mode tasks identically.
What You Can Expect: Scenarios
Everything goes right. Task runs, changes are pushed to a branch, a PR summary is ready. If you're watching, the sandbox stays warm for instant follow-ups until shortly after you leave; if you're not, it stops on the spot. You paid for active time, plus warm minutes only if you were actually there to use them.
A command hangs mid-task. Five quiet minutes, then the watchdog kills it and the agent resumes with a note to avoid blocking commands. Your task finishes a few minutes later than it would have. You did nothing.
Platform maintenance hits mid-task. Heartbeats pause; within ten minutes the recovery service resumes your task with full context. Most users never notice it happened.
The task genuinely can't finish (the repo was deleted, a provider is hard-down). Two automatic resumes are attempted. Then the task fails cleanly: partial work is on your branch, the sandbox is stopped, and your notification explains what happened. Worst-case wasted compute is bounded to roughly half an hour, never an overnight drain.
You come back the next day with a follow-up. The sandbox was long since reclaimed (auto mode). Your message transparently provisions a new environment on the same branch and the conversation continues. No dead ends.
Your runtime balance runs out mid-task. The governor stops the sandbox within minutes, marks the task stopped, and prompts you to top up. You are never billed past your balance.
Scheduled Tasks Run the Same Way
Scheduled tasks (see Scheduled Tasks) fire every minute via redundant triggers, with or without anyone online, and every run gets the same four-layer protection. A 3 AM scheduled task that hits a snag heals itself the same way a supervised one does.
Why This Design
Most AI coding tools treat a stuck agent as the user's problem: you notice the spinner, you hit stop, you type "continue." OutcomeDev treats it as the platform's problem. The design borrows the supervision patterns of production job orchestrators, heartbeats, lease-based claims, staged recovery ladders, and applies them to AI agents with session-preserving resumes, so a retry continues the work instead of restarting it. The result is the experience you'd expect from a reliable employee: you delegate, they deliver, and if something went wrong along the way, they already handled it.