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.
Monitoring and health
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 and watch the Overview tab update in real time.
What you see on a deployment
Section titled “What you see on a deployment”On the Overview tab of a deployment:
- Health status:
healthy,syncing,degraded, orpaused - 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
Section titled “What you see on a cluster”Open a cluster from your 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
Section titled “Live status during a rollout”Kicking off a deploy shows a progression like this in real time:
If a health probe fails, the status surfaces the failure immediately. No log-diving to find it.
Status meaning, at a glance
Section titled “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
Section titled “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.
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
Section titled “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 How the platform reacts to live CPU / memory usage.
Deployments The resource types and the fields that influence health checks.