Skip to main content

SLA and incident response

Mnemom’s availability commitments scale with plan tier. The free tier is best-effort; paid tiers carry contractual targets, with Enterprise escalating to custom terms. This page documents the public position. The authoritative numbers for any given contract live in the MSA and its SLA exhibit.
A public status page is live at status.mnemom.ai. It shows per-service operational state and 90-day uptime history. Incident communications go through the status page and email (for contractual customers).

Uptime targets by tier

Uptime is measured monthly against the gateway control plane — the endpoints under api.mnemom.ai/v1. Data-plane components in the Safe House (front-door checkpoint, back-door checkpoint, AIP) inherit the control-plane target; when the gateway is up, enforcement is up.
TierMonthly uptime targetMonthly error-budget equivalent
Free / OpenClawBest-effort — no SLA
Developer99.9%~43 minutes
Team99.95%~22 minutes
Enterprise99.99% target, contract-specific~4 minutes
Scheduled maintenance is excluded from uptime calculation on Developer and Team tiers with at least 72 hours advance notice. Enterprise contracts negotiate maintenance windows individually. Emergency security patches are never excluded. Measurement basis. Uptime is computed as (total minutes in the month − unavailable minutes) ÷ total minutes. A minute is “unavailable” when the synthetic monitors that exercise the public API return a non-success status from at least two geographic probes simultaneously.

Recovery objectives

TierRTO (target restore time)RPO (max acceptable data loss window)
Free / OpenClawBest-effortBest-effort
Developer4 hours1 hour
Team1 hour15 minutes
Enterprise15 minutes, contract-specific5 minutes, contract-specific
RTO and RPO apply to the control plane (dashboard, API, Supabase-backed state). Proof-chain commitments (Tier 1) are hash-chained and append-only — once anchored, they are not lost even under full-region failure; they become temporarily unretrievable, not corrupted.

Incident severity

Incidents are classified on declaration and re-classified as facts change.
SeverityDefinitionFirst notification target
SEV-1Full outage of the gateway or dashboard, OR a confirmed data exposure, OR a canary leak indicating agent compromise for any Enterprise customer.≤ 15 minutes
SEV-2Partial outage (single endpoint class, single region), OR degraded performance > 3× baseline latency, OR enforcement falling back to observe mode.≤ 30 minutes
SEV-3Background job failures (billing, observer, async AIP / back-door checkpoint) that do not affect synchronous enforcement or dashboard access.≤ 2 hours
SEV-4Cosmetic or minor functional degradation.Next business day
SEV-1 and SEV-2 invoke the on-call runbook within minutes of detection; remediation and communication run in parallel.

Incident communication

Who hears what, when, and through which channel.
AudienceChannelFirst updateCadence
All customersStatus page≤ 30 minutes after SEV-1/SEV-2 declarationEvery 30 minutes until mitigated, then on resolution
Enterprise contract contactsEmail to the designated security / operational contact≤ 15 minutes after SEV-1 declarationEvery 30 minutes until mitigated, then on resolution and at post-mortem
Team plan customersEmail to the primary org owner≤ 30 minutes after SEV-1/SEV-2Every hour until mitigated, then on resolution
Developer plan customersStatus pageSame as all-customers cadenceSame
Free / OpenClawStatus pageBest-effortBest-effort
Security-impacting incidents (confirmed exposure, canary leak, credential compromise, supply-chain event) also trigger:
  • Dashboard enforcement-mode downgrade notice if Safe House falls back to observe mode during the incident.
  • Breach-notification support for customers with a regulator obligation under GDPR Article 33, HIPAA Breach Notification Rule, or sector-specific law. Mnemom provides the timeline, technical detail, and attestations needed for the customer’s notification; the customer is the reporting party. See Compliance — shared-responsibility boundaries.
Post-mortems are published within 5 business days of SEV-1 resolution for Enterprise customers (private, under NDA) and within 10 business days of SEV-1 resolution for all customers in summary form.

How customers reach us

NeedWhere to send it
Suspected security vulnerabilityEmail [email protected] (PGP key available on request). For the open protocol repos you may also file a GitHub Security Advisory: aap, aip. Do not file public issues. See SECURITY.md.
Active incident affecting your trafficDashboard → SupportIncident (SEV-1/SEV-2 tag). Enterprise customers use the dedicated incident email on file.
Regulator-driven breach-notification assistanceYour Enterprise account owner or [email protected].
Non-urgent product or billing questionDashboard → SupportQuestion.
Responsible disclosure is acknowledged within 48 hours; fix or mitigation target is 7 days for high-severity findings.

Status page

status.mnemom.ai is live and publishes:
  • Current operational state for each service (gateway, dashboard, proof-chain anchoring) per region.
  • Active incidents with a live update log.
  • 90-day uptime history.
Scheduled maintenance windows are announced on the status page in advance. Contractual customers also receive email notification per the incident communication table above.

SLA credits

Enterprise and Team contracts include SLA credits against the subscription fee when monthly uptime misses the contractual target. The credit schedule is in the MSA’s SLA exhibit; typical structure:
  • Below target but ≥ 99.0%: 10% credit on the monthly subscription.
  • Below 99.0% but ≥ 95.0%: 25% credit.
  • Below 95.0%: 50% credit.
Credits are applied to the next invoice after the customer raises the claim with evidence. Free and Developer tiers do not accrue credits.

See also

  • Launch SLOs & Deferrals — Per-scenario SLO commitments (S1–S10) and the explicit deferral list
  • Compliance posture — Regulatory status and shared-responsibility boundaries
  • Safe House — the per-customer perimeter the uptime target covers
  • AEGIS — the cross-tenant Protection Network and its published SLOs
  • Managed Rules — the signed rule pipeline whose propagation latency is published as an SLO
  • Observability — Customer-side signals for detecting degradation early
  • API reference overview — Error codes, rate limits, and timeouts

AEGIS SLO commitments

AEGIS publishes Protection-Network SLOs at /trust/slos:
SLOTarget
Managed Rule propagationP95 ≤ 30 seconds (target; first 30-day window publishes 30 days post-GA)
Rule-set freshness under normal operationP99 ≤ 5 minutes
Failover availability99.99%
Staleness alert threshold24 hours (P0 page)
The KV → R2 → in-isolate read pipeline + the three independent signing chains (RECIPE_PROMOTION_SIGNING_KEY, RECIPE_KV_SIGNING_KEY, RECIPE_R2_SIGNING_KEY) are the mechanisms behind these commitments. See Managed rule envelope schema for the failover behavior and alert tags.