Watch pod CPU and memory on every 3B service, and alert when usage stays high. This is the first line of operational monitoring; how and when to scale is what you do after an alarm fires.
Metrics Server is enough to inspect live usage (kubectl top pods -n 3b) and to drive a CPU-based HPA. It is not enough to alarm: put these thresholds on the metrics pipeline described in what to monitor.
What to watch
Workload | Default request | Why |
| 512m CPU, 2 GiB memory | UI, API, and sign-in. Saturation shows up as a slow console. |
| about 1.2 CPU / 2.5 GiB together | Concurrent executions. CPU can look calm while the worker is still the bottleneck — see the note in how and when to scale. |
| 256m CPU, 512 MiB memory | Webhooks and public links. |
| 2 CPU, 4 GiB memory | File storage. One replica; raise |
| 512m CPU, 1 GiB memory | Schedules executions. |
| 1 CPU, 2 GiB memory | Live UI sync. |
The in-cluster postgres StatefulSet ships without CPU or memory requests, so percentage-of-request alerts will not fire on it. Watch the pod’s raw usage and the node it lands on, and see Postgres for database-specific signals.
On the single-server install everything shares one VM. Alarm on host CPU, memory, and disk as well as the pods; resize the VM as described in sizing.
Alarms to set
Use your pipeline’s pod CPU and memory metrics (kubelet / cAdvisor). Starting points:
Alarm | When to fire | What to do |
CPU sustained | Above about 80% of the container’s CPU request for 10 minutes | Raise replicas for |
CPU spike | Above about 95% of the request for 2 minutes | Same as above if it repeats; a single spike can be a deploy or a burst of executions. |
Memory | Above about 80% of the memory limit for 15 minutes | Raise the memory request and limit together. The next step is an OOM kill. |
An HPA targeting about 50% average CPU on worker, api, and edge is a good complement to these alarms, not a replacement. The alarm is what pages you when usage is already too high; the HPA is what adds replicas before you get there. Metrics Server (or a Prometheus adapter) must be running for that HPA to see CPU.
Page when a Deployment or StatefulSet has fewer Ready pods than it should for several minutes: the service is down or stuck, not merely busy.