Task Log

Reading the Task Log

Every task execution writes a log entry. That log is the only evidence that your automation is running.

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 detail behind a failure

What an entry records

Which task ran, its result, any data it returned, how long it took, and when it executed. Four short facts that answer most questions about automation.

Absence is the important signal

Everybody looks for failures. The more dangerous case is a task that has simply stopped appearing — disabled by somebody, past its end date, or an engine that is not running at all.

A failing task is loud. A task that stopped running is silent, and it can be silent for months.

Check the newest entries first

The log is most useful read backwards. Is the most recent entry from minutes ago, or from last Tuesday? That single question tells you whether the engine is alive before you look at anything else.

Duration is an early warning

A task that took two seconds for a year and now takes ninety is a task whose data has grown past what its approach can handle. It has not failed yet, and it will.

Watching duration over time is the cheapest predictive signal available.

Look for the pattern in failures

Every night at the same time, or once a week, or only at month end. The pattern usually identifies the cause faster than the message does — a failure at two every morning is competing with something else that runs at two.

The returned data matters

Tasks record what they did — how many records processed, how many messages sent. A task succeeding while processing nothing is a task that is not working, and it looks identical to a healthy one unless you read that field.

Have a routine

Once a week, read the log: newest entries recent, no repeating failures, durations stable, counts plausible. Five minutes, and it catches nearly everything before a user does.

Keep it, but not forever

The log grows continuously. Long enough to spot a trend and investigate an incident — a few months for most organisations. Then prune it, or it becomes one of your larger tables.

Worked example

A weekly review found a nightly task whose duration had grown from four seconds to two minutes across a quarter. It had not failed. Investigation showed it was re-scanning the whole table each run; adding an index and a date bound returned it to seconds before it ever timed out.

Recommendations

• Check the newest entry first — it says whether the engine is alive.
• Watch for absence, not just failure.
• Track duration as an early warning.
• Read the counts — success processing nothing is not success.

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.