As of September 06, 2026, the iflytek AI API responds in 258 ms p50 (edge, time-to-first-byte) from Asia (Tokyo) — its fastest measured region — with 99.3% uptime. Slowest is South America (São Paulo) at 653 ms p50.
Is iflytek down right now?
Reachable from all 4 regions
Last successful probe Sep 6, 17:15 UTC · every 5 minutes from 4 region(s)
On Sep 4, 13:46 UTC host probes failed from 2 of 4 regions — but 3 other provider(s) failed in the same minutes. A cause shared by several unrelated APIs sits above any one of them, and our data cannot say whose it was, so iflytek is not blamed for it. Measured from outside iflytek’s own network, independently of its status page; full log: measured AI API incidents.
Real requests: not measured for iflytek — only the API host is probed here, so errors limited to specific models are invisible to these probes. That is exactly what a status page tends to report, hence the line below.
iflytek publishes no machine-readable status page, so there is nothing to cross-check against.
Edge latency, 24 h
258 ms
p50 from Asia (Tokyo), the fastest region
Uptime, 24 h
99.7%
1,151 probes across 4 region(s)
Failed probes, 72 h
47
of 3,455 · Europe (Germany), US (Central), Asia (Tokyo), South America (São Paulo)
Reported by iflytek, 72 h
—
no machine-readable status page
Was iflytek down in the last 3 days?
Not attributably. 2 multi-region failure(s) coincided with other providers failing in the same minutes, so the cause sits above any one of them.
South America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · at least 5 minutes · 2 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · at least 15 minutes · 3 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · at least 5 minutes · 2 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Asia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
What iflytek’s own status page reported
iflytek publishes no machine-readable status page, so there is nothing to set against the measurements above.
Is iflytek getting faster or slower?
Right now iflytek is slower than usual from Europe (Germany): 398 ms against a three-day typical of 302 ms.
hourly p50 latencyall probes succeededsome probes failedhalf or more failedno data
One panel per region: the line is the hourly p50 edge latency (shared scale, ms), the strip beneath it is the outcome of that hour’s host probes. Hover any hour for the numbers. Flat is good; a rising line means the endpoint is slowing down from that origin, a gap means no probe succeeded in that hour.
How fast is the iflytek API from each region?
Region
p50 TTFB
p95
Uptime
Asia (Tokyo)
258 ms
1361 ms
99.3%
Europe (Germany)
301 ms
751 ms
100%
South America (São Paulo)
653 ms
1539 ms
99.7%
US (Central)
445 ms
1109 ms
100%
Measured from Asia (Tokyo), iflytek responds in 258 ms; from South America (São Paulo) the same API takes 653 ms — 2.5× longer for an identical request. That difference is the network path, not the model, and it applies to every call you make.
What is actually being measured here?
A probe in each region opens a real connection to iflytek’s own API host every five
minutes and times DNS resolution, the TCP handshake, the TLS handshake and the first byte of the
response. Nothing is routed through a gateway or aggregator, so these figures describe
iflytek’s infrastructure rather than a reseller’s. Uptime counts a probe as failed only when the
service genuinely fails — a 401 from an unauthenticated probe means the endpoint answered
correctly and is counted as up.
What this page does not tell you
These are edge latency numbers: the time before the model begins generating. They
say nothing about answer quality, throughput, price, or how long a full completion takes — those
depend on the model you call. Edge latency matters because it is unavoidable: it is paid on every
request, before a single token exists, and no prompt engineering removes it. Where an API key is
available, inference time-to-first-token is measured separately and shown on the region pages with the
model named next to the figure. Likewise, an unauthenticated probe cannot see errors that hit only some
models or some accounts — the kind a status page usually reports — which is why iflytek’s
own reports are shown next to the measurements rather than folded into them.