Before we meet KEDA, we need to see the problem it solves. This chapter shows where the standard approach to autoscaling works well, and where it quietly fails.

What autoscaling means

Autoscaling means that a system adds or removes capacity automatically as demand changes. In Kubernetes, the unit of capacity is usually a Pod. A Pod is the smallest runnable piece in Kubernetes, and it holds one or more containers. If demand goes up, we want more Pods. If demand goes down, we want fewer Pods, so we are not paying for machines that do nothing.

The classic signal: CPU and memory

The standard Kubernetes autoscaler looks at how busy each Pod is. If the average CPU use across Pods is high, it adds Pods. If it is low, it removes some. This works nicely for web servers that do real work for every request, because more requests mean more CPU use.

Where the classic signal breaks

• Queue workers. A worker takes a message, calls a slow outside service, and waits. While it waits it uses almost no CPU. Ten thousand messages can be waiting in the queue while CPU shows a calm 5 percent, so no new workers start.
• Stream processors. A program that reads from a stream such as Apache Kafka falls behind when data arrives faster than it can process. The measure that matters is lag, the number of unread messages, which CPU cannot show.
• Scheduled work. Some applications are needed only at known times, such as a trading dashboard from 9 a.m. to 5 p.m. CPU only reacts after the rush has already started.
• Rare events. A function that runs when a file is uploaded may be needed ten times a day. Keeping one Pod running all day just to wait is waste. Plain CPU-based scaling cannot go below one Pod.
• Delayed reaction. CPU rises only after a flood of work has arrived, so the system always starts scaling late.

KEDA does not replace Kubernetes autoscaling. It builds on it. To understand KEDA you must first understand the parts it connects to.

The three built-in autoscalers

How the HPA decides

The Horizontal Pod Autoscaler, or HPA, is a control loop that runs inside Kubernetes. By default it wakes up about every 15 seconds. Each time, it asks a metrics source for a number, compares it with a target, and calculates how many Pods it wants. The idea behind the calculation is simple: if you have 4 Pods and each is at double the target load, you need about 8 Pods. If each is at half the target, you need about 2.

Where the HPA gets its numbers

The HPA can read three kinds of metrics. Resource metrics are CPU and memory, served by a component called the metrics server. Custom metrics describe objects inside the cluster, such as requests per second on a Pod. External metrics come from systems outside the cluster, such as the length of a cloud queue. Kubernetes defines an official programming interface for external metrics, so any program can register itself to answer questions about them.

What the HPA cannot do alone

• It needs a program that actually fetches metrics from queues, streams and databases, and translates them into the official interface. Writing such an adapter for every system is a lot of work.
• It cannot scale a workload to zero by default. Its minimum is one Pod.
• It cannot create short-lived jobs in response to individual events.

KEDA is named after events, so it helps to know what an event-driven system looks like and which signals it produces.

What an event-driven system is

In an event-driven system, parts of the application talk to each other by sending small messages called events, instead of calling each other directly and waiting for answers. A shop website, for instance, does not charge the card, reserve stock, send email and update analytics in one long call. It drops an “order placed” event into a queue, and separate workers pick it up and do their own part. This design makes systems more flexible and more resilient, because a slow worker does not hold up the website.

Queues and streams

A queue is a line of messages. Producers add messages at the back, and consumers take them from the front. Each message is usually handled by one consumer and then removed. Examples include Amazon SQS, RabbitMQ and Azure Service Bus. A stream or log is a long record of events that consumers read at their own pace, each keeping track of its position. Apache Kafka is the best-known example. The gap between the newest event and the position a consumer has reached is called lag.

Signals that event-driven systems produce

Now we can describe KEDA properly: what it does, who made it, and how it fits with the tools you already use.

A short history

KEDA was started in 2019 as a joint project between Microsoft and Red Hat. Microsoft had been building Azure Functions, a service that runs small pieces of code in response to events, and wanted the same event-driven scaling to work on any Kubernetes cluster. The project was accepted into the Cloud Native Computing Foundation (CNCF) as a sandbox project in 2020, moved up to incubating in 2021, and reached the highest level, graduated, in 2023. Graduation means the project has proven maturity, broad adoption and healthy governance.

What KEDA does in one sentence

KEDA is a lightweight add-on for a Kubernetes cluster that watches external event sources and adjusts the number of Pods of your workloads, from zero up to as many as you allow, based on what it sees.

What KEDA is not

• It is not a message queue. It reads from queues you already have.
• It is not a replacement for the HPA. It feeds and controls the HPA.
• It is not a node autoscaler. It adds Pods, and other tools add the machines they run on.
• It does not require you to rewrite your application. The application keeps doing its normal job, and KEDA decides how many copies run.

Why teams choose it

KEDA is made of a few small programs. Each has one clear job, and together they bridge the world of events and the world of Pods.

The big picture

When you install KEDA, it creates a namespace, usually called keda, and starts three groups of Pods there. All your application workloads stay in their own namespaces. KEDA only reaches into them to read their scale and change their replica count.

flowchart TB
  subgraph Sources["External Event Sources"]
    Q["Message queue"]
    K["Kafka stream"]
    P["Prometheus metrics"]
    C["Cron schedule"]
  end
  subgraph Cluster["Kubernetes Cluster"]
    API["API Server"]
    HPA["Horizontal Pod Autoscaler"]
    subgraph KEDA["keda namespace"]
      OP["KEDA Operator - controller and scalers"]
      MS["Metrics API Server - external metrics adapter"]
      WH["Admission Webhooks"]
    end
    subgraph App["Application namespace"]
      SO["ScaledObject"]
      TA["TriggerAuthentication"]
      DEP["Deployment and Pods"]
    end
  end
  SO --> OP
  TA --> OP
  OP -->|"poll for events"| Q
  OP -->|"poll for events"| K
  OP -->|"poll for events"| P
  OP -->|"poll for events"| C
  OP -->|"scale 0 to 1 and 1 to 0"| DEP
  OP -->|"create and manage"| HPA
  HPA -->|"ask for external metrics"| API
  API -->|"forward request"| MS
  MS -->|"fetch values"| OP
  HPA -->|"scale 1 to N"| DEP
  WH -->|"validate objects"| API

Component by component

Almost everything you do in KEDA starts with one object. Learn its parts, and you can read any KEDA configuration you will ever meet.

What a ScaledObject is

A ScaledObject is a Kubernetes object that tells KEDA “scale this workload, between these limits, based on these triggers.” It lives in the same namespace as the workload. You create one for each application you want KEDA to manage.

The important settings, in plain words

A worked example in words

Imagine a service called “invoice-worker” that reads invoices from an SQS queue and turns them into PDF files. You write a ScaledObject that points at the invoice-worker Deployment. You set the minimum to zero and the maximum to 40. You add one trigger of type SQS queue, naming the queue and saying “target ten messages per Pod.” From then on, if 200 messages are waiting, KEDA wants 20 Pods. If the queue is empty for five minutes, it shrinks the Deployment to zero.

A scaler is the part of KEDA that knows how to talk to one kind of system. This is where KEDA gets its enormous reach.

What a scaler does

A scaler connects to a particular system, asks a question such as “how many messages are waiting?”, and returns two things: a number, and a yes-or-no answer to “is there any work at all?” The yes-or-no answer is called activity. It decides whether the workload should be running at all. The number drives how many Pods to run.

The families of scalers

Two numbers every trigger has

Almost every trigger has two main thresholds. The target value says how much work one Pod should handle, for example “ten messages per Pod.” This drives the Pod count once the workload is running. The activation value says how much work must exist before the first Pod is started at all, for example “at least one message.” Keeping these two ideas apart makes scale-to-zero behavior predictable. Chapter 10 explains why.

Most queues and databases need a password or identity. KEDA offers safe ways to provide them without putting secrets into scaling configuration.

The problem

To count messages in a private queue, KEDA must prove who it is. If you write the connection string straight into the ScaledObject, anyone who can read that object can read your secret. We want the credentials stored in one safe place and referenced by name.

TriggerAuthentication

A TriggerAuthentication is a separate KEDA object that describes how to log in. A trigger refers to it by name. The authentication object can pull values from several places:

• Kubernetes Secrets. The simplest option. The object points at a key inside a Secret.
• Environment variables of the target workload. KEDA reads values the workload already uses.
• Secret stores such as HashiCorp Vault. Values are fetched from a central vault at runtime.
• Cloud workload identity. KEDA uses an identity from the cloud provider, such as Microsoft Entra workload identity on Azure, IAM roles for service accounts on AWS, or workload identity on Google Cloud. No stored password exists at all.

Namespaced and cluster-wide versions

A TriggerAuthentication lives in one namespace and can be used only by ScaledObjects in that namespace. A ClusterTriggerAuthentication is cluster-wide and can be shared. Use the namespaced version by default. It limits the damage if one team misconfigures something.

The heart of KEDA is a clever division of labor between two different scaling mechanisms. Understanding this split explains almost everything about how KEDA behaves.

Two halves of the scaling range

Scaling a workload really has two separate problems. The first is deciding whether the workload should run at all: is it at zero, or is it at one or more? The second is deciding how many copies to run once it is awake. KEDA solves them in different places.

• Between zero and one: the KEDA operator decides. The HPA cannot handle zero, so KEDA does it directly by changing the replica count of your workload.
• Between one and many: the Kubernetes HPA decides. KEDA creates an HPA for you, and the HPA asks KEDA’s metrics server for the numbers it needs.

sequenceDiagram
  autonumber
  participant S as Event Source
  participant O as KEDA Operator
  participant D as Deployment
  participant H as HPA
  participant M as KEDA Metrics Server
  loop every polling interval
    O->>S: How much work is waiting?
    S-->>O: Value and activity
  end
  alt Work found and replicas are zero
    O->>D: Scale from 0 to 1
  end
  loop every HPA sync period
    H->>M: Request external metric value
    M->>O: Get latest value
    O-->>M: Current value
    M-->>H: Metric value
    H->>D: Set replicas between 1 and max
  end
  alt No activity for the cooldown period
    O->>D: Scale from 1 to 0
  end

Step by step

Going to zero is the most talked-about KEDA feature. It saves money, but it also changes how your system behaves, so it deserves a careful look.

Why zero matters

A workload with a minimum of one Pod costs money all day, even when nothing happens. If you have 200 small worker services and each sits idle 90 percent of the time, you pay for 200 always-on Pods to do almost nothing. With scale to zero, idle services use no CPU and no memory, and the cluster can shrink to fewer machines, which is where real savings appear.

Activation versus target

Each trigger in KEDA answers two different questions, and each question has its own threshold:

By default the activation value is zero, which means “wake up when there is any work at all.” You can raise it to avoid waking the workload for a trivial amount of work. For example, if starting the workload is expensive, you might say “do not wake unless at least 50 messages are waiting.”

The cooldown period

When the work disappears, KEDA does not shut down at once. It waits for the cooldown period, 300 seconds by default, with all triggers inactive before going from one to zero. This prevents a cycle of waking and sleeping if messages arrive in short bursts. Note that the cooldown applies only to the last step down to zero. Scaling from ten Pods to three is controlled by the HPA’s own rules.

The cost of sleeping: cold starts

When a workload is at zero and the first message arrives, someone must start a Pod, pull its image, start the program and make it ready. That can take from a few seconds to a few minutes. During that time the message simply waits in the queue. For background workers this is perfectly fine. For anything a person is waiting for, such as a web page, a cold start may be too slow. This is why scale to zero shines for queue and batch work, and why it needs extra care for interactive traffic (see the HTTP add-on in Chapter 17).

You do not need advanced mathematics to predict what KEDA will do. One short idea explains nearly every scaling decision.

The basic rule

For queue-like triggers, the HPA uses an “average value per Pod” idea. It divides the total metric value by the target value per Pod, and rounds up. If 230 messages are waiting and your target is 10 messages per Pod, then 230 divided by 10 is 23 Pods. If 231 messages are waiting, the result is 23.1, which rounds up to 24 Pods. Rounding up means the system always leans toward having enough capacity.

Then the limits apply

After the calculation, the result is held between your minimum and maximum. If the math says 300 Pods and your maximum is 40, you get 40. If the math says 0 and your minimum is 2, you get 2. Remember that if the minimum is zero, the HPA itself works from one upward, and the operator handles the last step to zero.

The tolerance band

The HPA does not react to tiny changes. By default, if the ratio between the measured value and the target is within about 10 percent of one, it does nothing. This prevents constant small adjustments. With 23 Pods running and a queue that grows slightly, you may not see a change until the number moves enough to cross this band.

Choosing a good target value

The target is the most important number you pick. Ask yourself: how many messages can one Pod finish in a reasonable time? If one Pod handles 5 messages per second and you want the queue cleared within 20 seconds, one Pod can clear about 100 messages in that time, so a target near 100 messages per Pod would keep the queue short. If your messages are slow and heavy, the target might be 5. Measure first, then set the target, and check it under real load.

Sometimes the right answer is not “more copies of a long-running program” but “one short-lived task for each piece of work.” KEDA has a second main object for exactly that.

Deployments versus Jobs

A Deployment runs Pods that live until they are told to stop. A Kubernetes Job runs a Pod to completion and then lets it exit. Which is better for event-driven work? It depends on how long each task runs and how safe it is to interrupt.

How a ScaledJob works

A ScaledJob looks similar to a ScaledObject but, instead of a scale target, it holds a template for the Job to create. KEDA polls the triggers on each polling interval. If it finds work, it creates Jobs, never more than the maximum replica count you set. Each Job runs its Pod to completion, and finished Jobs are kept for a while according to history limits so you can read their logs, and then cleaned up.

Scaling strategies

One subtle question is how many new Jobs to start when some are already running. KEDA offers several strategies:

Let us follow one burst of work from the moment it arrives until the system returns to rest. This ties together everything you have learned so far.

flowchart LR
  A["Burst of messages arrives"] --> B["Queue length rises"]
  B --> C["Operator polls and sees activity"]
  C --> D{"Replicas at zero?"}
  D -->|"yes"| E["Operator sets replicas to 1"]
  D -->|"no"| F["HPA already running"]
  E --> F
  F --> G["HPA requests metric from metrics server"]
  G --> H["Desired replicas computed"]
  H --> I["Deployment scaled up"]
  I --> J["New Pods start and pull messages"]
  J --> K["Queue drains"]
  K --> L["HPA scales down after stabilization window"]
  L --> M{"No activity for cooldown period?"}
  M -->|"yes"| N["Operator sets replicas to 0"]
  M -->|"no"| K

Where time is spent

Where state lives

KEDA keeps little state of its own. Your configuration lives in Kubernetes objects. The latest metric values live in the operator’s memory and are rebuilt after a restart. The HPA that KEDA creates is a normal Kubernetes object, so you can inspect it with ordinary tools. The status of each ScaledObject, including whether it is ready, active or in fallback, is written onto the object and visible through kubectl.

Real systems rarely depend on a single signal. KEDA lets you combine several, including time of day, in one object.

How several triggers combine

A ScaledObject can have many triggers. Each one independently proposes a Pod count. The HPA takes the highest of them. So if the queue trigger wants 8 Pods and the Prometheus trigger wants 12, you get 12. For activation, a workload wakes from zero if any single trigger is active, and goes back to sleep only when all are inactive. This “highest wins, any wakes it” behavior is safe by design: the system leans toward having enough capacity.

The cron scaler: scheduled capacity

The cron scaler turns the clock into a trigger. You give it a time zone, a start time, an end time and a desired number of Pods. Between the start and end, KEDA holds at least that many Pods. Outside the window, the cron trigger is inactive. This is perfect for predictable patterns: more capacity before the 9 a.m. rush, less overnight, and a bump before a weekly batch.

Combining signals wisely

• Queue plus cron. Scheduled floor, event-driven growth above it.
• Queue plus CPU. Scale on backlog, with CPU as a safety valve if the work turns out heavier than expected.
• Kafka lag plus Prometheus latency. Catch both a growing backlog and slow processing.

What happens when the thing KEDA depends on breaks? And how do you take manual control when you need it? These features answer both questions.

Fallback: a safe default when the source is down

Suppose KEDA cannot reach your message broker because of a network problem. Without a plan, it has no number, and the workload might stay stuck at whatever size it happened to have. The fallback feature lets you say: “if the scaler fails this many times in a row, hold the workload at this fixed number of Pods.” You pick the failure threshold and the replica count. When the source recovers, normal scaling resumes. The ScaledObject status shows a fallback condition while this is active, so monitoring can alert on it. Fallback works with metrics measured as an average per Pod, so check your trigger type.

Pausing autoscaling

Sometimes you want to freeze scaling, perhaps during a maintenance window, a debugging session or a data migration. KEDA supports annotations on the ScaledObject. One annotation pauses scaling and leaves the replica count where it is. Another pauses scaling and forces a specific number of replicas, which can even be zero. Removing the annotation resumes normal behavior. This is much safer than deleting the ScaledObject, since deletion hands control of the replica count back to whatever was there before.

Scaling modifiers: building your own formula

Newer versions of KEDA allow you to combine several triggers into one calculated value. Instead of “highest wins,” you write a small formula, for example a weighted sum of queue length and processing time. This is a power tool. It lets you express rules such as “scale on queue length, but only when error rate is low.” Because it is a newer feature, check the current KEDA documentation for its status and syntax before relying on it in production.

Autoscaling that reacts too fast flaps up and down. Autoscaling that reacts too slowly causes backlogs. This chapter shows the dials that control the speed.

The HPA behavior settings

Because KEDA uses a real HPA, you can tune the HPA’s behavior through the ScaledObject’s advanced options. Two directions can be tuned separately:

• Scale up. By default, the HPA may double the number of Pods, or add four, whichever is larger, every 15 seconds. That is fast. You can slow it down to protect a database from a sudden surge in connections.
• Scale down. By default, the HPA looks back over the past five minutes and picks the highest recommendation before shrinking. This stabilization window prevents sudden drops after a short lull. You can lengthen it for spiky workloads, or shorten it to save money faster.

Graceful shutdown: do not lose work when scaling down

When the HPA removes a Pod, Kubernetes sends it a polite stop signal and waits for a grace period before forcing it to stop. A well-written worker catches the signal, finishes its current message, and exits. A poorly written one is cut off mid-task, and the message is either lost or processed twice. For queue workers, set the grace period long enough to finish one typical message, and make sure your program handles the signal. Also design handlers to be idempotent, meaning that running the same message twice does no harm.

The built-in scalers cover a great deal, but not everything. These extension points let KEDA reach almost any signal, including web traffic.

External scalers: write your own

If your system is unusual, for example an in-house job scheduler, you can write an external scaler. This is a small server that speaks a simple protocol over gRPC, a fast way for programs to call each other. KEDA calls it with questions such as “is there any work?” and “what is the current metric value?” The scaler can be written in any language, run anywhere inside or outside the cluster, and answers from any data source you like. There are two styles. In the pull style, KEDA asks on each polling interval. In the push style, the scaler keeps a connection open and tells KEDA the moment activity changes, which reacts faster for waking from zero.

The metrics-API and Prometheus scalers

Often you do not need new code at all. The Prometheus scaler lets you write a query against your monitoring system and scale on its result. This is how you scale on things like “orders per minute” or “99th percentile latency” with no extra programming. The metrics-API scaler does the same for any HTTP endpoint that returns a number in JSON. Together they cover a huge range of business signals.

The HTTP add-on: scaling web traffic, even to zero

Plain KEDA reacts to queues and metrics, not to individual web requests. For web applications there is a companion project, the KEDA HTTP add-on. It places a small proxy called an interceptor in front of your service. When a request arrives for an application that is asleep, the interceptor holds the request, tells KEDA to wake the application, and forwards the request when the first Pod is ready. The user sees a slow first response instead of an error. While running, the interceptor also counts requests, so scaling can follow real traffic. Check the project’s current maturity level before using it for critical user-facing paths, since the add-on has been developing more slowly than the core.

Scaling custom resources

KEDA can scale anything that supports the standard scale interface, not only Deployments. This includes StatefulSets and many custom resources created by operators, such as certain machine learning serving frameworks. As long as the object exposes how many replicas it wants, KEDA can drive it.

KEDA is easy to install, and several platforms ship it ready to use.

Ways to install

• Helm chart. The most common method. One command installs the operator, the metrics server and the webhooks into their own namespace, and lets you set options through a values file.
• Plain manifests. The project publishes ready-made files you can apply directly, which suits teams that prefer fully explicit configuration.
• OperatorHub. On platforms that use operator catalogs, KEDA can be installed and upgraded through the catalog.
• Managed add-ons. Some cloud services offer KEDA as a built-in feature you switch on.

KEDA on major platforms

What to decide before installing

• One KEDA per cluster. Only one metrics server can register the external-metrics interface in a cluster. If another adapter already owns it, you must resolve the conflict first.
• Watch scope. By default KEDA watches all namespaces. You can limit it to chosen namespaces in shared clusters.
• Resource requests. Give the operator enough memory for the number of ScaledObjects you plan to run.
• Node placement. Place KEDA on reliable nodes, not on spot machines that may disappear.

KEDA can change how many Pods run and it holds the keys to your queues. That makes it a sensitive component, and it deserves careful protection.

What KEDA is allowed to do

To work, the operator needs permission to read ScaledObjects, to read and change the scale of target workloads, to create and update HPAs, and to read the Secrets that TriggerAuthentications reference. These permissions are broad by default. Anyone who controls KEDA can start or stop your workloads, and may be able to read credentials that scalers use.

Protecting the system

• Control who can create KEDA objects. Anyone who can create a ScaledObject can set the maximum replica count and cause a large bill or overload a downstream database. Use RBAC to limit these rights to trusted teams.
• Prefer identity over passwords. Use cloud workload identity so no secrets are stored, and grant only the narrowest permission, such as reading queue attributes.
• Use namespaced authentication. TriggerAuthentication objects stay inside their namespace. Use the cluster-wide kind only for shared credentials that you truly want every team to use.
• Limit the watch scope. In multi-tenant clusters, restrict the operator to namespaces that need it, or run separate controlled setups.
• Secure the metrics endpoint. The metrics server speaks through the Kubernetes aggregation layer. Keep its certificates valid and its network paths restricted.
• Apply network policies. Allow the operator to talk only to the API server and to the event sources it needs.
• Guard the supply chain. Install official images, pin versions and verify signatures where the project provides them.
• Cap the blast radius. Use admission rules, for example with a policy engine, to enforce a maximum replica count and require a reasonable polling interval across all ScaledObjects.

An autoscaler you cannot see is an autoscaler you cannot trust. KEDA gives you status, events, logs and metrics.

Status on the objects

Start with the ScaledObject itself. Its status shows conditions: whether it is ready, whether it is active, and whether fallback is in effect. It also shows the name of the HPA it created, the external metrics it provides and the time of the last activity. A quick description of the object, plus a look at the HPA, answers most “why did it scale?” questions.

Events and logs

KEDA records Kubernetes events when it activates or deactivates a workload and when something fails, for example when a scaler cannot connect. The operator and metrics server also write structured logs. When scaling seems stuck, the operator log usually names the scaler and the exact error, such as a rejected credential or an unreachable broker.

Prometheus metrics

KEDA exposes its own metrics in the Prometheus format. Exact names change between versions, so check the documentation for yours, but the useful families are:

Dashboards and alerts

A single dashboard per workload that shows queue length, desired replicas, actual replicas, and processing time tells the whole story. Useful alerts include:

• A scaler reporting errors for several polls in a row.
• A workload in fallback mode.
• Queue length rising while replica count is at its maximum, meaning you have hit your ceiling.
• Queue length high but replicas at zero, meaning activation failed.
• Operator or metrics server Pods restarting.
• Oldest message age passing a service goal, which is often a better signal than length.

KEDA must itself scale gracefully, and it must scale your workloads fast enough. Both questions come down to a few measurable things.

Reaction time: how quickly can you scale?

Total time from burst to capacity is the sum of polling delay, HPA delay, Pod scheduling, image pull and application warm-up. Shortening the polling interval to a few seconds helps, but each poll is a call to your event source. Calls to cloud queue services may cost money and are subject to rate limits, so a very short interval across hundreds of ScaledObjects can add up. Balance speed against cost and limits.

Pod startup is usually the bottleneck

Teams often tune the polling interval and forget that a Pod takes 90 seconds to start. Make start-up faster by keeping images small, using cached base layers, avoiding heavy work at start, and defining readiness checks that turn true as soon as the program can really accept work. If new Pods cannot be placed because the cluster is full, the node autoscaler must add machines, which can take minutes. Keep a small buffer of spare capacity for latency-sensitive workloads.

Scaling KEDA with the number of objects

• Many ScaledObjects. Each one has its own polling loop. Thousands are possible, but give the operator enough CPU and memory, and watch its logs for slow scalers.
• Slow event sources. One scaler that takes ten seconds to answer can delay others sharing its loop. Watch scaler latency.
• Shared queues. If twenty ScaledObjects poll the same broker, consider the total request rate that broker sees.
• Metrics server load. The HPA asks for metrics every few seconds for each ScaledObject, and the metrics server answers from cached values, so this is cheap, but it must stay healthy.

Protecting what sits behind the workers

The fastest autoscaling is not always the best. If 200 Pods wake up and all open connections to the same database, the database may fall over. Set the maximum replica count to what downstream systems can bear, limit how fast scale-up can happen, and use connection pooling.

KEDA is on the path of your scaling, so you must know what happens when it stumbles and how to make it sturdy.

What breaks when KEDA is down

If the operator stops, workloads that are already running keep running at their current size. The HPA that KEDA created still exists, but it cannot get fresh metrics, so it holds steady or reports missing metrics. Scaling to and from zero stops, which is the more serious effect: a sleeping workload will not wake up while the operator is down, and messages wait in the queue. Because queues hold messages safely, the usual result is delay, not data loss. That makes event-driven systems naturally forgiving, provided the queue itself is durable.

Making KEDA itself highly available

• Run standby operator replicas. The operator supports leader election, so extra replicas wait in standby and take over quickly if the active one fails. Check the current documentation for how the metrics server should be replicated.
• Spread across zones. Use topology spread or anti-affinity so failure of one zone does not remove all KEDA Pods.
• Set disruption budgets. Prevent node upgrades from evicting every KEDA Pod at once.
• Use priority classes. Make sure KEDA is scheduled even when the cluster is under pressure.
• Use fallback. Give important ScaledObjects a safe replica number for when their event source cannot be read.

Designing workloads that recover well

Make your consumers idempotent, so that a message delivered twice is not harmful. Use dead-letter queues so a poisonous message does not block a worker forever. Use visibility timeouts or acknowledgments properly, so messages from a worker that is shut down mid-task return to the queue. These habits turn scaling events from risky moments into routine ones.

For many teams, the main reason to adopt KEDA is money. Here is how the savings actually appear, and how to avoid false economies.

Where the savings come from

• No idle Pods. Workloads at zero use no CPU or memory requests, so the scheduler can pack other work onto fewer machines.
• Right-sized peaks. Instead of provisioning for the worst day all month, capacity follows demand hour by hour.
• Fewer nodes. When the node autoscaler sees empty machines, it removes them. This is where the actual bill falls.
• Cheaper machine types. Interruptible workers can run on discounted spot or preemptible machines, because a queue safely absorbs interruptions.

The savings only appear if nodes shrink

Scaling Pods to zero saves nothing by itself if the machines underneath stay on. The money is saved when the node autoscaler removes unused nodes. Make sure the node layer is set up to scale down, and watch for Pods that block it, such as ones with local storage or restrictive disruption budgets.

Counting the costs on the other side

KEDA is one of several ways to scale on demand. Knowing the alternatives helps you use each where it is strongest.

KEDA and Knative

The two projects solve different problems and can live side by side. Knative is a full serverless layer for web services: it routes traffic, manages revisions and scales mainly on request load. KEDA is a focused autoscaler for any workload and any event source, with no routing layer. Pick Knative when you want a serverless platform for HTTP services. Pick KEDA when you want to keep ordinary Deployments and Jobs and add event-driven scaling to them.

KEDA and node autoscalers

KEDA changes the number of Pods. A node autoscaler such as the Cluster Autoscaler or Karpenter changes the number of machines. They are partners: when KEDA asks for many new Pods and the cluster is full, Pods wait in a pending state, and the node autoscaler adds machines to fit them. A good design plans both layers together.

Teams that run KEDA well tend to follow the same habits. Teams that struggle tend to fall into the same traps.

Patterns that work

Patterns that hurt

A short checklist you can paste into your team’s playbook.

The most common mistakes, explained

• Wrong target value. Setting the target to 1 message per Pod, “to be fast”, creates huge Pod counts for small backlogs. Set it by measured capacity.
• Ignoring the activation value. A workload that wakes for every single message may start and stop constantly. Raise the activation value when starting is costly.
• Forgetting that the cooldown only covers the last step. Scaling from many Pods to one is controlled by HPA behavior, not the cooldown period.
• Using the wrong metric type. A value that is a total needs to be divided among Pods. A value already measured per Pod should not be. Mixing them gives wrong Pod counts.
• Setting minimum replicas above zero by habit. This quietly removes the savings of scale to zero.
• Trusting default timeouts for slow sources. A scaler that often times out causes erratic scaling. Fix the source or choose a different metric.
• Not testing fallback. Teams configure it, but never block the source in a test to see what happens.

When scaling does not behave, work through these problems in order. Most issues fall into a handful of categories.

Problem: the workload does not scale at all

• Check the ScaledObject status. Is it ready? An invalid trigger setting or an unreachable source shows up here first.
• Check the operator log. Look for authentication errors, connection errors or messages that the target could not be found.
• Check the HPA. Does the HPA exist, and does it report a current metric value? A missing value usually means the metrics server is not registered correctly.
• Check the target. The name and kind in the ScaledObject must match the real workload in the same namespace.

Problem: it will not wake from zero

Confirm that the trigger really reports activity. Compare the measured number with the activation value. If the activation threshold is higher than the current backlog, the trigger is correctly inactive. Also check whether the pause annotation is present, and whether a minimum of zero is actually set.

Problem: it scales up but never down

Look at the stabilization window and the scale-down policies. A long window holds the highest recent recommendation. Check whether another trigger, such as a CPU trigger or a cron window, is keeping the number high. Look also for messages that are stuck in flight, which can make the queue appear non-empty.

Problem: the Pod count flaps up and down

Suspect a target value that is too sensitive, a polling interval shorter than the processing time, or two autoscalers competing for the same workload. Lengthen the stabilization window and confirm that there is only one HPA.

Problem: scaling is correct but still too slow

Measure each stage: polling delay, HPA delay, scheduling, image pull and warm-up. Most of the time the largest part is Pod and node startup, not KEDA. Reduce image size, keep spare node capacity, and shorten the polling interval where the source allows it.

Problem: errors about metrics not available

This normally means the external-metrics interface is not served properly. Check that the metrics server Pod is healthy, that its registration with the API server shows as available, and that no other adapter has claimed the same interface.

KEDA is not a niche tool. It sits underneath major cloud services and runs in many production clusters.

This is an illustrative story built from common patterns. The company is fictional, but the decisions and problems are realistic.

The situation

PayWave is a payments company whose platform sends receipts, fraud alerts and settlement reports through a set of queue workers. There were 45 worker services, each running at least three Pods around the clock for safety. Traffic was heavily uneven: a monthly salary day created a rush 30 times higher than a quiet night. The team faced two problems. During salary day, queues grew faster than the old CPU-based scaling reacted, and customers received receipts up to 20 minutes late. During the rest of the month, most workers sat idle and cost money.

The approach

Problems they hit

The first salary day exposed a poison message that crashed workers and returned to the queue repeatedly. The queue never emptied, so KEDA kept scaling to the maximum. The cap held the damage, and an alert on the maximum being reached caught it within minutes. The team then added a dead-letter queue. Another issue was a cold start of nearly two minutes for report workers because of a large image. Slimming the image brought it under 20 seconds.

The results

Adopting KEDA is a project, and so is keeping it current. These steps make both smooth.

Migrating from a plain HPA

Upgrading KEDA

Treat each upgrade like any platform change. Read the release notes for changed defaults, deprecated settings and renamed metrics. Upgrade a test cluster first and replay a burst. Check that scalers you rely on have not changed behavior. Pin versions so no one gets a surprise upgrade. Confirm that your Kubernetes version is supported by the KEDA version you choose, since each release supports a range of Kubernetes versions.

Ongoing care

• Review quarterly. Look at which workloads hit their maximum, which never scale, and which keep a high minimum without a reason.
• Retire unused objects. Delete ScaledObjects for services that no longer exist.
• Track deprecations. Scalers and settings are occasionally renamed or removed. Watch for warnings in logs.
• Rehearse failure. Once in a while, block a source in a test environment and confirm that fallback and alerts behave as designed.

Short answers to the questions people ask most often.

If you remember only a handful of ideas from this guide, make them these.