Activity

Activity is one page for everything the account has going: deployments, backups, restores, task runs, key installations, hardening runs, servers being built or powered on and off, and runners being prepared. Anything long-running and remote shows up here while it is happening, and the last few finished runs stay listed so a quiet page still shows something happened.

Workers

The page also shows whether anything is picking up work. Without a live worker every row sits at queued forever, so Activity warns when no worker is running. Admins also see each queue process and counts of what is executing, ready, scheduled and failed.

Statuses

Every long-running record in KamalCloud shares the same five:

queued	created, waiting for a worker
running	a worker has it
succeeded	finished, cleanly
failed	finished, badly – with the error recorded
cancelled	somebody stopped it

queued and running are active; the other three are finished.

Stopping something

Admins can stop deployments, task runs, key installations and hardening runs from here. Building a server and changing its power are the provider’s work, so they cannot be stopped.

Stopping is marking. The worker is inside a Kamal command or an SSH session and cannot be interrupted from a web request, so it finds itself cancelled when the command returns. For deployments the underlying Kamal process is killed too, which is why stopping a deploy usually takes effect quickly rather than at the end.

Things that go quiet

A worker that is restarted mid-run, a runner that reboots, a dropped SSH session – any of these can leave a row saying “running” with nothing behind it.

KamalCloud handles this with heartbeats rather than timestamps: a run writes output roughly once a second, and a run that has been silent past its limit has lost its process. Reaper jobs settle those rows as failed – not cancelled, because nobody stopped it. They kill anything that may still be alive, since a silent run could still be holding Kamal’s lock.

Failed jobs

Background jobs that failed outright – as opposed to a deployment that ran and failed – are listed at the bottom of Activity. An admin can retry one or discard it. Only jobs that belong to this account are listed.

This is the place to look when something did not happen at all: a backup that never started, a notification that never arrived. See also Troubleshooting.

Live output

Only an environment’s Logs and Shell stream over a live channel. Deployment, backup and task pages reload when the environment’s updates channel says something changed. The Activity page refreshes itself on a timer, and hardening output is not streamed: the server’s Security page reloads until the run finishes.

Output is batched into the record’s log column, so leaving the page and coming back gives you the whole run rather than the tail.

ANSI colour is stripped and clone tokens are redacted before anything is written down.