Service status, SLA and maintenance

Check the status

Two public, anonymous probes with no customer data, based on the service's own health checks. They answer at the root of the API host (they do not hang off /api/v1):

Probe	What it checks	Use it for
GET /health/live	The process responds. It does not touch the database, cache or queue.	External uptime monitors.
GET /health/ready	Database, cache and message bus. The result is cached for a few seconds.	Knowing whether dependencies are operational.

/health is an old alias of /health/ready.

curl -i https://<api-host>/health/ready
# HTTP/1.1 200 OK
# {"status":"Healthy","checks":{"Database Connection":{"status":"Healthy","duration":"3"},"Cache":{...}},"totalDuration":"6"}

• status is Healthy, Degraded or Unhealthy. With Unhealthy the HTTP code is 503; otherwise 200.
• The response includes only each check's status and duration, never descriptions or exceptions.
• Do not probe more than once a minute from a single monitor.
• An isolated 503 is not an incident; alert after several consecutive failures (recommended: 3 in 3 minutes).

Availability SLA per plan

Monthly availability target for the API and outgoing webhooks:

Plan	Monthly availability	Maximum downtime per month
Starter	99.5 %	≈ 3 h 36 min
Growth	99.9 %	≈ 43 min
Enterprise	99.95 %	≈ 21 min
Custom	99.99 %	≈ 4 min

How it is measured. Percentage of minutes in the calendar month in which GET /health/ready answers without Unhealthy, measured from outside our infrastructure. Excluded: scheduled maintenance under the policy below, failures of your network or your integration, force majeure and the API's own limits (429 for quota or burst).

Webhooks. Events that are not delivered because of an outage on our side are retried as described in Webhooks; an outage on your side does not count against the SLA.

The percentages in this table are those of the current commercial rate. Compensation for breaches (service credits) and any additional commitment are set in your contract; if they differ, the contract prevails.

Maintenance windows

Type	Notice	When	Expected impact
Scheduled	At least 7 days ahead, through the changelog and email to the account administrators	Outside European business hours (preferably between 01:00 and 05:00 UTC)	Brief interruption; the API may answer 503 with Retry-After.
Urgent (security or stability)	As much as possible, with no minimum period	When needed	Still communicated, and it does count towards the SLA if it exceeds what was announced.

Usual deployments are blue-green and need no window. Compatible changes described in the versioning policy are never treated as maintenance.

What your client should do

• On 503 or 429, retry with exponential back-off and respect Retry-After.
• Use Idempotency-Key on writes so you can retry without duplicating.
• Verify webhook signatures and deduplicate by the X-IncentIA-Idempotency-Key header: during maintenance they may arrive late.