Reliability commitment
We don't break your build.
ChangeSpec is an advisory layer. We surface information. We do not own your deployment gate. If our API is down, if we ship a bad update, if the feed is slow - your build runs, your deploy goes out, your IDE stays open.
This is a product commitment, not an aspiration. Every integration is engineered around it.
What we guarantee
Advisory by default. Blocking only when you ask.
The CLI exits 0 whether it finds zero issues or fifty. Blocking behavior - where a finding causes a non-zero exit - is behind an explicit --fail-on flag. It is never the default. We will never silently change this.
2 seconds in your IDE. 5 seconds in CI. Then we give up.
Every call from the MCP server or CLI has a hard wall-clock timeout. If we do not respond in time, the client falls back to cached data and moves on. You never wait longer than 5 seconds for ChangeSpec under any network condition.
One environment variable. Thirty seconds. Done.
CHANGESPEC_SKIP=1 disables all ChangeSpec network calls in every integration - CLI, MCP server, CI step. Nothing touches our API. Nothing hangs. Your pipeline runs clean.
We go down. You read from cache. Nothing breaks.
The CLI and MCP server keep a local cache of the last successful response. General change data is cached for 7 days. Security advisories are cached for 24 hours. When the API is unreachable, you read from cache with a staleness warning on stderr. Not stdout. Not an error.
Three failures. Circuit opens. Two minutes rest. We probe once.
After 3 consecutive failures to reach ChangeSpec, the client stops trying for 120 seconds. No retry storms. No hanging calls. After the cooldown, a single probe goes out. If it succeeds, normal operation resumes. If not, the cooldown resets.
Old versions keep working. Deprecation takes 12+ months.
We do not break old MCP server or CLI versions against the current API. When a version is deprecated, you get a warning on stderr for 12 months before anything changes. You upgrade on your schedule.
If something goes wrong: bypass in 30 seconds
If ChangeSpec is causing any friction in your workflow - for any reason - disable it completely with one variable.
export CHANGESPEC_SKIP=1
# Re-run your build or deploy. ChangeSpec makes zero network calls.
# Remove the export when the issue is resolved.# In your MCP server config, add to env:
{
"mcpServers": {
"changespec": {
"command": "changespec-mcp",
"env": { "CHANGESPEC_SKIP": "1" }
}
}
}
# Restart your AI coding environment.changespec check . --no-changespec
When bypass is active, the CLI exits 0. The MCP server returns { "status": "skipped" }. No network calls are made. No errors are surfaced.
SLO targets
These are targets, not contractual guarantees. We publish them so you can calibrate. We do not promise 99.99% at this stage. We design the clients to handle 99% so you never notice the remaining 1%.
| Metric | Target | Notes |
|---|---|---|
| API availability (monthly) | 99% | ~7h downtime/month tolerated by client cache |
| API p95 response time | < 500 ms | Well within 2s interactive timeout |
| Feed freshness (general) | < 1h from source | Events indexed within 1 hour of vendor publication |
| Feed freshness (security) | < 15 min from source | Security advisories prioritized |
| Health endpoint availability | 99.5% | Lightweight endpoint, separate from main API path |
| Status page availability | 99.9% | Independently hosted from main infrastructure |
Programmatic health check
Check ChangeSpec availability from your own tooling. The health endpoint returns machine-readable JSON.
curl https://api.changespec.com/.well-known/changespec-health{
"status": "ok",
"components": {
"api": "ok",
"feed": "ok",
"webhooks": "ok",
"mcp": "ok"
},
"feed_freshness": {
"last_event_at": "2026-04-16T10:00:00Z",
"lag_minutes": 12
},
"incidents": [],
"checked_at": "2026-04-16T14:00:00Z"
}
Status values: ok, degraded, outage. The endpoint always returns HTTP 200. Non-200 means the health endpoint itself failed - treat as status unknown.
A human-readable status page is planned.
Incident history
We publish an RSS feed of incidents so your own tooling can detect and respond to ChangeSpec degradation.
An incident history page and RSS feed are planned.
Under the hood
These commitments are specified in machine-readable form in the Integration Safety companion document to the ChangeSpec 1.1 specification. It includes MUST/SHOULD conformance language, timeout tables, circuit breaker reference pseudocode, cache file format, and 10 mandatory conformance test vectors for non-blocking behavior.