> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Operate an installation

> Check health, inspect logs, review changes, and roll back an Akua installation

An installation keeps running after the first deploy. This page is for operators who need to answer four questions quickly: what is running, is it healthy, what changed, and how do we safely change it again?

Use the dashboard for the common path, or use the API when you need automation. The same underlying installation model powers both.

## Start with status

The installation status is the fastest way to tell whether the cluster matches the installation repository.

Check:

* **State**: whether the installation is `pending`, `rendering`, `syncing`, `healthy`, `degraded`, `failed`, or `deleted`.
* **Health**: whether rendered resources are healthy or still settling.
* **Sync**: whether the cluster is converged to the latest accepted repository revision.
* **Revision**: the commit SHA the cluster is currently running.
* **Reconciling**: whether Akua is actively rendering or applying a change.

For the full state model, see [Installation lifecycle](/installs/lifecycle).

## Inspect pods and logs

When status says an installation is degraded, inspect the live workload:

* Use **Pods** to see the current pods and containers for the installation.
* Use **Logs** to stream output from all pods, or narrow the stream to one pod when the failing workload is obvious.

Logs come from the running installation. They can include whatever your application writes to stdout or stderr, so avoid logging secrets or customer data.

## Review what changed

Every installation has a private git-backed repository. That repository stores the selected Package version, inputs, vendored source, and rendered manifests that explain what the cluster is trying to run.

Use the repository history when you need to compare two rollouts, audit a customer-specific change, or understand why a render produced different manifests. See [Installation repositories](/installs/repositories) and [Package versioning](/installs/versioning).

## Make changes safely

Sensitive changes should go through a [repository change request](/installs/repository-change-requests). A change request prepares edits in a managed fork, validates them, and applies them only after an authorized reviewer accepts the proposal.

Use change requests for:

* Agent-authored fixes.
* Partner or CI-authored updates.
* Customer-specific patches that need approval before rollout.
* Automated version or image updates that should be reviewed first.

After a change request is accepted, Akua applies the change, records the new repository revision, and the installation moves through the normal render and sync lifecycle.

## Roll back

Rollback is git-history-backed: restore the installation to a previous known-good repository state, then let Akua render and sync that state to the cluster.

For reviewed environments, prepare the rollback as a repository change request so the revert is validated and approved before it reaches the installation. The resulting commit stays in history, so the original change and the rollback are both auditable.

## API

Operate installations programmatically.

<CardGroup cols={2}>
  <Card title="Install status" icon="heart-pulse" href="/api-reference/installs/get-install-status">
    Read health, sync, revision, and resource state.
  </Card>

  <Card title="Stream logs" icon="terminal" href="/api-reference/installs/stream-install-logs">
    Follow live logs for an installation or pod.
  </Card>

  <Card title="Repository change requests" icon="code-branch" href="/api-reference/repository-change-requests/list-repository-change-requests">
    Propose, review, accept, reject, and withdraw changes.
  </Card>

  <Card title="Installation renders" icon="arrows-rotate" href="/api-reference/installs/list-install-renders">
    Inspect render attempts and artifacts.
  </Card>
</CardGroup>

## Related topics

<CardGroup cols={2}>
  <Card title="Installation lifecycle" icon="heart-pulse" href="/installs/lifecycle">
    Lifecycle states, renders, pods, and logs.
  </Card>

  <Card title="Repository change requests" icon="code-branch" href="/installs/repository-change-requests">
    Review proposed changes before they apply.
  </Card>

  <Card title="Package versioning" icon="clock-rotate-left" href="/installs/versioning">
    Compare revisions and understand rollback history.
  </Card>

  <Card title="Installation repositories" icon="folder-tree" href="/installs/repositories">
    The git-backed source of truth for each install.
  </Card>
</CardGroup>