Running jobs, GPU VRAM usage, Celery worker health, model load, recent activity, and system alerts — all on one screen. The first thing you see when you open Guaardvark.
Every active Celery task — image generation, video rendering, document indexing, bulk generation, upscaling — appears in the job panel with a live progress bar, elapsed time, and estimated completion. Progress is pushed over Socket.IO via useJobSocket so the dashboard updates without polling. Click any job to see its full details in the job modal.
The GPU panel reads from gpu_api.py and hardware_service.py to show VRAM used, VRAM free, current model loaded, and GPU utilisation percentage. For systems without a GPU, the panel shows CPU and RAM utilisation instead. The resource coordinator's allocation state — which model is currently holding VRAM and how much — is visible so you can plan job sequencing manually if needed.
The Celery monitor panel queries /api/health/celery and the celery_monitor_api.py endpoints to show the number of active workers, the queue depth per worker type, and the last-completed task for each worker. A red indicator on any worker signals a worker crash or queue backup. One click on a stalled worker lets you restart it from the UI.
The activity feed shows the last 20 system events in reverse chronological order: completed jobs, new document uploads, model loads, settings changes, and user-initiated tasks. Each event links to the relevant surface — a completed image job links to the Content Library, a completed index job links to the Documents surface — so the dashboard is a navigation aid as well as a status monitor.
Guaardvark runs several concurrent background processes: Celery workers, Redis, Ollama, and optionally the Discord bot. Jobs queue in Redis and run across multiple Celery worker processes. GPU VRAM is a shared resource allocated to whichever generation task is running. Without a dashboard, understanding what the platform is doing at any moment requires inspecting multiple log files and running commands against the database. The dashboard surfaces all of this state in one place without any command-line interaction.
The dashboard's data comes from multiple API sources aggregated by the DashboardPage React component. Job progress arrives over Socket.IO via useJobSocket, which subscribes to the unified_progress_system.py event stream. GPU status is polled from /api/gpu/status every five seconds, with the update rate configurable in Settings. Celery health is checked from /api/health/celery which queries the Celery inspect API. The activity feed reads from the jobs and events tables in SQLite, updated in real time as tasks complete.
Quick action buttons on the dashboard let you jump directly to the most common workflows: start a new chat, open the image generator, navigate to Documents, or trigger a system health check via ./start.sh --test. The dashboard also surfaces alerts — a pending database migration, a model that failed to load, a backup that hasn't run recently — as yellow or red banners at the top of the page. These alerts are generated by the health check endpoints and pushed to the dashboard over Socket.IO, so critical issues appear immediately without requiring you to navigate to the Settings or Logs pages.
Health endpoint stack. GET /api/health returns system health including Flask, database connectivity, Redis, and Ollama availability. GET /api/health/celery checks Celery worker availability and queue depth. GET /api/gpu/status queries PyTorch CUDA availability and VRAM statistics via backend/services/hardware_service.py and gpu_resource_coordinator.py. GET /api/system from system_api.py returns a broader snapshot including version, uptime, database size, and configuration flags. All of these are aggregated by the dashboard component on initial load, with individual panels subscribing to refresh events at appropriate intervals.
Job progress infrastructure. The unified_progress_system.py utility provides a standardised interface for Celery tasks to emit progress. Tasks call update_progress(job_id, percentage, message, extra_data), which both updates the database Job record and emits a Socket.IO event to subscribed clients. The progress_emitter.py handles the Socket.IO emission, and the progress_manager.py manages in-memory progress state between the database write and the emit. The useJobSocket React hook subscribes to these events and updates the job panel without any polling overhead. When the browser reconnects after a disconnect, the dashboard re-fetches current job states via the REST API to recover the current progress snapshot.
# Check system health from the terminal
llx health
llx status
# Watch a specific job from the terminal
llx jobs watch JOB_ID
# List all running jobs
llx jobs list
# System health endpoints
curl http://localhost:5000/api/health
curl http://localhost:5000/api/health/celery
curl http://localhost:5000/api/gpu/statusStart a batch of 200 image generations or a bulk document indexing run, then leave the machine to work. Check the dashboard periodically to see progress without interrupting the generation. When the job completes, the activity feed shows the completion event and links to the Content Library. If a job fails mid-batch, the job panel shows the failure and the error message, and a retry button re-queues the failed batch.
The GPU panel shows exactly how much VRAM is free at any moment. Before queuing a video generation job that requires 12 GB VRAM, check that the current image model has released its allocation. The resource coordinator handles this automatically, but the dashboard gives you visibility to plan manually for complex multi-step pipelines where you want specific jobs to run in a specific order.
Open the dashboard after a night of unattended batch processing. The activity feed shows everything that completed, the job panel shows any failed or stalled tasks, and the alert banners surface any system-level issues that need attention. The entire system state is legible at a glance without reading log files. Click through to specific jobs, failed tasks, or the Content Library to see the outputs from the overnight run.
Monitoring a local AI platform via tail -f logs/backend.log is functional but requires parsing raw text to understand system state. Guaardvark's Dashboard translates log-level events into structured, visual state: progress bars instead of percentage strings, colour-coded health indicators instead of OK/ERROR text, a navigable activity feed instead of a stream of log lines. The Socket.IO real-time updates mean the dashboard is always current without requiring a page refresh. For users running Guaardvark on a headless server and accessing it via a browser, the dashboard is the primary operations interface for a system they can't directly touch.
The dashboard is the default landing page at http://localhost:5173 (Vite dev server) or http://localhost:5000 (production build served by Flask). DashboardPage is the first route registered in the React router. From the terminal, llx status prints a text-based equivalent with system health, active jobs, and model information.
Basic widget reordering and show/hide is available via the dashboard settings panel. A more configurable widget system is on the roadmap. Currently the dashboard panels — job list, GPU status, Celery health, activity feed, quick actions — are a fixed set with configurable refresh intervals.
The dashboard uses Material-UI v5's responsive grid, so it adapts to smaller viewports by stacking panels vertically. Functionality is identical on mobile; the layout just shifts from a multi-column grid to a single-column stack. The job progress bars and health indicators are sized to remain legible at mobile viewport widths.
The job history is accessible from the Jobs page (/jobs), which shows all job records with their creation time, completion time, duration, status, and output file count. The dashboard's activity feed shows only the most recent 20 events; the Jobs page has full pagination and filtering. llx jobs list from the terminal lists jobs with the same filtering options.
GET /api/health/celery calls Celery's inspect().ping() and inspect().active() methods. A healthy indicator means at least one Celery worker responded to the ping and the Redis broker is reachable. A warning indicator means workers are running but the queue depth is above a configurable threshold. A failure indicator means no workers responded or the Redis connection failed. Both the indicator and a detailed message are surfaced on the dashboard.