# Monitoring and health

> Live health for every deployment and cluster. No third-party tools to wire up.

Every deployment and cluster in Ownkube has a **live health read-out**. No extra tools, no config, no scraping to set up.

Open any deployment from your [dashboard](https://app.ownkube.io/dashboard) and watch the Overview tab update in real time.

## What you see on a deployment

On the **Overview** tab of a deployment:

- **Health status**: `healthy`, `syncing`, `degraded`, or `paused`
- **Sync status**: whether the live workload matches your saved configuration
- **Replica count**: running vs. desired (e.g. `3 / 3`)
- **Current image and tag**: the exact version of your code that's live right now
- **Public hostname**: the allocated URL (for public web deployments)
- **App platform version** with an **Upgrade** control if a newer version is available

Status updates stream into the dashboard as rollouts happen. You don't refresh. The page does.

## What you see on a cluster

Open a cluster from your [dashboard](https://app.ownkube.io/dashboard) to see a live telemetry strip:

- **Region and Kubernetes version**
- **Node count, vCPU, and memory allocation**
- **Active deployment count**
- **Cluster platform version and creation time**

The cluster detail page also shows an at-a-glance list of every deployment on the cluster with its health status.

## Live status during a rollout

Kicking off a deploy shows a progression like this in real time:

<div class="ok-diagram">
  <img class="ok-diagram-light" src="/docs/diagrams/deployment-status-light.svg" alt="A deployment's health progresses from syncing to pulling the image, starting the container, and running a health check, which lands on healthy or degraded, with degraded able to recover back to healthy." />
  <img class="ok-diagram-dark" src="/docs/diagrams/deployment-status-dark.svg" alt="A deployment's health progresses from syncing to pulling the image, starting the container, and running a health check, which lands on healthy or degraded, with degraded able to recover back to healthy." />
</div>

If a health probe fails, the status surfaces the failure immediately. No log-diving to find it.

## Status meaning, at a glance

| Status | What it means |
|---|---|
| **Healthy** | All replicas passing health checks, live config matches saved config |
| **Syncing** | A change is rolling out; new replicas starting, old ones draining |
| **Degraded** | At least one replica is failing health checks or crash-looping |
| **Paused** | Deployment is set to 0 replicas; no containers running |
| **Deleting** | Deployment is being removed from the cluster |

## What's coming

The next round of monitoring is owned by two of the agents: the **Incident agent** turns logs and signals into plain-English explanations, and the **Cost agent** keeps a running watch on the bill.

### Incident agent: application logs

Searchable, filterable container logs directly in the dashboard, with the Incident agent surfacing the relevant lines when a deployment goes degraded.

### Metrics dashboards

CPU, memory, request rate, and latency trend lines per deployment.

### Incident agent: alerting

Plain-English alerts on deployment failures, resource thresholds, or health flaps. Example: "payment-worker OOMKilled at 14:32. Tried to load a 2GB dataset into 512MB RAM. Suggested limit: 3GB."

### Cost agent: anomaly detection

Surface unexpected spend jumps before they become monthly surprises. Example: "EKS data-transfer-out 4x higher than 7-day baseline. Investigate before month-end."

## Limits and constraints

- **Metrics** are roadmap items. Live health and sync are the in-product signals today.
- **Log retention** is configurable from 1 to 3650 days.

- [Autoscaling](/docs/features/autoscaling)
- [Deployments](/docs/features/deployments)

---

**Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.