Application logs (roadmap)
Searchable, filterable container logs directly in the dashboard, with the relevant lines surfaced automatically when a deployment goes degraded.
Monitoring and health
Every deployment on 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 (own cloud)
Section titled “What you see on a cluster (own cloud)”On the Advanced own-cloud path, where you run in your own AWS account, each cluster has its own telemetry. On Ownkube-hosted compute there’s no cluster to watch: the deployment health above is the whole picture. 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 |
What’s coming
Section titled “What’s coming”The next round of monitoring covers application logs, metrics dashboards, and alerting. These are on the roadmap:
Metrics dashboards (roadmap)
CPU, memory, request rate, and latency trend lines per deployment.
Alerting (roadmap)
Plain-English alerts on deployment failures, resource thresholds, or health flaps, so you don’t have to dig through logs to understand what happened.
Cost anomaly detection (roadmap)
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”- Logs, metrics, and alerting 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.