Reliability Policy

Last updated: April 21, 2026 · Version 1.1

This is a public reliability policy, not a contractual Service Level Agreement. It describes the targets ROAM Intelligence operates against, how we communicate during incidents, and the support response you can expect on each plan. Contractual SLAs with service credits are not offered in our current product tier; Partner customers who require one should contact partners@roamintelligence.com.

1. Uptime target

We target 99.5% monthly uptime for the ROAM web app, the public API, the persecution map ingestion pipeline, the Ezekiel AI assistant, and outbound webhooks. "Uptime" means the service is reachable and returning successful responses for the majority of authenticated requests over a calendar month.

Real-time component health is published on our public status page. Historical uptime is visible there as well.

Internally we track tighter component-level Service Level Objectives (e.g. p95 latency targets for individual API endpoint families and first-token latency for the Ezekiel assistant) so that the 99.5% headline above is met even when one surface is misbehaving. Those internal targets, their measurement windows, and their error-budget burn-rate alerts are summarised on the admin Health Strip and reviewed quarterly.

2. Status page

Our status page lives at status.roamintelligence.app and tracks the following components independently:

Web app — the dashboard, map, and account UI.
API — the public REST API at /api/v1.
Map ingestion — the background pipeline that pulls from upstream sources (ACLED, ReliefWeb, X, ICC, AlertMedia, State Dept. advisories, etc.) and refreshes the incident map.
Ezekiel — the AI assistant and chat surfaces, including widgets and Slack/Teams bot.
Webhooks — outbound delivery of alert events to customer-configured endpoints.

You can subscribe on the status page itself to receive email or SMS notifications when we open, update, or resolve an incident on any component.

3. Incident communication cadence

During a confirmed incident affecting any component above we commit to the following posting cadence on the status page:

Initial post within 1 hour of confirming a customer- facing incident, identifying the affected component(s) and a brief description of impact.
Updates at least every 2 hours while the incident is open, even if the only update is "still investigating — no new information."
Postmortem within 5 business days of resolution for any incident classified as "major" (multi-component outage, data loss, or security event). The postmortem is posted to the status page and linked from the resolved incident.

Lower-severity events (single-component degradation under 30 minutes) are posted on the status page but do not require a written postmortem.

4. Data freshness target

Persecution incidents from automated upstream sources are targeted to appear on the map within 15 minutes of being published by the upstream source. Manually verified incidents (those promoted by an analyst from the verification queue) typically appear within 1 hour of verification.

Sustained ingestion lag beyond these targets is treated as a Map Ingestion incident and posted on the status page.

5. Security and breach notification

If we discover or are notified of a security breach affecting customer data, we will:

Notify affected customers by email within 72 hours of discovery.
Post a Security incident to the status page describing the scope and the components affected, redacted as necessary while investigation is ongoing.
Provide a written incident report to affected customers within 14 days of resolution, including timeline, root cause, data categories involved, and remediation steps.

Partner-tier customers operating under our Data Processing Agreement receive the additional notice and cooperation rights described in that document.

6. Support response targets

Initial response targets (first human reply, business hours Mon–Fri, US Eastern), measured by support tier:

Free — community support and documentation; best-effort email reply.
Core — email support, 2 business days.
Team — email support, 1 business day.
Partner — email and Slack Connect support, 4 business hours for normal requests, 1 business hour for confirmed production-down incidents on a Partner-tier deployment.

Support requests are submitted via the Contact & Support page or, for Partner customers, your dedicated Slack Connect channel.

7. Scope and limits

The targets above are operational commitments, not a contractual guarantee. They explicitly do not include:

Outages caused by upstream third-party data providers (ACLED, ReliefWeb, OpenStreetMap, OpenAI, Stripe, WorkOS, our cloud host, etc.).
Scheduled maintenance windows announced at least 24 hours in advance on the status page.
Force majeure, internet routing failures outside our control, or customer-caused incidents (e.g., expired DNS, exceeded spend cap, revoked OAuth tokens).

We update this policy as the service matures. Material changes are announced on the status page and via email to billing contacts at least 30 days before they take effect.

8. Questions

Reach us at partners@roamintelligence.com for Partner-tier reliability questions, or via the Contact & Support page for general inquiries.