AWS Kubernetes Health Monitoring for Smart Building Reliability
Ficode reviewed health monitoring across 33+ microservices, corrected a misleading load-balancer health check without planned downtime and defined a three-tier roadmap covering six prioritised services.
The project in context
For a connected-building platform, an unhealthy signal can change how traffic is routed or how a service is restarted. Ficode reviewed health monitoring across 33+ microservices, corrected a misleading load-balancer health check without planned downtime and defined a three-tier roadmap covering six prioritised services.
Misleading health signals. Uneven checks. Too many services to fix at once.
The smart-building platform needed health checks that reflected service readiness rather than returning an inaccurate healthy or unhealthy status. Across a large microservice estate, inconsistent checks also made it difficult to identify where a correction would matter most.
The challenge Before
Misleading signals
A check may not match the real service stateUneven probe coverage
Checks have different purposes across servicesRemediation at scale
A broad estate needs practical prioritiesWith Ficode Connected Approach
Review signals
Inspect health-check behaviour across 33+ servicesCorrect the check
Align the misleading load-balancer signalPlan the work
Three tiers and six prioritised servicesReview the checks, correct the false signal and plan the next fixes
Review
Assess existing health-check behaviour across more than 33 microservices to understand where signals may be unreliable or missing.
Classify
Set out when readiness, liveness and startup checks are appropriate.
Correct
Align the identified health-check configuration with the intended service behaviour. The source reports that this correction required no planned downtime.
Prioritise
Organise the follow-up work into three tiers and identify six services for prioritised improvements.
From a reported health signal to a clearer operational decision
Review probes
Inspect existing health and load-balancer checksCompare with behaviour
Assess signals against service readinessCorrect and prioritise
Fix misleading checks; plan follow-upCONNECTED OUTCOME
One misleading load-balancer check was corrected without planned downtime; remaining improvements were organised into three tiers, with six services prioritised.
A more useful monitoring picture and a practical plan
Broader visibility into health-check gaps
Reviewing more than 33 microservices gave the team a structured view of health-check behaviour across the platform.
A clearer purpose for each check
Differentiating readiness, liveness and startup probes makes it easier to assess whether a check supports routing, restart or startup decisions.
A targeted correction without planned downtime
The misleading load-balancer health check was corrected without planned downtime.
A manageable sequence for follow-up work
Three remediation tiers and six prioritised services gave the platform team a starting point for improving monitoring in stages.
The project outputs were a 33+ service review, a three-tier plan, six prioritised services and a reported correction without planned downtime.
Confirmed technology and implementation scope
Amazon EKS, Kubernetes and microservices; readiness, liveness and startup probe strategy; load-balancer health checks and phased service remediation.
