Tasks and notifications | SoAI Documentation

The bell at the right of the SoAI WebUI header opens one dropdown that holds two panels. Tasks shows work that is running now, and the notifications panel holds the notices SoAI has saved for your account. Anything that keeps going after you leave the page that started it, a model download, a backend installation, an automation run, a backup, is visible in one of the two.

Watch active work in Tasks

Select the bell, then select the Tasks heading to expand or collapse the list. This browser remembers that choice, while the Notifications list underneath it starts expanded every time, and Esc collapses the task list again.

Each row stands for one plugin or one source of tracked work, and the heading counts the rows, as in Tasks: 3. A row carries a status indicator, the plugin name, and one line per operation with its label (Model download, Backend install, RAG folder scan, and so on), a short detail line, and a progress bar. A plugin that is loaded and ready has a row even when nothing is downloading, because the panel follows active plugins as well as operations.

Expanding the panel asks the server for the current active-task snapshot and reconciles the list against it, so work started in another session appears and anything that ended in the meantime drops out. That snapshot returns at most the smaller of SYSTEM.TASKS.ACTIVE_TASKS_LIMIT and SYSTEM.TASKS.TASK_LIST_MAX_LIMIT, both 1,000 by default. A task that reaches a terminal state leaves the panel, so when you need its completed record or its output, return to the page that started the work.

You see your own tasks, and an Administrator also sees system-owned ones. Live task events need Task management (TASK_MANAGEMENT), which a Standard account holds by default; without it the rows only change when a reconcile runs.

Stop or cancel active work

A row for a plugin that can be stopped shows Stop with that plugin's name, and selecting it stops the plugin without asking again. A row that exists only because a cancelable task is running shows Cancel running task instead. A persistent plugin has no control in this panel, and a few operation types never offer cancellation, so model deletion, software updates, and backup creation, restore, and verification run to their end.

A SoAI Bench run appears as a SoAI Bench row that only administrators see, and an administrator can cancel any running benchmark from this panel.

Stop all activity sits at the right of the Tasks heading and appears only when there is something to stop or cancel. Selecting it collapses the list and asks for confirmation, naming how many plugins it will stop and how many tasks it will cancel, and the confirmation is one dialog for both. SoAI then sends a stop request for every non-persistent active plugin and a cancellation request for every cancelable operation, and it reports what was requested, what had already finished, and what failed.

Cancellation is a request rather than an immediate stop, because SoAI records it and the operation ends when its worker observes it, so watch the row or the originating page until a terminal result arrives. A task that is already terminal answers with 400 and is simply removed from the panel. Cancelling a task you can see needs nothing beyond a signed-in session, while the cancellation-registry, sweep, reset, and cancel-all administration endpoints require Request cancellation (REQUEST_CANCELLATION_ADMIN).

Read and clear notifications

The bell badge adds unread notifications to the long-running operations SoAI tracks for you (backend installations and updates, model and plugin downloads, plugin uploads and clones, RAG document uploads, URL fetches and folder scans, SoAI Bench runs, software updates, backup creation and restore, and file uploads), and its tooltip names each part separately. The notification heading shows the total the list holds, read ones included.

A notification row has its title, a relative time, the message clipped to a few lines, and Delete. Expand appears only when the message is actually clipped. Selecting a row that carries a destination follows it, which can be a chat conversation, an automation run, an internal WebUI page, or an external address, and an external one goes through a confirmation dialog first.

Opening the panel while the list is expanded marks the loaded unread notifications as read, apart from the notices described below. Scrolling to the bottom of the list loads 100 older notifications at a time. Clear all appears whenever the list has content and asks you to confirm, since it cannot be undone, while Delete removes a single row straight away. Both act only on your own notifications.

Reading any of this requires Notifications (NOTIFICATIONS), another Standard default, and plugin circuit breaker notices are filtered out unless the account also has Plugin read access (PLUGIN_READ). When the notification stream cannot be reached, the panel says that notifications are unavailable and keeps reconnecting.

Notices that ask for an answer

A tool approval, an agent question, and a secret request each raise a notification that stays unread until you deal with it, and it also raises a toast with an Open button unless you are already viewing that conversation. Opening it marks the notification read and takes you to the conversation at the pending request, where you answer in the panel above the composer. Agent mode, tool approvals, and checkpoints describes the three request kinds and what happens when one is refused or expires.

What raises a notification

Automation runs post a notice when they finish or fail, pointing at the run's conversation when it has one and at the run otherwise. Plugin circuit breaker trips, failed backups, low disk space, applied API rate limits, an exhausted OpenAI quota, and throttled sign-in attempts each raise one, and connected mail and calendar accounts add sync failures and reminders. Every new notification also raises a toast in the corner of the WebUI.

Administrator settings and API access

An Administrator with Configuration changes (CONFIG_PATCH) selects the Settings button at the right of the header, chooses Settings, turns on Advanced in the page header, and then uses Search settings... to reach a path, or opens System for the task limits and Server for the notification settings. Select Save in the page header afterwards.

SYSTEM.TASKS.TASK_LIST_MAX_LIMIT and SYSTEM.TASKS.TASK_LIST_MAX_OFFSET bound what a task query may ask for, and a request above either one is rejected. SERVER.WEBUI.NOTIFICATIONS.EMIT_ON_AUTOMATION_COMPLETE is on by default and controls the automation notices for both success and failure. SERVER.WEBUI.NOTIFICATIONS.MAX_PER_USER keeps 1,000 notifications per account, and when a new one crosses that line SoAI deletes the oldest read notifications first and only then the oldest remaining ones, so an account that never opens the panel still loses its oldest notices.

A client can do the same work over the API, where GET /api/v1/tasks/active lists what the panel lists, POST /api/v1/tasks/{task_id}/cancel answers 202 with the recorded cancellation, and the notification routes under /api/v1/webui/notifications list, open, delete, and clear. HTTP API reference carries the full route inventory with its methods and permissions.