Kiro — Scale Smart. Never Drop a Request.

The Problem

HPA sees averages.
Kiro sees individuals.

Kubernetes HPA makes scale-down decisions without knowing which pods are actively handling requests. The result is silent and costly.

✗ WITHOUT KIRO (HPA ALONE)

28%

Aggregate CPU across 10 pods — looks fine to HPA

pod-1 … pod-10 UNKNOWN

⚠ HPA scales down — deletes 4 pods

💀 pod-3: was mid-request (30s into 45s job)

💀 pod-7: was processing a database export

❌ 2 jobs failed. On-call paged. Users affected.

✓ WITH KIRO

28%

Same aggregate CPU — but Kiro knows more

pod-3 · loadFactor: 0.91 · isBusy: true SHIELDED

pod-7 · loadFactor: 0.85 · isBusy: true SHIELDED

pod-1, pod-5, pod-8, pod-9 · isBusy: false ELIGIBLE

✅ Both jobs complete. Zero incidents. No pager.

// The safety invariant — proven, not configured

pressure ≥ busyPodCount / totalPods

desired = ceil(total × pressure)

∴ desired ≥ busyPodCount

// HPA target can never drop

// below the number of busy pods.

// Verified by unit tests. Every build.

The Guarantee

Not a heuristic.
A proof.

Mathematical invariant · verified on every build

When we designed Kiro's scale-down protection, we wanted something stronger than "it usually works." We proved it holds — no edge cases, no configuration dependencies.

Pressure floor. Kiro floors the metric at busyCount/total — HPA's desired replica count cannot mathematically drop below the number of busy pods.

Deletion guard. Non-idle pods are shielded at the Kubernetes scheduler level before any scale-down event. Only idle pods are candidates for removal.

HOLD signal. If all pods are busy, Kiro emits HOLD regardless of load — no down-scaling, no exceptions.

Features

Everything you need.
Nothing you don't.

🎯

Pod-Level Busy Awareness

Scrapes every pod individually every 15 seconds for loadFactor and isBusy. Knows exactly which pods are handling active work — not just the cluster average.

🛡️

Mathematically Safe Scale-Down

The pressure metric is floored at busyCount/total. HPA's desired replica count can never drop below the number of actively busy pods. Proven invariant.

🔄

Anti-Churn Guard

Tracks UP↔DOWN direction alternations in a sliding window. When it detects 3+ oscillations in 5 minutes, it emits HOLD — preventing thrashing, cold-start latency, and surprise billing spikes.

🔌

Multi-Protocol Scraping

Supports HTTP JSON endpoints, Prometheus text format, and JMX/RMI — whatever your application already exposes. No sidecar, no agent, no SDK required.

📦

Zero External Dependencies

Embedded DuckDB — no Redis, no Kafka, no Postgres. Runs as a single pod. Ships anywhere EKS, OpenShift, or vanilla Kubernetes runs. Install in one Helm command.

📊

Live Dashboard

Built-in web UI at port :8090. See pod states, scaling pressure, anti-churn events, and reconcile loop activity — no separate monitoring stack needed.

How It Works

Four steps.
One guarantee.

Scrape Each Pod

Every 15 seconds Kiro hits every pod's metrics endpoint concurrently using Java 21 virtual threads.

every 15s · timeout 5s · 3 retries

Evaluate Busy State

Each pod's isBusy and loadFactor are stored. Stale pods (scrape failed) are assumed busy — safe side.

eval window: 120s default

Shield Non-Idle Pods

Before HPA acts, Kiro applies deletion protection to every non-idle pod at the Kubernetes scheduler level.

applied before every HPA cycle

Publish Pressure Metric

Kiro serves kiro_scaling_pressure via the Custom Metrics API — floored at busyCount/total.

custom.metrics.k8s.io/v1beta2

Comparison

Kiro vs the alternatives

KEDA, VPA, and standard HPA address different problems. Kiro is a safety layer, not a replacement — and complements all of them.

Capability	Kiro	HPA (CPU/mem)	KEDA	VPA
Pod-level busy awareness	✅ Per-pod scrape	❌ Aggregate only	❌ Aggregate only	N/A
Busy-pod delete guard	✅ Math-proven	❌	❌	N/A
Anti-churn protection	✅ HOLD signal	❌	❌	❌
Custom metric protocols	HTTP · JMX · Prometheus	— CPU/mem only	50+ trigger types	— CPU/mem only
Zero infra dependencies	✅ Embedded DuckDB	✅	❌ Redis etc.	✅
Built-in live dashboard	✅ Port 8090	❌	❌	❌
Math-proven invariants	✅ Unit-tested every build	❌	❌	❌
Drop-in HPA integration	✅ Standard Custom Metrics API	✅ Native	✅	Separate

Integration

Two fields.
Complete protection.

Add one endpoint to your service. Kiro handles everything else.

MetricsController.java

            @GetMapping("/metrics")

            public Map<String, Object> metrics() {

              return Map.of(

                "loadFactor", queue.load(),

                "isBusy",    active.get() > 0

              );

            }

Terminal

            # 1. Install Kiro

            helm install kiro \

              oci://ghcr.io/kiro-io/charts/kiro \

              --namespace kiro-system \

              --create-namespace

            # 2. Apply a KiroScaler CR

            kubectl apply -f kiro-scaler.yaml

            # 3. Wire HPA to kiro_scaling_pressure

            kubectl apply -f hpa.yaml

Add one endpoint

Expose GET /metrics returning {"loadFactor": 0.82, "isBusy": true}. Works with any language — Java, Python, Go, Node. Also supports Prometheus text format and JMX/RMI.

Install Kiro via Helm

Single Helm chart. One pod. No external services. Ships to EKS, OpenShift 4.10+, and vanilla Kubernetes 1.22+.

Create a KiroScaler CR

Apply a KiroScaler resource pointing at your deployment with your upscaleLoadThreshold and downscaleLoadThreshold.

Wire your HPA

Point your existing HPA at kiro_scaling_pressure via the standard custom.metrics.k8s.io/v1beta2 API. No changes to HPA's min/max settings.

⏱ Most teams integrate in under 30 minutes. Kiro adds no runtime overhead to your pods — it polls from the outside.

Pricing

Pay for what you protect.
Not what you run.

Per-KiroScaler licensing — priced per protected deployment, not per node. A 500-node cluster with 3 critical services pays for 3 scalers.

Monthly

Annual Save 17%

STARTER

$ 299 /mo

billed annually · $359/mo month-to-month

~$60/scaler/month · up to 5 deployments

For small teams protecting their first critical services.

✓Up to 5 managed deployments

✓1 Kubernetes cluster

✓HTTP / JMX / Prometheus scrape

✓Built-in live dashboard

✓Community Slack support

–Multi-cluster

–Air-gapped license

See Kiro in
your environment.

We'll walk through a live demo tailored to your cluster setup, show you the dashboard, and answer every question your team has before you commit a single line of code.

✅ 30-minute walkthrough — we bring the cluster

✅ Live scale-down safety demonstration with busy pod

✅ EKS and OpenShift setup covered if relevant

✅ No sales pressure — just the product

✅ Response within 1 business day

Book a Demo

✅

Request received!

We'll be in touch within 1 business day to schedule your demo. Check your inbox for a confirmation.

Full Name *

Company *

Work Email *

Your Role

Cluster Size

Kubernetes Platform

What problem are you trying to solve?

We respect your privacy. No spam, ever. Unsubscribe any time.

Scale smart.Never drop a request.

HPA sees averages.Kiro sees individuals.

Not a heuristic.A proof.

Everything you need.Nothing you don't.

Pod-Level Busy Awareness

Mathematically Safe Scale-Down

Anti-Churn Guard

Multi-Protocol Scraping

Zero External Dependencies

Live Dashboard

Four steps.One guarantee.

Scrape Each Pod

Evaluate Busy State

Shield Non-Idle Pods

Publish Pressure Metric

Kiro vs the alternatives

Two fields.Complete protection.

Add one endpoint

Install Kiro via Helm

Create a KiroScaler CR

Wire your HPA

Pay for what you protect.Not what you run.

See Kiro inyour environment.

Book a Demo

Request received!

Book a Demo

Request received!

Scale smart.
Never drop a request.

HPA sees averages.
Kiro sees individuals.

Not a heuristic.
A proof.

Everything you need.
Nothing you don't.

Four steps.
One guarantee.

Two fields.
Complete protection.

Pay for what you protect.
Not what you run.

See Kiro in
your environment.