Appearance
Scale & SLOs
Capacity notes for the managed Evitrus cloud on evitrus.io. Closed beta is a single-region, small footprint stack — not a 50M-events/month reference deployment. Numbers below are what we commit to today; larger scale is a capacity project, not a silent assumption.
Environments
| Environment | Role | Topology (today) |
|---|---|---|
| Managed cloud | Customer SaaS on *.evitrus.io | Single Kubernetes cluster, single-node ClickHouse, Postgres for identity |
There is no separate “largest customer” public figure yet — beta traffic is well below plan caps.
Soft capacity (what the product enforces)
| Limit | Free | Basic | Enterprise |
|---|---|---|---|
| Included events / month | 10 000 (hard cap) | 50 000 | 300 000 |
| Retention | 14 days | 730 days | 730 days |
Per-request export (GET /events/export) | 50 000 events max | same | same |
Optional per-key and per-org hourly rate limits can be set in the product (leaky bucket). When unset, ingest is not artificially throttled beyond plan monthly quotas and process resources.
Availability
These are targets for the managed API, not contractual guarantees yet.
| Class | Target | Error budget (30d) | Notes |
|---|---|---|---|
POST /ingest, GET /ingest/config | 99.95% | ~22 min | Own Deployment; 202 after durable ClickHouse write; does not wait for correlate/evaluate |
POST /compliance/evaluate | 99.5% | ~3.6 h | Own Deployment; customer evaluators fail-open on 5xx/timeout |
Identity (login, invite, keys) is the same availability class as Evaluate. A Postgres blip must not 5xx ingest for already-cached API keys (in-memory TTL; stale cache is served if Postgres errors after a successful lookup).
Burn-rate alerts and load tests are scoped to /ingest and /ingest/config only. Evaluate 5xx must not consume the ingest error budget.
Latency targets (working SLOs)
These are targets for the managed API, not guarantees in a contract yet. Measured server-side at the ingest / query handlers under normal beta load.
| Path | Target (p95) | Notes |
|---|---|---|
POST /ingest (≤100 events) | < 100 ms | Accept + append to ClickHouse; 202 after durable write; does not wait for correlation |
GET /changes and GET /events (one page) | < 100 ms | Time window + keyset cursor; limit default 100 / max 1000 |
| Change projection lag | < 2 s | Ingest 202 → Change visible on /changes; async consumers only |
POST /compliance/evaluate | < 100 ms typical; CPU-bound | Runs the engine now (same function as the live worker); 409 on deny |
GET /evaluate | < 100 ms | Last stored verdict for the UI |
Events are write-visible on 202 (GET /events). Changes are a projection and may lag by up to the projection SLO. If the correlator is behind, POST /compliance/evaluate still derives the Change from events.
What we do not claim yet
- Sustained events/sec at 50M+/month — not load-tested publicly
- Multi-AZ ClickHouse HA or cross-region read replicas
- Unbounded (unpaginated) search over a whole tenant
Rough ingest throughput
On the current single-node ClickHouse and API pod sizing used for the managed cloud, we expect comfortable sustained ingest on the order of tens to low hundreds of events per second for mixed exporter traffic, assuming payloads stay near the documented Evidence Event shape. Bursts above that may queue at the client or hit HTTP timeouts — exporters should retry with backoff.
Treat this as an order-of-magnitude guide for beta sizing, not a marketing benchmark. Ask for a load-test window if you need a written Enterprise capacity plan.
When you outgrow MVP
- Raise plan / usage-based billing (monthly allowance).
- Use export + windowed pulls if you need offline archives.
- For Enterprise: dedicated capacity review (CH sizing, rate limits, CMEK — see Security & residency).
Last updated: 2026-09-17. We will revise this page when prod HA topology ships or when we publish measured load-test results.