How availability is calculated

There is no service-level agreement

MNS does not publish a contractual service-level agreement (SLA) for API Mall or any API on it, anywhere. Every figure on this status page - the daily strip, the 24-hour/7-day/30-day/ 90-day percentages - is informational only. It describes what our monitoring observed; it is not a commitment, and it creates no entitlement to a credit, refund or any other remedy. We track internal reliability objectives privately, and we do not publish them, precisely so that an internal target is never mistaken for an external promise.

What counts as downtime

Every measured second of a component's history falls into exactly one of six categories. Four of them come from the same six-status vocabulary shown on the front page; two more - planned maintenance and unmeasured time - are handled as follows:

• Operational and Degraded performance both count as available, in full. A slower response is not the same as no response, and counting it as downtime would make "degraded" meaningless as its own status.
• Partial outage counts as available at half weight. Part of the component was working and part was not, so neither "fully up" nor "fully down" describes it honestly; the weighting says so numerically instead of picking one.
• Major outage counts in full as downtime.
• Under maintenance is excluded from the calculation entirely - neither up nor down. Planned, announced work is not a fault, so it does not count against availability; how much time was excluded this way is always disclosed separately, never folded silently into the "available" total.
• No data (shown as an em dash, never as 0% and never as 100%) is excluded entirely. A period we did not measure is not evidence of anything, and guessing in either direction would be dishonest. This covers both a component that had not started being monitored yet and any gap in our own monitoring pipeline.

Put together: availability = (up + degraded + 0.5 × partial) ÷ (up + degraded + partial + major), with maintenance and unmeasured time removed from both the top and the bottom of that fraction before it is calculated.

When a problem is judged to have started

An outage's start time is the moment of the first failing check, not the moment enough consecutive failures had accumulated for us to be confident and raise an alert. We record that first-failure timestamp separately and always report the outage from it, specifically so that a real problem is never quietly shortened in the history books by however long it took us to notice it.

Detection takes a few minutes, by design

To avoid raising a false alarm on a single dropped request, a component is only marked as failing after several consecutive unsuccessful checks, run roughly a minute apart. In practice this means a genuine outage is typically confirmed and reflected on this page within about three minutes - not instantly. This is the same detection latency this page's own trade-off already accepts: a page that flips to red on every single transient blip would be less trustworthy, not more, and the true start time (see above) is preserved regardless of how long confirmation took.

What is excluded, and why

• Announced maintenance is excluded from the denominator, as described above, and is always disclosed as its own figure alongside any percentage it affects.
• A component's history only exists from the day monitoring for it began. A component being tracked for less than 90 days shows the days before monitoring started as no data, never as operational - the strip fills in over time and never fabricates a clean record for a period we were not watching.

Unknown time is disclosed, never counted as up

If our own monitoring has a gap - a missed check, a pipeline issue, a component newly added - that period is unknown, not operational. Where a meaningful part of a reported window was unknown, the percentage shown for that window is accompanied by a plain-language note stating how much of the window was actually covered, so a reader is never left assuming a number is more complete than it is.

How long we keep the data

• Raw probe results are kept for 30 days, after which only the pre-aggregated hourly and daily summaries remain.
• Hourly availability summaries are kept for 13 months.
• Daily availability summaries are kept indefinitely - there is no automatic deletion schedule for them.
• The public status page itself only ever displays the last 90 days of daily history.

Where the numbers come from

The figures on this page are calculated from our own recorded monitoring history, not estimated or approximated. Where a correction to that history is needed - a mis-classified diagnosis rule, a retroactively-declared maintenance window - the affected figures are recomputed from the underlying record, not hand-edited; published availability is never quietly changed without a trace of why.