How it compares
Three ways to stop paying for idle staging.
Napwake, a timetable or a scale-to-zero proxy. Here are the same four rooms through one evening and the next morning, run each way. Step through it, or drag the time.
Napwake
Pauses on use, and wakes on the first request at the Service, with a forecast.
Napwake keeps an activity clock for every room. CPU, deploys, your tools’ annotations and Prometheus queries, such as request rate, all count.
dev in use, staging in use, pr-42 in use, qa in use. The doorman is on duty beside staging.
A scale-to-zero proxy
Such as KEDA’s HTTP add-on, Sablier or Knative.
Requests reach these rooms through the proxy. Your Ingress or routes point at it.
dev in use, staging in use, pr-42 in use, qa in use.
Napwake pauses a room after idleAfter with no sign of use. This evening uses the default, an hour. Set it per workload, per namespace or for the whole cluster. The morning has autoResume on, with a forecast that has learned the team’s week.
01 What only Napwake does
Only Napwake does all five.
A timetable or a proxy may do one or two of them.
It pauses on use.
Napwake counts how long a room has been idle. CPU, deploys, your own tools and Prometheus queries, such as request rate, all count as use.
It wakes on the first request.
At the Service, for any TCP: HTTP, gRPC, Postgres, Redis. The doorman holds the request while the room wakes. Your Ingress doesn’t change.
The room is ready before the team.
Napwake learns each room’s week. With
autoResume, it wakes a room 15 minutes before an hour it expects busy.On a public URL, it can ask first.
Set
napwake.dev/wake: ask, and the doorman asks before he wakes a room. A browser gets a Wake it button, so a person wakes it and robots don’t.It never deletes anything.
A pause scales a workload to zero. Only the pods go. The workload, its Services and its data stay.
02 Side by side
Three approaches, five questions.
| Napwake | A timetable | A scale-to-zero proxy | |
|---|---|---|---|
| What decides | Use. CPU, deploys, your tools’ annotations and Prometheus queries, such as request rate. Paused after idleAfter with none. | The clock. A schedule turns rooms off and on at set times. | Requests through the proxy. A room with none for a while is turned off. |
| What wakes it | The first request at the Service, for any TCP. On a public URL set to ask, a person’s click. Or, with autoResume, the forecast, 15 minutes early. | The clock, at the on time. | An HTTP request through the proxy. |
| What the first person sees | Usually one slow response while it starts. A browser gets a waking page. A room the forecast woke is already up. | Out of hours, nothing answers. In hours, the room is on, used or not. | A slow first response while the room starts. Some show a waiting page. |
| What you change in your setup | A Helm install, metrics-server, and a label on a workload or namespace. Apps need readiness probes. Your Ingress, Services and DNS stay as they are. | An operator or a CronJob, and a schedule for each namespace or workload. Nothing sits in the request path. | The proxy, with your Ingress or routes sent through it and a route or an object per app. Some need apps redeployed in their own format. |
| What happens to work with no traffic | It stays on while its CPU is busy, or while your tools mark it in use. | It stops at the off time, finished or not. | Most count only requests, so a busy queue worker looks idle and can be paused mid-job. |
What the table says of a timetable or a proxy is true of most tools of that kind, by their own docs, checked 2026-10-22. Napwake’s column is from its docs.
See it on your own cluster.
One command shows what’s idle in your cluster and what pausing would free, with nothing installed.
$ kubectl napwake scan