Chinese AI lab founded by Yang Zhilin (ex-Meta / Tsinghua / Recurrent AI). Builds Kimi, a long-context assistant pitched on multi-hundred-thousand-token windows and strong Chinese-language performance. Distributes through kimi.com (chat) and platform.moonshot.cn (API).
Components ranked by incident count. Click a row for the incident list. Down-time is attributed proportionally for multi-component incidents.
Component
Incidents
Down (attr.)
Median MTTR
Last
Score Breakdown
Uptime50%
49.7
Frequency20%
80.7
Severity20%
7.3
MTTR10%
94.2
SLA Compliance
How often does this provider clear their stated availability target?
Industry default (99.9%) · 99.90%
✕ last 14d98.18%-1.72%
Met SLA in 10 of 13 weeks (77%)
13 weeks on record
Method: a rolling quarter (13 weeks ≈ 91 days). Each cell is one 7-day slice of Statuspage-standard uptime (1 − (critical + 0.3 × major) / window; minors and maintenance excluded; red when the slice dips below the stated SLA).
Kimi — Incidents by Day last 14d
MinorMajorCritical
Total 15 incidents
0
3
6
9
12
04-2104-2304-2504-2704-2905-0105-0305-05
Worst Incidents
Ranked by severity-weighted duration (impact × wall-clock). Click any incident for the full update timeline.
Type of Failure
Categorised from the public incident headlines (outage / latency / auth / etc.).
Other
15
100%
When It Breaks
Incident starts by weekday × hour, UTC. Hover a cell for incident detail.
S
0
M
0
T
0
W
0
T
Thursday01:00–02:00 UTC
2incidents
2 critical
搜索功能报错Apr 23
搜索功能报错Apr 23
Thursday02:00–03:00 UTC
3incidents
3 critical
搜索功能报错Apr 23
搜索功能报错Apr 23
搜索功能报错Apr 23
Thursday03:00–04:00 UTC
3incidents
3 critical
搜索功能报错Apr 23
搜索功能报错Apr 23
搜索功能报错Apr 23
Thursday04:00–05:00 UTC
1incident
1 critical
搜索功能报错Apr 23
Thursday05:00–06:00 UTC
1incident
1 critical
搜索功能报错Apr 23
Thursday06:00–07:00 UTC
1incident
1 critical
搜索功能报错Apr 23
Thursday07:00–08:00 UTC
1incident
1 critical
搜索功能报错Apr 23
Thursday18:00–19:00 UTC
1incident
1 critical
搜索请求出现大量报错Apr 30
13
F
Friday06:00–07:00 UTC
1incident
1 critical
搜索请求出现大量报错May 1
Friday07:00–08:00 UTC
1incident
1 critical
搜索请求出现大量报错May 1
2
S
0
00
06
12
18
HOUR OF DAY · UTC15 incident starts · hover any cell for detail
Hottest hour
Thursday 02:00 3
Worst day
Thursday 13
Worst time of day
02:00–03:00 3
How fast they fix things
Distribution of resolution times alongside the 12-week trend so you can see whether they're getting faster or slower.
Typical fix
7m
half of incidents resolve faster
On a bad day
3h 58m
9 in 10 resolve faster than this
Distribution
<15m
9
15m–1h
2
1–4h
3
4–24h
1
24h+
0
+0 ongoing (not counted above)
MTTR Trend (12 weeks)
Are they recovering faster or slower over time? Lower is better.