Status, storage and audit

See what is ready, what is using capacity, and which operations need attention.

The combined Status view requires the essentials update. Storage, operations and audit pages are also available in the original management preview.

Readiness and capacity

Service admins open Status for readiness, free bytes and inodes, reservations, active Git sessions and outstanding work. Storage shows configured admission floors. Readiness can be false when writes are unsafe while read availability remains separately reported. Repository-specific barriers still apply.

Configured quotas and reservations are admission controls, not proof of a hard disk boundary. Validate the actual dedicated volume or project quota on the target host. Inspect both bytes and inodes: either can prevent writes.

Pending, running and failed work

The Status view puts actionable work first. Filter operations by state and open a result for its phase, bounded error, relevant audit and recovery instructions. HTTP 202 and replay remain pending until the durable record says completed. Failed jobs are not automatically retried, and failed purge keeps its access fence.

Resolve the underlying failure before explicit recovery. Do not remove unknown files or treat a process exit as proof that a push or export succeeded.

Low storage

Check the correct mounted volume, bytes, inodes, reservations, ownership and actual quota. Archive and recoverable deletion retain storage. They do not free capacity. Purge and Git pruning are not automatic remedies for low space.

Increase verified capacity or resolve known operational artifacts using the reviewed runbook. Preserve failed operation evidence before taking action.

Audit

Service admins can inspect global audit events. Repository admins can inspect their repository's filtered audit. Events document authorized intent and operation results; a failed job's detail page links to relevant audit. Actual ref records, rather than child exit status alone, establish push outcomes.

External checks

Use an existing host timer/cron and notification destination for health and backup alerts. The operator status guide includes CLI examples. A successful command returning JSON with ready=false needs an explicit readiness check in the script.

There is no built-in monitoring or backup scheduler. Status cannot invent a last-backup timestamp for copies managed externally.