Some systems degraded

We post an incident as soon as we detect customer-visible degradation, even if we are still investigating the cause. Every incident is closed with a public summary describing what broke, what was affected, and what we are doing to prevent recurrence.

Severity

• Minor — partial degradation, error rates elevated, no customer-visible outage.
• Major — a core feature is impaired for a subset of projects (for example, evaluations degraded or failing open).
• Critical — service-wide outage, sustained data loss risk, or security incident.

What we monitor

• Gateway health, evaluation latency, daily budget usage, degraded evaluations.
• Dashboard response time, auth, and billing webhook delivery.
• Website and documentation availability.
• Rate-limit Redis connectivity and fail-open behavior (see Redis failover runbook).

What we do not monitor

• Request payload contents — there are none to see.
• Customer application code or database schema.
• Cross-region failover timing — we operate a single region at launch.
• Third-party hosts (Neon, RDS, Railway) — we surface their incidents but do not own them.

Service-level commitment

Brume is in soft launch. We do not publish an uptime SLA yet. We publish a public benchmark with workload, hardware, and latency methodology, and we track our own internal SLOs against that benchmark. Once we have six months of measured uptime history, we will publish a target SLO backed by the data.