Skip to main content

​
Settings Status: read incident timelines and SLA attestation

Open Settings → Status (/settings/status) when you need to answer a short-term operational question for your organization: is a declared platform incident affecting one of our channels, and what does the incident timeline say right now? The page is an organization-scoped read of the declared incident feed. It is separate from the monthly uptime rollup in Settings → Reliability. Owners and admins can read the organization-scoped detail. Viewers can open the Status surface in read-only mode; the page never lets a tenant declare, edit, or acknowledge a platform incident.

​
1. What the Status surface publishes

The Status surface publishes three related views:
  • Per-channel availability. Each channel your organization uses is mapped against declared platform incidents. A channel with no traffic and no declared incident is not presented as verified uptime; it is not measured.
  • Incident timeline. Active and recently resolved incidents show their severity, affected component, current state, and timestamped updates. Read the timeline to distinguish an incident that is still being investigated from one that is being monitored or resolved.
  • The verify pipeline. The page verifies the published incident record, maps its declared component to your organization’s channel set, and then derives the organization view from that result. This keeps an unrelated component out of your history while retaining platform-wide incidents. It is a read-time projection of the published feed, not a tenant-local health probe.
The page’s incident states follow the published progression: Investigating, Identified, Monitoring, and Resolved. A maintenance notice or informational notice can appear in the feed, but scheduled maintenance and informational notices do not count as downtime in availability calculations.

​
2. Map a marked incident to your tenant’s view

Start with the incident’s affected component and severity, then check whether that component maps to a channel your organization uses:
  1. Open Active now and select the incident that overlaps the time your channel changed.
  2. Compare the affected component with the channel list shown for your organization. A video-only incident, for example, does not appear in the organization history for a tenant that uses only SMS and email.
  3. Read the incident updates and the impact badge together. The timeline tells you what the platform has confirmed; the badge tells you the incident’s severity class.
Severity rolls up worst-first. A channel touched by a critical incident is reported as critical even if another overlapping record is minor. Major and minor incidents likewise roll up above normal operation, while informational notices do not reduce availability. Overlapping windows count once in the availability calculation, so the same minutes are not deducted twice. A platform-wide incident maps to every channel. A component-scoped incident maps only to the channels represented by that component. If an incident does not map to any channel in your organization, it does not explain a tenant-level change and will not appear in the org-scoped history.

​
3. Status or Reliability?

Use the surface that matches the question: Reliability is the monthly uptime rollup. It combines declared incident windows with your organization’s outbound message outcomes, exposes the per-channel availability and delivery-health rows, and can export the completed period as CSV. Read Settings Reliability: the monthly uptime rollup for the drill-down and response steps.

​
4. SLA attestation: does it exist, and what does it show?

Yes. The SLA attestation is the organization-level monthly statement behind the same availability derivation. It is available to authenticated members through GET /api/v1/reports/sla-attestation; choose a calendar month with the month=YYYY-MM parameter, or omit it to use the most recent complete month. The attestation shows:
  • the attested month and its exact UTC window;
  • overall platform uptime and de-duplicated downtime minutes;
  • delivery rate for each channel, using terminal outbound messages as the denominator; and
  • the support_sla block, which reports first-response and resolution SLA attainment for digital conversations.
A null channel delivery rate means there was no terminal traffic, not zero percent delivery. Likewise, a month with no measured channel is not silently turned into 100% uptime. The attestation and Reliability report use the same read model, so a month selected in either surface should produce the same availability and delivery figures. For formulas, CSV export, and claim handling, see Monthly SLA and availability report and the SLA attestation model.

​
5. If a channel is degraded, check Status first

When a channel suddenly behaves differently, first open Settings → Status and look for an active incident that maps to that channel. Read the newest update and its affected-component scope before changing routing or retrying traffic. A declared incident gives you a platform explanation and a timeline for the next update. If Status has no matching incident, do not treat the absence as proof that the channel is healthy. Check Reliability for the channel’s delivery-health row, then open the delivery log and inspect recipient, sender, provider, and wallet failures. Delivery success is your traffic’s outcome; it can degrade while platform availability remains 100% because of invalid recipients, unregistered senders, filtered content, carrier rejection, or insufficient balance.

​
See also