Docker-vs-Kubernetes Workload Advisor

A workload-level recommendation of whether a workload needs Kubernetes, backed by your own historical usage data.

**Available now**, on the Pro plan and above. See the **Advisor** page in your dashboard, and the "Placement" column on the Workloads page.

A single-replica API that never restarts and barely moves off 5% CPU is paying full Kubernetes tax (the control plane, the YAML, the on-call familiarity with kubectl) for a job a Docker container run by KubeWatch's own autoscaler would do identically. KubeWatch already unifies Docker and Kubernetes scaling under one policy surface. This feature turns that dual-runtime awareness into a concrete recommendation, either "this doesn't need Kubernetes" or "this does," backed by the workload's own historical usage rather than a generic rule of thumb.

What you get

A daily Placement Analysis Job that scores every workload's CPU volatility, restart/failure pattern, and actual use of Kubernetes-specific features (StatefulSets, service mesh sidecars) against its current runtime.
Structured rationale, not just a verdict, since each recommendation lists the specific factors behind it (e.g. "stateful workload", "cpu volatility: low"), so you can see why, not just what.
A rough, deliberately conservative estimated savings figure, an operational-overhead estimate, not a precise cloud-bill number.

What it doesn't do

This feature is advisory only and never migrates a workload automatically. It only evaluates workloads already inside KubeWatch, in either runtime, which means it doesn't recommend Kubernetes adoption for workloads running outside KubeWatch's management entirely.

Low-confidence results aren't shown at all, since a wrong "move this" suggestion damages trust in this feature more than a missed one would. If a workload doesn't appear on the Advisor page, it may simply not have a confident-enough recommendation yet (14 days of usage history is the default analysis window).

Dismiss a recommendation from the Advisor page if it doesn't apply. It won't reappear until the underlying workload's metrics shift meaningfully.