#Activity Monitoring — Tasks and Journal

Most databases run your queries and imports in the dark. You fire off a large load, the cursor spins, and you wait — with no idea whether it’s making progress, where it’s running, or why it failed.

WWKG Studio gives every workspace two live, side-by-side panels in the sidebar: a Tasks panel showing what’s happening now, and a Journal panel showing what has happened. Both are scoped to the workspace you’re working in, and both update live as operations run.

#The Tasks panel — what’s happening now

The Tasks panel lists the workspace’s in-flight work — queries, imports, commits, branch operations — and keeps each one visible for a short while after it finishes, so quick operations don’t flash past before you see them.

For each task you get:

• Live progress — a progress bar and phase for running work, plus a memory footprint for the heavy operations.
• Cancel — stop a running task you started, right from the row.
• Active vs. recently finished — live work sits up top; just- finished work collapses into a dimmed tail you can hide.
• Failures stand out — a failed task stays at full strength with a red accent and sorts ahead of the successes, so an error never quietly scrolls away.

Sort and kind chips let you focus the list, and the top-bar Tasks icon carries a count badge — red when there are recent failures to look at — so you know there’s something worth opening even when the panel is closed.

#The Journal panel — what has happened

The Journal panel is the workspace’s history: one card per task, in order, with its outcome, timing, and the events it went through. Expand a card to see the per-event detail. Status and kind chips filter the view; failed cards are tinted red so problems are easy to spot in the record.

The journal travels with the workspace — it’s encrypted with your workspace key and replicated like any other workspace data — so the history is available wherever the workspace is, and confidential at rest.

#Provenance — who, where, and across nodes

Both panels show the full execution path of a task: who initiated it, the node it entered through, and the node it actually ran on. When work is delegated to another node — for example a SERVICE query or a remote data fetch handed to a worker — the task is labelled with that node’s role (host, worker, custodian) and nests under the operation that spawned it, so a distributed operation reads as a single tree rather than scattered rows.

Operations that act on the workspace itself but can’t be recorded inside it — deleting a workspace, say — are surfaced too, marked so you can tell host-level work apart from your data operations.

#Why it’s built in

Because activity is first-class in WWKG — every operation is a tracked task and every state change is a journal entry — you get this observability without wiring up a separate metrics stack, log aggregator, or tracing backend. It’s the same record the system itself uses to manage and recover work, surfaced for you in Studio.

Domain events build on this operational record. Tasks and the Journal show the work as it runs; workspace events record what that work changed as queryable graph facts, with links to commits, tasks, actors, and causes. See Events with Provenance for that domain-level event model.