The article describes a real-world incident experienced by the author while managing a small side project hosted on a free-tier virtual private server with only 1 GB of memory and a single CPU core.

The infrastructure included a monitoring watchdog running on a separate server that periodically checked a health endpoint and was configured to automatically reboot the main server if it appeared unresponsive for an extended period.The problem occurred when the author launched an intensive ffmpeg task on the production server.Because the machine had only one CPU core, the video-processing job consumed nearly all available processing power.As a result, the application's health-check endpoint could not respond within the watchdog's 10-second timeout window.

Although the server itself remained operational, the monitoring system interpreted the delayed response as a server failure and was close to triggering an unnecessary reboot.

Using this example, the author argues that asking whether a system is 'fully fixed' is misleading because software and infrastructure are open systems with constantly evolving failure modes.Fixes often introduce new risks, especially in resource-constrained environments where components are tightly coupled.

The article also emphasizes that monitoring systems are themselves part of the infrastructure and can become sources of failure if not designed carefully.Rather than seeking absolute guarantees, the author recommends focusing on resilience, detection, and recovery.

The implemented solution was to require multiple failed health checks before declaring the server down, reducing the risk of false positives caused by temporary resource spikes.

The broader lesson is that engineering should prioritize understanding known failure scenarios, validating fixes, and creating mechanisms to detect and recover from unexpected problems rather than assuming any issue can be permanently eliminated.