A vendor-neutral standard for machine-readable operational state of web services.

Every web service exposes health checks differently. Spring Boot returns {"status": "UP"}. Kubernetes probes expect a 200. The IETF health check draft uses {"status": "pass"}. Your custom endpoint returns {"healthy": true}. Monitoring systems, load balancers, and orchestrators all interpret these differently — or don't interpret them at all.

There is no common model for what "operational state" means across systems.

Open Operational State provides a canonical semantic model that any health check, readiness probe, or status endpoint can be interpreted through — without requiring systems to change their existing endpoints.

npm install @open-operational-state/parser @open-operational-state/emitter

import { parse } from '@open-operational-state/parser';

// Automatically detects Spring Boot, IETF draft, plain HTTP, or native format
const snapshot = parse( { contentType, body, url, httpStatus } );

console.log( snapshot.condition );  // 'operational' | 'degraded' | 'down'
console.log( snapshot.profiles );   // ['health']

Or validate a live endpoint from the command line:

npx @open-operational-state/validator probe https://your-api.com/health

The standard is built around a six-layer extensible architecture:

1. Core Model — stable, transport-agnostic semantics for operational state
2. Profiles — domain-specific specializations (Liveness, Readiness, Health, Status)
3. Serializations — wire-level JSON representations, decoupled from meaning
4. Adapters — bridges for existing formats (plain HTTP, draft-inadarei, Spring Boot)
5. Discovery — how monitors locate operational-state resources
6. Capabilities — what a target supports and how to negotiate interaction

New to the project? Read in this order:

1. Architecture — the six-layer model explained
2. Core Model — the semantic foundation everything builds on
3. Condition Vocabularies — the locked vocabulary values and ecosystem mapping

• Read the Contributing Guide
• Review the Code of Conduct
• See Support for help channels

No. Open Operational State does not replace existing health check or status endpoints. It provides a model that can interpret and normalize responses from existing endpoints through adapters.

No. The project builds on prior work including the Health Check Response Format for HTTP APIs (draft-inadarei-api-health-check) and the Service Status Resource Format for Web Services (draft-dallariva-web-service-status-json). It is compatible with both and can normalize responses that follow either format. See Prior Art for details.

Because existing systems already use different formats. This standard provides a unifying semantic layer that allows them to coexist while being interpretable through a common model.

The standard can interpret Kubernetes liveness and readiness probe semantics. The condition vocabulary includes explicit mappings for Kubernetes concepts. However, the standard is not Kubernetes-specific — it applies to any web service.

Specification and governance documents are licensed under CC BY 4.0. Code is licensed under Apache 2.0.