Service level objectives

Tessera defines its reliability targets as measured service level objectives (SLOs). Each SLO is computed from production telemetry, evaluated continuously, and defended with multi-window burn-rate alerting — the platform team is paged when the error budget is burning fast, long before a monthly target is breached.

SLO	Target	Window	Measured as
API availability	99.9%	30 days	Non-5xx responses returned at the public load balancer across the REST API (api.staging.tessera.zone) and the serving read API, including failures before an application instance is reached
Ingest availability	99.95%	30 days	Non-5xx POST /v1/events responses at the public load balancer and durable enqueue after acceptance (enqueue failures after acceptance count against this budget)
Event → state latency (p95)	≤ 2 seconds	28 days	Time from a streamed event's arrival to the updated entity state (embedding + scores) being readable, for slots with real-time scoring¹

¹ Real-time (streaming) scoring is generally available in a later phase; until then this SLO applies to preview deployments only.

What these mean for you

• Error budgets, not perfection. A 99.9% / 30-day SLO allows roughly 43 minutes of full unavailability per month. We spend that budget carefully: deploys stop when the budget is burning.
• Acceptance is durable. Ingest acceptance (202-style per-item results) means the event is enqueued to durable storage, not merely received. The ingest SLO is stricter than the API SLO for exactly that reason.
• Retries are safe. All ingestion is idempotent (event_id dedup + Idempotency-Key), so a client's retry-on-5xx never duplicates data and does not reduce your effective availability.
• Freshness is visible. Every state read returns event_cursor and computed_at, so you can measure staleness end-to-end yourself.

How they are enforced internally

Every service ships a standard RED dashboard (rate, errors, duration) and a saturation row generated from one service registry; alert rules are promtool-tested in CI, and every alert routes by severity (page or ticket) and links a runbook. Burn-rate policy: a page fires at 14.4× budget burn (1 h and 5 m windows both burning), a ticket at 6× (6 h and 30 m). A continuous log-scanning guard additionally proves that customer attribute values never appear in service logs.

Public availability is measured at the external load balancer—the point where customers receive a response—so routing, endpoint-selection, and connection failures count even when application RED telemetry has no request to record. Application metrics remain the route-level diagnostic view.

Status and incident history: see the status page (docs.staging.tessera.zone/status).