Monitoring: Log & Task¶
Admin-only panel (Administration → Log & Task, /admin) exposing a durable MongoDB ledger of background activity: Celery tasks, ingestion runs, application logs, and worker health.
Availability
Admin-only. Shown in single- and multi-user mode, hidden in public/demo; non-admins get Forbidden.
Each pane polls every 8 s; toggle Auto to pause. With live updates on, a green Live badge appears and the active pane refreshes on each event. The Tasks, Ingestion and Logs panes each have a free-text search box next to their filters.
Tasks¶
Celery task history (figures, screenshots, MultiQC, advanced viz, Delta tables) with a status badge, duration, and timestamp. Filter by status, kind, or text. Expand a row for the task id, worker, and labelled Arguments, Result, Error / Traceback and Logs blocks.


Ingestion¶
Ingestion runs, newest first: status, a CLI or UI source badge, instance label or hostname, project, and user. Uploads made through the web UI are recorded alongside CLI runs; recording is best-effort and never blocks an upload.
Expand a run for its provenance field grid: run id, host, CLI version, the resolved project id, the invoking command line, the CLI and project config paths, and the data root. Long paths are shortened to head/…/tail, with the full value in a tooltip and click-to-copy. Below it are two tables:
- Steps: every phase the run went through (provisioning, template resolve, server and S3 checks, config validation, project sync, scan, process, joins, dashboard import), each with
success/failed/skippedand a detail line such as 3 data collection(s) processed. The summary line tallies ok / failed / skipped and the wall-clock duration. - Data collections: one row per data collection: tag, type, format, scan mode (
recursive/single), the regex or filename it matched on, the local directories scanned, and the file count when known. These local scan paths are not shown anywhere else in the UI.


Logs¶
Recent application logs from a capped collection, tagged by level and source (api / celery). Filter by level, source, or text; expand a row for the logger, the source file:line, and the full message.
Runtime capture floor
The capture floor selector sets what the server persists, live. Drop it to DEBUG while debugging, then raise it back. It differs from the Level filter, which only narrows rows already captured. The change is broadcast to Celery workers and is not persisted: a restart falls back to DEPICTIO_MONITORING_APP_LOG_MIN_LEVEL.

Health¶
Celery worker and broker health: status, worker count, active tasks, live-updates state, and worker hostnames.

Configuration¶
| Variable | Default | Purpose |
|---|---|---|
DEPICTIO_MONITORING_ENABLED |
true |
Master switch. |
DEPICTIO_MONITORING_RETENTION_DAYS |
14 |
TTL for task events. |
DEPICTIO_MONITORING_APP_LOG_MIN_LEVEL |
WARNING |
Default log capture floor. |
DEPICTIO_MONITORING_APP_LOG_CAPPED_MB |
64 |
Log collection size cap. |
DEPICTIO_MONITORING_LIVE_UPDATES |
true |
Enables live WebSocket push. |
Live push
Requires DEPICTIO_EVENTS_ENABLED=true. Without it the panel still works over polling.
CLI ingestion identity¶
Set instance_label in the CLI YAML; each request then sends X-Depictio-CLI-Instance and X-Depictio-CLI-Host, and depictio-cli run records an ingestion run automatically, so multiple CLIs against one server stay distinguishable. Recording is best-effort and never blocks ingestion.
What leaves the machine
Sensitive option values such as --provisioning-key are redacted to *** before the run is reported, but the rest of the invocation and the local paths listed above (CLI and project config, data root, scanned directories) are visible to server admins whenever monitoring is enabled.
Post-deployment check (v1.3.0+)¶
scripts/check_deployment.py walks every dashboard and every tab the API
returns and replays, per component, the exact data fetch the viewer issues for
that component type. It reports which components fail and attributes each
failure to a root cause. No browser involved.
uv run python scripts/check_deployment.py --host demo.example.org
uv run python scripts/check_deployment.py --host localhost:5080 --scheme http
With no token it sends no Authorization header, which on a public-mode
instance is what an ordinary visitor gets, so the run reproduces what a visitor
sees. Pass --token-file with an admin bearer token to cover private dashboards
too.
| Option | Default | Description |
|---|---|---|
--host |
required | Viewer or API host, with or without scheme. |
--scheme |
https |
https or http. |
--token-file |
- | File holding an admin bearer token, one line. |
--only |
- | Restrict to these dashboard ids. |
--concurrency |
4 |
Parallel in-flight requests. |
--timeout |
60 |
Per-request timeout, seconds. |
--json / --markdown |
- | Write the per-component report to a file. |
--strict |
false |
Exit 1 when any component fails. |
--dry-run |
false |
List dashboards and exit. |
--insecure |
false |
Skip TLS verification. |
The exit code is 0 unless the deployment is unreachable or preflight fails. Add
--strict to fail CI on any broken component.
Finding the admin token on Kubernetes
It lives in the backend pod under /app/depictio/.depictio/, at
user.token.access_token. The file is named after the admin account
(<username>_config.yaml), not admin_config.yaml, so glob for
*_config.yaml rather than assuming a fixed name.