#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.