Skip to main content
Available for self-hosted Business plan and above
Path: Admin Panel → Computed Outbox Use Computed Outbox when formula, lookup, or other computed field values stop updating or take much longer than expected. The page shows the overall task health, the jobs moving through the queue, tasks that may need recovery, and any space whose computed tasks are currently paused.

​
Read the Health Status

The status beside the page title shows whether computed tasks need attention: When the status needs attention, the page lists the reason.

​
Find a Task in the Queue

Live BullMQ queue lists the jobs Teable still retains, so you can follow one computed task or look for slow ones. Each row is one task by default, and it moves through states in place as Teable retries it. Switch to Deliveries when you need the full attempt history of a task or want to hunt for slow runs. To narrow the list:
  • Click the state tiles above the table to filter by state: Waiting, Active, Delayed, Failed, Completed (retained), and so on. You can select several at once, and hovering a tile explains what that state means.
  • Filter by Space, Base, Cause, or Outcome, search for a task, Base, Space, or error, or set a minimum processing time to surface slow tasks.
  • Click a row to open its detail: queue timestamps, delivery lag, processing time, and, for failed deliveries, the full failure reason with the redacted SQL.
Completed does not mean the task did work. The outcome badge says what the delivery actually did: Processed ran the task, No-op found nothing left to do, Deferred rescheduled it for later, and Parked means its scope is paused. The Outcome filter narrows the list by that result and shows how many deliveries each one covers, so pairing Completed (retained) with Processed leaves only the deliveries that really ran the task.
A failed row is the history of one delivery attempt, not a stuck task. The durable task keeps retrying on its own, so read the Ledger state column to decide whether to act: Settled means a later retry already succeeded, and Dead letter links to anomaly maintenance. Settled failures are hidden by default; a banner shows how many there are and lets you reveal them. Clear failed history removes the retained failed-job records from the queue only. It repairs nothing, and dead letters remain in Anomaly maintenance. A state tile can also count entries whose job data no longer exists in Redis, usually left behind after eviction or data loss. The list cannot show them, so the page explains the gap under the table. Teable sweeps such leftovers out of the failed state on its own; Clear failed history removes them right away.

​
Handle Anomalous Tasks

The Failed count and Anomaly maintenance show different types of problems, so their numbers may differ.
Anomaly maintenance collects anomalies into problem groups, one per Base, source table, and error, so a single root cause is easy to spot. Review the failure reason and fix the underlying problem before you recover anything. Expand a group to read its error details and the tasks it covers; those rows are for inspection, and recovery always runs on the group as a whole. The actions a group offers depend on its type: After a group recovery, Teable reports how many tasks it restored, how many were newly queued or already queued, and how many were delivered or deferred. Workers then consume the group under the current concurrency and task-splitting limits. A group marked Base deleted belongs to a Base that no longer exists. Recovering it would fail again immediately, so Discard group is the only action offered.

​
Pause Computed Tasks for a Space

When one space’s computed tasks are making an incident worse, pause that space in Computed task pauses rather than stopping the whole instance.
1

Open the pause dialog

Click Pause a space.
2

Find the space

Search by space ID or name, then select it from the results.
3

Choose how long

Set Pause duration to 15, 30, 60, or 120 minutes.
4

Record why (optional)

Note the incident or maintenance window in Reason.
5

Confirm

Click Confirm pause.
A pause only stops workers from claiming new computed tasks for that space. Tasks already running are not interrupted, and matching tasks wait until the pause ends rather than being dropped. A pause always expires on its own, and two hours is the longest you can set. If the incident outlasts it, pause the space again from this page. The list shows every active pause with who created it, why, and when it auto-resumes, along with how many pending tasks the active pauses are holding, so you can judge the backlog a resume will release. To lift one early, click Resume on its row and confirm.

​
Adjust Concurrency

The queue section has two concurrency controls. Each one writes a cluster-wide override that every process picks up within about 15 seconds, with no restart, and each can be reset so processes return to their own environment setting. An Overridden badge marks a control that is no longer on its default. Raise the claim caps when one busy Base is the bottleneck, and per-process concurrency when many Bases are queued at the same time.
Higher concurrency puts more load on your database. Spaces that store their data in a database tenant keep the environment defaults for the claim caps, because their connection pools are sized for those values.
Last modified on August 12, 2026