Live webinar! Reserve your spot to explore Event-driven vs. Resource-based scaling.
Learn more
by Zbynek Roubalik
June 17, 2025
Kedify’s HTTP scaler has been running in production across many customer environments—handling everything from gRPC and WebSockets to TLS-heavy web workloads. It’s fast, reliable, and has been used to scale all kinds of traffic patterns, including those with zero baseline.
We’ve added support for diverse use cases over time: scaling out internal APIs, external websites, even services that serve one-off event bursts. A lot of this has come directly from customer feedback.
Two common requests stood out:
That’s why we’re rolling out two new features in Kedify’s HTTP scaler:
These are about keeping the user informed and the experience solid, especially when scaling behavior isn’t instantaneous.
Protect your users from cold start failures.
Try Kedify HTTP scaler’s new waiting and maintenance pages.
Get Started FreeWhen running public-facing applications, like websites or portals, that use scale-to-zero for cost savings, there’s often a noticeable gap during cold starts. A user visits your site, but the backend is still spinning up. During this moment:
This isn’t just about technical uptime. It’s about perceived reliability. For these kinds of applications, feedback matters. Users expect a response, even if it’s just “hang tight, we’re starting up.”
Waiting Pages are designed exactly for this: a human-friendly buffer. They’re ideal for interactive apps meant to be accessed by real users, not background microservice traffic or machine-to-machine APIs. If you care about first impressions or UX under load, this is the tool to reach for.
Waiting Pages act as an intelligent buffer. When a request arrives and no pod is ready, Kedify shows a holding page, buys time, and retries behind the scenes.
triggers: - type: kedify-http metadata: hosts: www.my-app.com pathPrefixes: '/' service: http-demo-service port: '8080' scalingMetric: requestRate targetValue: '10' coldStartWaitingPageEnabled: 'true' coldStartWaitingPageBody: '<html><body><h1>Spinning things up! Hang tight...</h1></body></html>' coldStartWaitingPageStatusCode: '503' coldStartWaitingPageRetryAfter: '10s'
The waiting page can be defined in three ways:
coldStartWaitingPageBody
in the ScaledObject trigger metadataConfigMap
via coldStartWaitingPageConfigMapRef
This way, instead of a 503 error, users see a helpful message and rarely notice the cold start.
Sometimes, things go wrong: resource limits, misconfigurations, or quota caps might prevent scale-up. Other times, teams need to take services offline for updates or planned maintenance.
Maintenance Pages handle both cases. They provide a reliable way to serve a friendly message to users instead of leaving them with a broken experience.
triggers: - type: kedify-http metadata: hosts: www.my-app.com pathPrefixes: '/' service: http-demo-service port: '8080' scalingMetric: requestRate targetValue: '10' maintenancePageEnabled: 'true' maintenancePageBody: '<html><body><h1>We’re doing some quick maintenance. Please check back soon.</h1></body></html>' maintenancePageStatusCode: '503'
You can configure the maintenance page via:
maintenancePageBody
directly in the ScaledObjectConfigMap
via maintenancePageConfigMapRef
This is especially useful for frontend services or portals where users expect clarity, not cryptic errors or endless loading spinners.
Whether you’re using scale-to-zero for cost efficiency, dealing with bursty traffic, or running customer-facing apps that need consistent branding and feedback, these features are built for you. Waiting and Maintenance Pages help ensure a smooth experience under pressure, acting like UX airbags for your autoscaling workloads.
Together, Waiting and Maintenance Pages act like UX airbags for your autoscaling workloads.
These features are available now in Kedify’s HTTP scaler. Read the docs for implementation steps, or book a consult to talk with a founding maintainer of KEDA.
Built by the core maintainers of KEDA. Designed for teams that scale with confidence.
Share: