The xrelia model
xrelia organizes reliability intelligence around nine core resources: Platforms, Services, Service Instances, Health Checks, User journey (synthetic requests), Metrics, Dependencies, Changes, and Incidents.
Platforms
Section titled “Platforms”A Platform represents a deployment context such as production, staging, preview, or development.
Platforms allow the same service to exist in multiple environments without mixing operational data. Health, incidents, alerts, and metrics are evaluated independently for each platform.
A service can have one or many service instances within a platform, and platform health is calculated from the health of those instances.
For example, the api service may have multiple production instances across regions and a separate staging instance, each monitored independently.
Services
Section titled “Services”A Service represents a logical application, API, worker, database, queue, or infrastructure component.
Services provide ownership, organization, and a unified view across multiple deployments. They aggregate health from all associated service instances and are the primary resource used for dashboards, alerting, and incident management.
Use services to represent the systems your team owns.
Typical services include a web API, an authentication service, a PostgreSQL database, a Redis cluster, or a background job processor.
Instances
Section titled “Instances”A Service Instance represents a specific deployment of a service on a platform, region, cluster, or infrastructure target.
Service instances are the resources that xrelia actively monitors. Health checks, synthetic requests, metrics, and dependencies are associated with individual instances, allowing xrelia to detect localized failures that may affect only one deployment.
For example, a production deployment in one region can become unhealthy while other instances of the same service remain healthy.
Use service instances to represent what is actually running in production.
Health checks
Section titled “Health checks”A Health check is a direct probe that verifies whether a service is reachable and responding correctly.
Health checks are the primary signal for availability. They can perform HTTP, HTTPS, TCP, DNS, or custom checks against your services and infrastructure.
A health check records whether the target succeeded, failed, timed out, or returned an unexpected response. xrelia uses these results to calculate availability and confidence.
Use health checks to answer a simple question: Is this service operational right now?
User journey
Section titled “User journey”Unlike a health check, which verifies basic availability, a User journey validates that critical functionality is working correctly. User journey is a collection of one or more synthetic requests.
A Synthetic Request simulates a real user interaction with your application.
It can perform authenticated requests, multi-step API flows, or complete user journeys.
Synthetic monitoring helps detect issues that infrastructure metrics cannot, such as broken authentication, failed checkout flows, expired certificates, or third-party API failures.
Use synthetic requests to answer: Can users successfully complete important actions?
Metrics
Section titled “Metrics”A Metric is a time-series measurement that describes the behavior or performance of a service.
Metrics can represent latency, request rate, error rate, CPU usage, memory usage, queue depth, database connections, or any custom application measurement.
xrelia stores metrics with timestamps and labels, then calculates aggregations such as averages, percentiles, and rolling windows.
Metrics provide the context needed to understand why a service became unhealthy.
Use metrics to answer: How is the service performing over time?
Dependencies
Section titled “Dependencies”A Dependency represents a relationship between one service and another system that it relies on.
Dependencies can be internal services, databases, message queues, cloud services, or external APIs. xrelia tracks dependency health separately and incorporates it into service confidence and incident analysis.
When a dependency fails, xrelia can identify which services are affected and estimate the potential blast radius of the failure.
Use dependencies to answer: What could cause this service to fail?
Changes
Section titled “Changes”A Change represents a deployment or configuration modification affecting a service instance.
xrelia tracks two types of changes:
Deployment changes, such as new releases, rollouts, restarts, or infrastructure replacements.
Configuration changes, such as environment variable updates, feature flag changes, routing changes, or infrastructure configuration modifications.
Changes are automatically correlated with health checks, synthetic requests, metrics, and incidents. When a service instance becomes unhealthy shortly after a deployment or configuration update, xrelia highlights that change as a likely contributing factor. Use changes to answer: What changed before this problem started?
Incidents
Section titled “Incidents”An Incident is a correlated operational event that represents a meaningful service disruption.
xrelia groups related failures from health checks, synthetic requests, metrics, and dependencies into a single incident. This prevents alert storms and creates a unified operational timeline.
An incident includes severity, affected services, impacted platforms, contributing dependencies, and the sequence of events that led to the disruption.
Use incidents to answer: What is broken, what is affected, and how did it happen?