# SLA & Health

> Real-time platform health, active incidents, scheduled maintenance, and your partner SLA tier via GET /sla. Drive in-app status banners and alert users when market data or order execution is degraded. Incident severity P0–P3 explained.

Real-time platform health status, active incidents, scheduled maintenance windows, and your partner
SLA tier. Use it to drive status banners in your app or alert users when market data or order execution
is degraded.

## Service health

<MethodTag m="GET" /> `/sla`

Returns overall platform health, any active incidents with severity and affected services, upcoming
maintenance windows, and your SLA tier entitlements. Incidents are also broadcast via the
`incident.declared` and `incident.resolved` webhooks.

Public status-page consumers can call `GET /api/v1/status` without partner credentials. It returns
service health, active incidents, recent resolved incidents, and maintenance windows with public cache
headers, while authenticated partners continue to receive incident webhooks and SSE events.

## Published service objectives

SLOs are measured per calendar month from MyStocks server-side request and service-health telemetry. A successful API request is one that reaches the service and returns a non-`5xx` response; partner authentication, validation, rate-limit, market-closed, and insufficient-funds responses are not service failures.

| Tier | Monthly availability | 30-day error budget | P0 acknowledgement |
| --- | ---: | ---: | ---: |
| Standard | 99.5% | 216 minutes | 30 minutes |
| Professional | 99.9% | 43.2 minutes | 15 minutes |
| Enterprise | 99.95% | 21.6 minutes | 5 minutes |

For GA certification, authenticated non-streaming API traffic must sustain p95 response latency of at most 1 second and an error rate of at most 0.1% under the approved load profile. Regional failover recovery must complete within 60 seconds. Live market-order execution has a separate five-minute operational target while the relevant exchange is open; it is not an HTTP latency metric.

Planned maintenance announced at least 72 hours in advance, partner-side failures, exchange closures, and force-majeure upstream outages are reported separately. They are excluded from service-credit calculations only where the signed partner SLA explicitly permits it. Error-budget exhaustion freezes non-essential releases until reliability has recovered or an authorized exception is documented.

## Order operations and execution expectations

An API acknowledgement is not an execution confirmation. A successfully accepted
order enters `PENDING` and may remain there while the dealing team validates market
status, buying power, restrictions, and the available execution venue. Build partner
interfaces around the webhook-driven lifecycle rather than assuming an immediate fill.

| Event | Published objective | Source of truth |
| --- | --- | --- |
| API acknowledgement | Within the API latency objective above | HTTP response and request ID |
| Order review during an open supported session | Five-minute operational target | Order status and execution webhooks |
| Market closed or outside the supported dealing window | Held, rejected, or expired under the documented order policy | `GET /market/status` and order lifecycle |
| Material service degradation | Incident acknowledgement by contracted tier | Public status and incident webhooks |
| Reconciliation exception | Investigated before the next controlled-production trading window | Reconciliation report and support case |

Exchange sessions, holidays, early closes, and settlement dates vary by market.
Use `GET /market/status`, `GET /market/holidays`, and `GET /market/settlement`
instead of hard-coding local hours. A signed enterprise SLA can add named dealing
coverage and escalation contacts; it does not turn a pending acknowledgement into
a guaranteed fill.

For an order that exceeds the published objective, open a support case with the
order ID and `X-Request-ID`. Do not submit a duplicate order. The support severity
depends on customer impact and whether the relevant exchange is open.

```bash
curl "https://mystocks.africa/api/v1/partner/sla" \
  -H "Authorization: Bearer pk_live_<key>"
```

```json
{
  "status": "OPERATIONAL",
  "tier": "starter",
  "incidents": [],
  "maintenance": [{ "id": "mnt_abc123", "title": "NGX data feed upgrade", "scheduledStart": "2026-06-15T02:00:00Z", "scheduledEnd": "2026-06-15T04:00:00Z", "affectedServices": ["market-data"], "status": "SCHEDULED" }],
  "services": [
    { "name": "Market Data", "status": "OPERATIONAL" },
    { "name": "Order Execution", "status": "OPERATIONAL" },
    { "name": "Webhooks", "status": "OPERATIONAL" },
    { "name": "Sub-Accounts", "status": "OPERATIONAL" }
  ],
  "checkedAt": "2026-06-09T10:00:00Z"
}
```

## Incident severity levels

| Level | Name | Impact |
| --- | --- | --- |
| `P0` | Critical | Full platform outage — all trading and market data unavailable. |
| `P1` | Major | Core service degraded — order execution or market data impaired. |
| `P2` | Minor | Partial degradation — some exchanges or endpoints affected. |
| `P3` | Informational | Maintenance or cosmetic issue with no user impact. |