> ## Documentation Index
> Fetch the complete documentation index at: https://help.teable.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Computed Outbox
> Monitor BullMQ delivery and computed task backlog in the Admin Panel.
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:
| Status | Meaning |
| ------------ | ----------------------------------------------------------------- |
| **Healthy** | Computed tasks are running normally. |
| **Degraded** | Teable found failures, timed-out tasks, or a growing backlog. |
| **Critical** | BullMQ is unavailable or no worker is available to process tasks. |
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:
| Anomaly type | Action | What happens |
| --------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Dead letter** | **Recover entire group** | Restores every dead letter currently in that group to the durable queue and redelivers them. Every other group stays untouched. |
| **Dead letter** | **Discard group** | Permanently deletes the dead letters in that group. They cannot be recovered or replayed afterwards, so use it only when a replay is pointless. |
| **Timed out** | **Re-arm latest timeout** | Wakes the queue for the newest task in the group so a worker can take it over. |
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.
Click **Pause a space**.
Search by space ID or name, then select it from the results.
Set **Pause duration** to 15, 30, 60, or 120 minutes.
Note the incident or maintenance window in **Reason**.
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.
| Control | What it limits |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Per-process concurrency** | How many computed tasks each worker process handles at once. |
| **Per-base claim caps** | How many computed tasks run at the same time for one Base (**Per base**) and for one source table within it (**Per seed table**). Both default to 2 and accept values from 1 to 16. |
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](/en/basic/admin-panel/database-tenant) keep the environment defaults for the claim caps, because their connection pools are sized for those values.