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.