Skip to content

Health scoring

xrelia continuously evaluates the health of every service instance using health checks, synthetic requests, metrics, and dependencies These signals are combined into a health assessment that reflects both the current operational state and the confidence of that assessment.

Health is calculated at the service instance level and then aggregated upward:

Service Instance → Service → Platform

This hierarchy allows xrelia to detect localized failures while still providing a clear view of overall service and platform health.

Each service instance receives a health score based on the current state of its health checks, synthetic requests, metrics, and dependencies.

Health is not binary. An instance may be fully healthy, degraded, partially unavailable, or unavailable.

Service instance health is the primary operational signal used for alerting, incident creation, and service health aggregation.

Service health represents the combined health of all instances belonging to the same service.

A service with multiple instances may remain healthy even if one instance fails, depending on the severity and the proportion of affected instances.

Service health provides a logical application-level view that abstracts away individual deployment details.

Platform health represents the overall operational state of a platform, such as production or staging.

xrelia aggregates the health of all services within a platform and weighs them by service importance. A critical production service has a greater impact on platform health than a non-critical internal tool.

Platform health provides a high-level view of whether an entire deployment environment is functioning normally.

The Confidence score measures how certain xrelia is about a service’s health assessment.

A service instance with many recent observations from health checks, synthetic requests, and metrics has high confidence. An instance with sparse data, newly created checks, or intermittent reporting has lower confidence.

Recent deployments and configuration changes also influence confidence during incident analysis by increasing the likelihood that a new failure is related to a recent change.

Confidence helps distinguish between “the instance is healthy” and “we do not have enough evidence to know.”

Latency is evaluated using percentile distributions rather than simple averages.

xrelia tracks percentiles such as p50, p90, and p99 to capture the full range of response time behavior.

Percentiles provide a more accurate view of user experience and help detect performance degradation before availability is affected.

Availability is calculated from health check and synthetic request results over rolling time windows.

xrelia measures the percentage of successful observations and tracks uptime across configurable periods. Availability calculations automatically account for failures, timeouts, and missing observations.

Availability is used for health scoring, alerting thresholds, and service-level reporting.

Health calculations are performed over rolling observation windows.

Short windows provide fast detection of failures, while longer windows provide stability and historical context. xrelia combines multiple windows to balance responsiveness with accuracy.

For example, a brief spike may affect a short-term health score, while a sustained outage will significantly affect both short-term and long-term health.

Deployments and configuration changes do not directly reduce health scores. Instead, xrelia uses them as contextual signals during incident detection and root cause analysis.

When failures begin shortly after a deployment or configuration change, xrelia automatically associates those events with the change timeline and highlights them as likely contributing factors.

This allows operators to quickly answer not only “Is the service unhealthy?” but also “Did a recent change likely cause it?”