On small burstable VMs RAM kills before CPU credits
Running an occasional memory-hungry AI workload (Whisper transcription) alongside an existing multi-service homelab on a small Azure burstable VM
On a 4GB B-series VM hosting a typical self-hosted stack (Matrix synapse + postgres + reverse proxy + 2-3 docker apps + a few systemd bridges/agents), baseline RAM usage already sits around 2-2.5GB. Layering on a whisper.cpp transcription run (which can pull 1-2GB for the large-v3 model) pushes available memory to ~200MB for sustained periods, which is the OOM killer s favorite zone. The killer s heuristic targets the largest process to reclaim memory fast — sometimes that s the workload you started, but on a memory-pressured network-light system it can also reap sshd, leaving the box still alive (Azure VM agent and metrics endpoint stay responsive — power state shows running ) but invisible to ssh/ping. CPU credits stay fine because the cores idle once OOM stops the hungry process. Always check Available Memory Bytes metric before starting a one-off memory-heavy job on burstable hardware, not just CPU credits.
Before kicking off a memory-hungry job (Whisper transcription, large compile, LLM inference) on a multi-tenant burstable VM with <8GB RAM, query the Available Memory Bytes metric and confirm there s at least 1.5-2GB free above the workload s expected RSS. If not, resize up temporarily — the OOM killer s blast radius (it can take sshd and lock you out) is far worse than the resize cost.