New features, improvements, and fixes, shipped to all customers automatically.
v1.9.0Feature
Docker-Desktop-Style Volume Browsing
Every volume mount on a pod or container now has a Browse action: a breadcrumb file explorer showing names, sizes, permissions, and modified times, powered by a one-shot command run inside the container rather than a live session.
Breadcrumb navigation, sortable columns. Click into a folder to go deeper; click a column header to sort by name, size, permissions, or modified time. Browsing only in this pass, no download or edit action.
Works on Docker and Kubernetes agents. Built on the same one-shot agent command channel the autoscaler already uses, not the interactive exec pipe, so a listing resolves and returns without holding a live connection open.
Clear error for shell-less containers. Distroless and scratch-based images have no shell to run a listing command in. Browsing one of these shows a direct "no shell available in this container" message instead of an empty folder.
v1.8.0Feature
Image Details & Vulnerability Scanning
Every container and pod’s image is now a link to its own detail page: digest, size, build date, and every other container or pod across your fleet running that same image. From there, scan it for known CVEs using Trivy, Grype, or Snyk. Volume mounts are also now visible on the pod and container detail pages.
Image details, deduplicated by digest. A base image shared across dozens of containers only shows up once, with a reverse lookup showing every container and pod currently running it, useful for finding every place a stale or vulnerable image is still deployed.
Vulnerability scanning, three engines. Configure Trivy, Grype, or Snyk under Settings, then scan any image on demand. Findings are cached per digest, sorted by severity, with the affected package and fixed version.
Volume mounts on Docker and Kubernetes. Named volumes, bind mounts, emptyDir, hostPath, PVCs, ConfigMaps, and Secrets all show up on the pod and container detail pages, with source, destination, and mode.
v1.7.0Feature
Live, Region-Aware Cloud Pricing
Cloud Costs and the Nodes page now price AWS, Azure, and GCP instances from each provider’s own live pricing API for the instance’s actual region, instead of one hand-maintained global rate. A hardcoded pricing table is now only a fallback, not the default.
Region-correct by default. A London EC2 instance and a Virginia one now price differently, matching what you’d see in AWS’s own console, pulled from AWS’s Price List API and Azure’s Retail Prices API rather than a single hardcoded rate applied everywhere. GCP prices from a live regional blended rate, since its catalog has no exact per-machine-type lookup.
Agent-resolved pricing on the Nodes page. The Kubernetes Agent itself can resolve a live price for its own node across all three providers, using whatever cloud identity is already available to it (an API key for GCP). An opt-in Helm setting (livePricing.enabled, off by default) since it’s a new outbound call the agent didn’t make before.
Always falls back cleanly. No pricing credential configured, an unrecognized instance type, or a transient API error all fall back to the existing static pricing table rather than showing an error or a blank number.
v1.6.1Improvement
Agent Update Notifications
A dismissible banner now appears across the dashboard when a connected agent is running an older version than the latest release, with an "outdated" badge next to that agent on the System Health page.
Version-aware, not just a fixed count. Dismissing the banner only suppresses that specific version’s notice, a newer release surfaces the banner again rather than staying dismissed forever.
v1.6.0Feature
Custom Branding
Make the dashboard look like your own product instead of KubeWatch: your logo, your accent color, and your organization name in the sidebar, browser tab, and login page. Available to every plan, self-hosted or SaaS, and entirely optional, leave it unset and nothing changes.
Accent color. Pick a color from Settings → Branding and it replaces the indigo accent across the entire dashboard, buttons, links, active nav state, all of it, without a page reload.
Logo upload. Upload a PNG or JPEG and it replaces the KubeWatch wordmark in the sidebar and the browser tab favicon. Validated server-side by decoding the actual image, not just trusting the file extension.
Branded login page. Self-hosted deployments show their brand automatically on the login screen. SaaS organizations get a branded link (yourapp.com/login?org=your-slug) to share internally, so your team signs in against your identity, not a generic one.
v1.5.0Feature
Incident Management
A full incident lifecycle alongside Alerts: declare an incident (from scratch, or escalated directly from a firing alert), work it with your team, resolve it, and capture a postmortem. On-call scheduling routes new incidents to whoever is currently on call, and an insights view tracks MTTA, MTTR, and which alert rules generate the most incidents.
Declare, respond, resolve. A status pipeline (declared → acknowledged → mitigated → resolved), a timeline of every status change and update, and responders you add by user ID. Declaring an incident from a firing alert on the Alerts page carries its severity and links back to the originating alert automatically.
On-call scheduling & dynamic routing. Build a schedule from shifts (a user plus a start and end time). Declaring an incident automatically pages whoever’s shift covers that moment, so severity- and availability-based routing happens without anyone looking up who’s on call.
Related incidents. Every incident shows past incidents from the same alert rule, or matching severity within 90 days if there isn’t one, real SQL matching on your own incident history, not a black box.
Postmortems with tracked action items. Once resolved, write a summary (save as a draft or publish it) and track action items with an open/done status underneath, plus an insights view aggregating MTTA, MTTR, severity breakdown, and your noisiest alert rules.
Notifications via your existing channels. Incidents notify the same Slack, email, webhook, and PagerDuty channels you already configured for Alerts, one-way, reusing the exact delivery and retry logic alerts already use.
Two additions to how you connect clusters and test the endpoints running on them. The Clusters page can now discover and one-click connect to EKS, GKE, and AKS clusters using the cloud credentials you already connected for Cloud Costs, no manual kubeconfig required. The Performance page adds Stress, Soak, and Spike testing alongside the existing Load Testing, each with its own purpose-built metrics.
Auto-discover EKS, GKE & AKS clusters. Reuses your connected AWS, GCP, or Azure account (from Cloud Costs) to list every Kubernetes cluster in it. Connecting mints a fresh authentication token server-side rather than trusting anything cached from discovery, an IAM authenticator token for EKS, an OAuth2 access token for GKE, refreshed automatically well before either expires, and a static-credential kubeconfig for AKS.
AAD-integrated AKS clusters flagged for manual connect. An AKS cluster with AAD authentication and local accounts disabled needs the kubelogin exec plugin to connect, which this feature does not attempt to emulate. Those clusters show "Manual connect required" instead of a Connect button, so you know exactly which ones need a hand-built kubeconfig.
Stress, Soak, and Spike testing. The Performance page gained a Test Type dropdown. Stress ramps concurrency until the target breaks, reporting max load capacity, the breaking point, and recovery time. With Soak, load stays steady for up to an hour while the test tracks uptime % and latency drift, a leak/degradation proxy. Spike, meanwhile, bursts to roughly 8x baseline concurrency and measures how the target handles it and how long it takes to recover.
Network timing breakdown on every test. Every test type now reports average DNS lookup, TCP connect, TLS handshake, and time-to-first-byte, the client-observable stand-in for target-side resource usage that this page has no way to measure directly.
v1.3.0Feature
Auto Scaling
KubeWatch can now scale your workloads, not just watch them. Define a per-workload policy (thresholds, replica bounds, cooldowns) and the Scaling-Engine acts on the same metrics you already track. The same policy surface drives both runtimes, while what happens underneath fits each: native HorizontalPodAutoscaler and Karpenter objects on Kubernetes, full orchestration on standalone Docker.
Kubernetes: native HPA & Karpenter. For a Kubernetes policy, KubeWatch renders a standard HorizontalPodAutoscaler (and a Karpenter NodePool when node-level scaling is requested) and the in-cluster agent server-side-applies it. The cluster's own controllers execute the scale, so scaling keeps working even if KubeWatch is unreachable.
Docker: orchestrated scaling with a managed load balancer. Standalone Docker has no HPA, so KubeWatch owns the whole loop: it chooses placement by host headroom, scales containers via the Docker Engine, and (optionally) runs a managed Caddy load-balancer pool that health-checks new replicas before sending them traffic.
Dry-run, cooldowns, approvals, and a decision log. Every policy starts in dry-run: it logs exactly what it would do, with the rendered manifest or command, against live data. Asymmetric cooldowns prevent flapping, approval gates hold high-stakes actions for a human, and an append-only decision log answers "why did this scale" after the fact.
One-click rollback. Every action can be rolled back from its history entry. On Kubernetes this cleanly restores the previous scaling envelope. On Docker it restores the previous replica count, and the UI states plainly when fresh containers will be created.
v1.2.0Feature
Multi-Cluster Dashboard
Monitor all your Kubernetes clusters from a single pane of glass. This release introduces a unified multi-cluster overview, a cluster selector with per-cluster drill-down, and cross-cluster alert aggregation so you can correlate incidents that span multiple environments.
Multi-cluster overview. A new top-level dashboard shows health scores, active alert counts, node readiness, and resource saturation for all registered clusters simultaneously. Clusters are grouped by environment tag (production, staging, development).
Cluster selector. A persistent cluster selector in the top navigation bar lets you switch context instantly. The selector remembers your last-used cluster per browser session and supports keyboard shortcut navigation.
Cross-cluster alert aggregation. Alert rules can now be scoped to "all clusters" or a custom cluster group. Aggregated alerts surface in a unified incident feed with per-cluster breakdowns, so on-call engineers see the full blast radius of a cascading failure at a glance.
Cluster comparison view. Side-by-side metric comparison across up to four clusters makes it easy to verify that a deployment rolled out consistently and that resource usage is symmetric across replicated environments.
Agent v1.2 with multi-cluster identity. The KubeWatch Agent now embeds a cluster identifier in all emitted telemetry. Upgrading to Agent v1.2 is required to use multi-cluster features. Migration is zero-downtime and backward-compatible.
v1.1.0Feature
Alert Engine
A fully redesigned alert engine with threshold-based and rate-of-change rules, native Slack and email integrations, and granular silence rules. Configure once, get notified everywhere your team already works.
Threshold-based alert rules. Define alerts using a YAML-like rule editor or the visual wizard. Conditions support comparison operators (>, >=, <, <=, ==, !=) against any ingested metric. Rules evaluate on configurable windows from 1 minute to 24 hours with configurable consecutive-breach counts to reduce flapping.
Rate-of-change alerts. Alert when a metric increases or decreases by more than a specified percentage over a rolling window. Useful for detecting sudden memory leaks, traffic spikes, or an unexpected drop in request throughput.
Slack integration. Send alert notifications to any Slack channel or DM via an incoming webhook or Bot Token. Notifications include a summary card with severity badge, affected workload, current metric value, and a deep link back to the relevant dashboard panel.
Email notifications. Route alerts to one or more email addresses or distribution lists. Emails are rendered in HTML with an embedded sparkline of the metric over the past hour and a one-click acknowledge link.
Silence rules. Suppress alerts matching a label selector for a defined time window, ideal for planned maintenance. Silences can be created from the alert feed, the rule editor, or the API, and support recurring schedules (e.g., every Sunday 02:00 to 04:00 UTC).
Alert history and audit log. Every alert state transition (firing → resolved, rule created, silence applied) is recorded in an immutable audit log retained for 90 days, giving you a clear post-incident timeline.
v1.0.0Feature
Initial Release
The first public release of KubeWatch. Core support for Docker and Kubernetes monitoring, live log streaming, and a basic alerting foundation. This is the foundation on which everything else is built.
Docker monitoring. Monitor running containers on any Docker-enabled host. Track CPU usage, memory consumption, network receive/transmit rates, block I/O, container uptime, and restart counts. Containers are auto-discovered when the Agent starts and removed from the view automatically on exit.
Kubernetes monitoring. Deploy the Agent as a DaemonSet and immediately gain visibility into node resource usage, pod scheduling events, container restarts, PersistentVolume capacity, and Deployment/StatefulSet/DaemonSet replica health across all namespaces.
Live log streaming. Stream stdout and stderr from any container in real time directly in the dashboard. Supports log filtering by severity keyword or regex, line-count limiting, and pause/resume for reviewing bursts of output. Logs are also indexed and searchable for the duration of your plan's retention window.
Basic alerts. Create simple threshold alerts on CPU, memory, and restart-count metrics with email delivery. The foundation for the full alert engine shipped in v1.1.
REST API. A versioned REST API (v1) provides programmatic access to metrics, logs, and container metadata. API keys are generated per-account and scoped to read-only or read-write permissions.
KubeWatch Agent v1.0. The Agent is distributed as a Docker image and a Kubernetes Helm chart, licensed under the Software Usage Agreement. Configuration is minimal, provide your API key and the Agent auto-discovers workloads and begins streaming telemetry within seconds.
All updates are deployed automatically to hosted accounts. Self-hosted customers can pull the latest Agent and dashboard images from ghcr.io/kubewatch.