AWS Kubernetes Health Monitoring Case Study for Smart Building Reliability

Executive Summary

Ficode helped a UK-based smart-building technology provider improve the reliability and observability of its AWS-hosted platform by auditing health monitoring across more than 33 microservices running on Amazon EKS. Our team identified false health signals, optimised Kubernetes health checks, and created a structured roadmap for implementing reliable monitoring, automated recovery, and future-ready autoscaling across the platform.

Client Overview

Our client is a UK-based smart-building technology company providing cloud-based building management solutions for commercial properties. Their AWS-powered platform integrates IoT devices, building automation systems, and enterprise applications to enable real-time monitoring, operational control, and facility management. As the platform continued to scale, the client required a reliable monitoring strategy to improve system visibility, reduce false alerts, and strengthen operational reliability.

Business Challenges

The platform was facing a specific version of the monitoring confidence problem:

• Monitoring dashboards were showing a majority of services as unhealthy but users were logging in, live data was flowing, and the platform was operating normally.
• With no reliable way to distinguish a false health alert from a genuine failure, the operations team had lost confidence in the monitoring dashboard as a source of actionable information.
• Services without health monitoring were running without any automated recovery a crashed or hung service could remain failed indefinitely with no alert and no automatic restart.
• Poorly configured health checks risk the opposite problem: a working service restarted unnecessarily creates a crash loop that looks identical to a genuine failure.
• Without a clear picture of which services had reliable health endpoints, there was no safe starting point for adding automated monitoring.

Ficode Solution

Traffic Routing Layer:

The platform routes all traffic through a single load balancer using path-based rules the authentication API answers at /auth, the platform API at /platform, and so on. The load balancer was checking service health by requesting the root path for every service. Path-based services don’t serve anything at the root path; they return a 404 or connection error. Every service was correctly marked unhealthy for responding correctly to a request it was never designed to handle. The fix is a configuration change, not application code, and it eliminates the false alarms immediately.

Kubernetes Automated Recovery:

The cluster was running more than fifteen application services without automated health probes. A service process that crashed, hung, or became unresponsive would remain in that state indefinitely the cluster had no mechanism to detect the problem or restart the service.

Three-tier Classification:

Every service was classified into one of three groups: services with confirmed, stable health endpoints that can have monitoring added immediately; services with appropriate endpoints that need the target to be specified explicitly; and services with no dedicated health endpoint, which require a short code change before probes can be configured safely.

Security & Scalability

• TLS-protected ingress through a controlled load-balancing layer.
• Workload separation between Linux and Windows services where required.
• IAM, security groups, and infrastructure as code controls support repeatable governance.
• Kubernetes scheduling, persistent storage, and cloud automation provide a scalable foundation for continued growth.

Results & Business Impact

33+ Services Reviewed for Health Monitoring:

The platform was assessed service by service to identify which workloads were ready for health probes and which needed application-level changes first.

3-Tier Reliability Roadmap Created:

Services were grouped into immediate, near-term, and future-readiness categories, giving the team a practical phased plan instead of a risky all-at-once rollout.

6 Critical Services Prioritised First:

Live data delivery, historical charts, and external integration services were prioritised for reliable probes because they have the highest user-visible impact.

0-Downtime Health-Check Correction:

Correcting the load balancer health-check configuration removed misleading unhealthy signals without downtime, code changes, or a maintenance window.

2 Probe Types Prepared for Autoscaling:

Accurate readiness and liveness probes created the operational prerequisite for safe horizontal scaling of high-traffic Kubernetes services.

Conclusion

Looking to modernise your cloud infrastructure or improve application reliability on AWS? Partner with Ficode’s AWS experts to build secure, scalable, and high-performance cloud-native solutions tailored to your business goals.

About Ficode

Ficode is a global software development and AWS consulting company specialising in cloud-native application development, AWS infrastructure, DevOps, QA & Software Testing, AI solutions, enterprise software engineering, and digital transformation. We help businesses worldwide build secure, scalable, and high-performance technology solutions that accelerate innovation and long-term growth.