Diagnosing a Failure

A task that is not doing its job has a small number of causes, and they are worth checking in order.

Where to find it

Architect Panel → Automation:

• Tasks — the scheduled tasks themselves
• Task Log — every execution and its result

Architect Panel → Activity:

• Error Log — the underlying error

Work through these

1. Is it enabled? The most common answer, and the most embarrassing to skip.
2. Is the engine running at all? Check whether any task has logged recently. If none has, the problem is not this task.
3. Is it past its end date, or outside its active window? A task with a window only runs inside it.
4. Has it hit its maximum runs? A capped task stops silently when it reaches the limit.
5. Is it in preview mode? Then it is reporting what it would do rather than doing it.
6. Is it failing? Now read the log entry and the error log.

The first five take a minute between them and account for most cases.

Preview mode is the sneaky one

A task in preview runs, logs, and appears entirely healthy while changing nothing. Somebody set it during testing and did not switch it back, and nothing about the log looks wrong.

Check it early rather than after an hour of reading code.

Then look at what changed

A task that ran for months and stopped is responding to something. A schema change, a permission change, a renamed field, an integration whose credentials expired.

The question is not "what is wrong with the task" but "what changed around it".

Timeouts present as inconsistency

A task that mostly works and occasionally does not is usually running out of time on larger batches. The duration in the log confirms it — successful runs near the limit and failures at it.

The fix is bounding the work, not extending the timeout.

Errors from inside are in the error log

The task log says a run failed; the error log says why. Match them by time, because the task log entry is deliberately short.

Fix the cause, not the symptom

Re-running a failed task clears the alert and leaves the cause. If it failed once it will fail again, and the second failure will be at a worse moment.

Test in preview

Once you have a fix, preview mode is exactly the tool — it exercises the task and reports what it would do without doing it. Use it, then switch it off, and confirm you did.

Watch it after fixing

Two or three runs. A fix that works once and fails on the next batch is common, particularly where the cause was volume.

Worked example

A nightly reminder task had stopped sending. It was enabled, the engine was healthy, and the log showed successful runs every night. It was in preview mode, set during a change three weeks earlier. The fix was one field; finding it took two minutes because preview was on the checklist.

Recommendations

• Check enabled, window, cap and preview before anything else.
• Ask what changed around the task.
• Bound the work rather than extending timeouts.
• Use preview to test, then confirm you switched it off.