Troubleshoot and Fix Failed Runs

Use this page when a managed agent automation does not run, or when a run fails. To test an automation before you use it, see Test Automations.

Instruction automations and code automations do different things after a failed run:

	Scheduled instruction automation	Code automation
When Type pauses it	After three consecutive failed runs, or immediately when a saved account blocks the run	After the first failed run
Notice	If Type can identify the creator and the run thread, it posts a pause notice there. The notice mentions the creator.	Type tells the owner. The pause reason includes the last error.
Repair	You find and fix the cause.	Use Fix for an unavailable saved account. For other failures, Type starts a repair agent; you can also fix the code yourself.
Resume	You select Enable.	After account repair, select Enable. For code repairs, a successful verification run or deploy enables it again.

Common issues

Issue	What to check
No thread was made	The trigger configuration, the enabled state, the webhook URL, app permissions, and the schedule time. Email needs an address that you create.
The managed agent cannot access data	The scope of the connection, the connection assignment to the Space, and expired credentials.
The output is too broad	Make the trigger narrower, or write clearer instructions.
There are too many notifications	Examine Settings → Notifications, thread subscriptions, and the automation instructions.

When an automation stops running

• Scheduled instruction automation paused: Three consecutive failed runs pause the schedule. An expired, revoked, or removed saved account pauses it immediately. Examine the errors and fix the cause. Test the automation, then enable it. See Recover an automatically paused schedule.
• Code automation paused: The first failed run pauses the automation. Use Fix for an unavailable saved account; otherwise, Type starts a repair. See Fix a failed code automation run.
• RSS source disabled: Five consecutive fetch errors, or one HTTP 410 response, stop polling. Fix or replace the feed, then resume it. See Recover a disabled RSS feed.
• Webhook rejected: Examine the HTTP response, the JSON body, the secret, and the signature. See webhook requests and errors.

Recover an automatically paused schedule

Type pauses a scheduled automation after three consecutive failed runs. If an expired, revoked, or removed saved account prevents the run from starting, Type pauses it immediately. If Type can identify the creator and the run thread, it posts a pause notice in that thread. The notice mentions the creator. A paused schedule does not start scheduled runs until someone enables it again.

1. Open the automation from Automations in the sidebar.
2. Open Run history. Open the failed run, and read the error and the tool results.
3. Fix the cause. For an unavailable account, select Fix beside it under Needs attention to sign in again or choose another account. See Fix an unavailable account. You can also restore the execution owner’s Space access or correct the instructions or model settings.
4. Select Save.
5. Select Test to test the saved definition. The test runs as you. Also make sure that the automation creator has access before you resume the schedule.
6. Select Enable. In the Space automation list, the same action is Resume task in the menu.
7. Examine the next scheduled run in Run history.

Note

Fixing an account, saving changes, or running a private test does not resume a paused schedule. You must select Enable.

Fix a failed code automation run

A run fails when the method returns err(...), throws, goes over a limit, or when Type cannot start it.

If a saved account blocks the run, Type pauses the automation without starting a repair agent or replaying the event. Select Fix to sign in again or choose another account, then select Enable. See Fix an unavailable account.

For other failures, Type does not retry a failed run automatically. It pauses the automation and starts a repair. At the end of the repair, Type runs the original event one more time to verify the fix. This verification run is a real run with real access. It is not a fixture test.

What happens after a failure

The following repair flow applies to code failures, not unavailable saved accounts.

1. Type pauses the automation after the first failed run. The pause reason includes the last error.
2. Type tells the owner of the automation.
3. Type starts one repair agent in the Space. The agent reads the error, changes the code, and tests it with fixtures.
4. Before the repair finishes, the failed run’s writes must be reconciled. See Reconcile before verification.
5. When the repair agent finishes, Type runs the saved code one time: the verification run. It uses the original event, the current checkpoint, and real access.
6. If the verification run succeeds, Type resumes the automation. A schedule continues at its next planned time.

Reconcile before verification

The failed run can have made writes before it failed, for example a Slack reply or a new issue. Type does not undo them. The verification run runs the same event again, so it can make the same writes again.

Before the repair finishes, make sure that a second run of the event is safe:

1. Read the run history of the failed run. Find each write that it started.
2. Check each destination. Find out which writes are complete and which are not.
3. Make the fixed code skip or update the completed work. For example, read before you write, or use the provider’s idempotency key. See Write Safely.
4. If you cannot make the verification run safe, ask the repair agent to request human help. The automation then stays paused, and Type does not start the verification run.

The automation stays paused if:

• the repair takes more than 30 minutes,
• the verification run fails,
• the repair agent asks for human help,
• someone edits the automation at the same time,
• an input request or approval is open.

Note

failurePolicy accepts "pause" and "pause_and_investigate". Both values have the same effect today.

Find the cause

Read the run history:

type-cli automations history --space <space> --automation <automation-id> --status failed
type-cli automations history --space <space> --run <run-id> --include-activity

console.log does nothing in automation code. To see values, use ctx.setOutput() and action logs. Write clear error messages in err(...). The message is the first thing that you see in the run history.

Common causes

Error	Cause	Fix
Invalid subscription event: ...	The event does not match the schema.	Make the schema accept the real provider data. Use z.looseObject() and .nullish().
QuickJS API request budget exceeded	More than 128 requests, or more than 8 at the same time.	Ask for fewer, larger pages. Make fewer calls at the same time.
Type API response exceeds the QuickJS 2 MiB limit; paginate the request	A response was too large.	Ask for smaller pages.
QuickJS result exceeds the 2 MiB combined limit for checkpoint, output, visualization and receipts (... bytes)	The output, checkpoint, report, and handoffs are larger than 2 MiB together.	Return less data. Store large datasets in another place.
Code-only automations cannot invoke an agent	ctx.agent in mode: "code".	Set mode: "code_with_optional_agent" and agent.instructions.
Sandbox commands require a live automation invocation	A sandbox call in a test.	Give the result in toolResponses.
A previous automation run was interrupted; its side effects were not replayed	Type stopped a run before it finished, for example during a server restart.	Check if the run made changes. Then resume.
A timeout	The run took more than 180 seconds.	Do less work in each run. Save progress in a checkpoint.

For more messages, see Errors.

Fix it yourself

You can fix the code before the repair agent does, or after it stops.

1. Change the code. Add a fixture that causes the same failure.
2. Deploy the code: type-cli automations deploy . --space <space>.
3. Make sure that the deploy succeeds. A successful deploy enables the automation again.

Caution

Before you resume, check if the failed run made changes. A run can fail after a write. Type does not undo the write. See Reconcile before verification.

Interrupted runs

If a run stops before it finishes, for example because a server restarts, Type does not run the code again automatically. It marks the run as failed, so that a write does not occur two times. The failure then starts the normal repair. Check the destination before the repair finishes, because the verification run uses the same event.

Events during a pause

• Type does not save new events for the automation while it is paused.
• Events that Type saved before the pause wait. They run after the automation resumes, if the code still subscribes to their event type.
• A schedule does not run missed ticks. It continues at its next planned time.

Keep a feedback thread

If an automation gives a weak result, change the instructions near that example. The best automation instructions usually come from real event payloads and real review feedback.