Task Log

The task log is the audit trail for the platform's background-task engine. Every scheduled or queued task that runs leaves a row here recording when it started, how long it took, and what happened.

What Each Row Tells You

• Started — timestamp.
• Task name — e.g. nightly_invoice_sync.
• Duration — how long it took.
• Status — success, failure, timeout, cancelled, retry-queued.
• Records processed — volume metric the task reports.
• Triggered by — cron schedule, manual invocation, event hook.
• Output — stdout/stderr captured (expand to view).

Useful Queries

• All failures in the last 24h — “why didn't the dashboard refresh overnight?”.
• All runs of send_renewal_emails last week — “did the campaign run on schedule every day?”.
• Long-running outliers — “which task took 30 minutes when it normally takes 30 seconds?”.

Worked Examples

• Missed renewal: Customer complains their subscription wasn't renewed. Filter log for process_subscription_renewals, see it failed at 03:00 with a Stripe rate-limit error. Replay the failed task.
• Performance regression: Sort by duration descending. The nightly_aggregation task ran in 90 seconds last week, 8 minutes today. Investigate the SQL plan changes.
• Volume audit: Sum records-processed across all tasks for the month — confirms ingestion volume for capacity planning.

When a background task fails, the task log captures the output, but you still need a systematic process to figure out the cause and decide whether to retry, fix and retry, or accept the failure.

Systematic Debugging

1. Read the error message. It almost always points at the root cause directly.
2. Look at the input parameters. Was it a bad input? Missing required field? Stale cached value?
3. Check related logs. Activity log, email log, API log — the task may have failed because something upstream failed.
4. Re-run on a single record. Use the “run on input” button to test against just the offending record.
5. Reproduce in dev. Pull the same input and run locally with full debugger.
6. Apply fix. Either code change, config change, or data clean-up.
7. Retry the failed batch. Or mark resolved if the underlying issue went away on its own.

Common Failure Modes

• Timeouts: Long-running task hit the PHP max_execution_time. Solution: chunk the work or raise the limit.
• Memory limits: Big imports OOM'd. Stream rows instead of loading into an array.
• External service errors: Stripe/SendGrid/Slack returned 503. Solution: built-in retry with exponential backoff usually handles this — check it triggered.
• Locked rows: Two tasks tried to update the same row. Reduce concurrency or use row-level locking with a sensible timeout.
• Schema drift: Task references a column that was renamed. Update the task code.

Worked Examples

• Email send failed for one user: Log shows “invalid recipient address”. Look at the user's email field — it had a trailing space. Clean up, retry.
• Nightly export timed out: 200,000 rows now instead of 50,000. Chunk into 4 batches; reschedule.
• External API down: Multiple tasks failed with 5xx from Stripe. After Stripe recovers, replay all queued failures.
• Memory exhausted: Convert foreach ($all_rows as $row) to a cursor pattern. Re-run the task.