In my previous post, we looked at how default Google guest daemons consume over 15% of available memory on a 1 GB Google Compute Engine (e2-micro) instance, pushing standard Debian images into SSH lockout during moderate memory pressure.

To see how far we could push the lower boundary of GCE instances without sacrificing reliability, I built a custom minimal Alpine Linux image (alpine-3-24-1-uefi-lite-v5).

We subjected this image to a punishing synthetic stress harness: pinning 900 MB to 1,250 MB of memory, driving 16 concurrent worker threads, and executing over 167,000 sub-processes in five minutes. While standard Debian froze solid, the Alpine instance maintained sub-second SSH logins and responsive interactive keystrokes.

Google Compute Engine’s e2-micro instances are a staple of the GCP Free Tier, offering 2 vCPUs and roughly 1 GB of RAM (969 MiB usable). They are ideal for lightweight bastions, cron runners, and small test beds. However, if you run memory-sensitive workloads—such as Go builds, package extractions, or continuous process forks—you may have experienced intermittent, baffling SSH connection timeouts and unresponsive terminals.

The root cause is rarely your application alone. By default, GCE provisions a suite of Google guest daemons that consume a disproportionate share of resident memory on small VMs, creating an environment primed for SSH exhaustion.

Testing alerting in Google Cloud Monitoring requires a proactive approach, especially with uncommon scenarios. For assertions that almost always pass—such as DNS record verification or health checks—you can simulate failures using synthetic log injection.

The Alerting Signal: assertion_passed: false

At the heart of this strategy is a convention: services perform their internal checks and log a JSON payload with an assertion_passed boolean. When a check fails—be it a DNS mismatch or a stale cache—the service logs {"assertion_passed": false}.