What is the iflytek API's uptime?

Measured uptime for the iflytek API averages 99.8% across 4 region(s) over the last 24 hours.

Is the iflytek API down? Live status, latency & uptime by region

Last verified October 21, 2026 · rebuilt about every 30 minutes

Is the iflytek API down right now?

Reachable from all 4 regions

Last successful probe Oct 21, 22:16 UTC · every 5 minutes from 4 region(s)

25 isolated failure(s) in the last 72 hours, the most recent (host probes) visible from only one region (Asia (Tokyo)). A single-region failure cannot be separated from a problem on that network path, so it is not called an outage. 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.

As of October 21, 2026, the iflytek AI API responds in 229 ms p50 (edge, time-to-first-byte) from Asia (Tokyo) — its fastest measured region — with 99.7% uptime. Slowest is South America (São Paulo) at 649 ms p50.

Endpoint response (TTFB), 24 h

229 ms

Typical (p50) from Asia (Tokyo), the fastest region

Uptime, 24 h

99.8%

1,152 probes across 4 region(s)

Failed probes, 72 h

of 3,459 · 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?

No. 25 isolated single-region probe failure(s) were recorded, none of which meets the bar for an outage (two or more regions at once).

Oct 21, 15:21 UTCAsia (Tokyo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · [Errno 104] Connection reset by peer
Oct 21, 05:50 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 17:35 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 16:40 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 16:10 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 15:05 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 13:50 UTCAsia (Tokyo) only — not an outage · at least 5 minutes · 2 failed probe(s) · timeout
Oct 20, 12:55 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 12:35 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 04:25 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 02:35 UTCSouth America (São Paulo) only — not an outage · under one 5-minute probe cycle · 1 failed probe(s) · timeout
Oct 20, 01:55 UTCSouth America (São Paulo) only — not an outage · at least 15 minutes · 2 failed probe(s) · timeout

Earlier days with iflytek incidents: Oct 5 (1 outage) · Sep 29 (1 outage)

Show this live in your README: — embed code

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?

Endpoint response (TTFB) · milliseconds · lower is faster

Last 72 hours · UTC · newest time on the right · current hour is incomplete.

Each line shows a region’s typical response per hour (p50), using the same scale. A gap means no successful timed probe in that hour.

typical response per hour (p50)all probes succeededsome failed (under half)half or more failedno probes recorded

Probe counts by region

Europe (Germany): 0 failed / 858 endpoint probesUS (Central): 0 failed / 856 endpoint probesAsia (Tokyo): 3 failed / 856 endpoint probesSouth America (São Paulo): 45 failed / 856 endpoint probes

Chart details

The strip shows endpoint probe outcomes, not model-request success. Adjacent hours with all successes or no data are joined. Hover an hour for its recorded values.

Latest is the most recent hourly p50 with data. Median is the median of hourly p50 values over these 72 hours. The “slower than usual” label means latest is at least 25% above that median; it is a relative change, not a fixed speed rating.

How fast is the iflytek API from each region?

Endpoint response (TTFB) · last 24 hours · milliseconds (ms) · lower is faster.

How to read these metrics

Endpoint response (TTFB)Network connection and the first response byte, without model inference.

Typical · p5050% of successful timed samples finish within this time.

Slower · p9595% of successful timed samples finish within this time.

Region	Typical (p50 TTFB)	Slower (p95)	Uptime
Asia (Tokyo)	229 ms	899 ms	99.7%
Europe (Germany)	300 ms	770 ms	100%
South America (São Paulo)	649 ms	1589 ms	99.7%
US (Central)	413 ms	1438 ms	100%

Measured from Asia (Tokyo), iflytek responds in 229 ms; from South America (São Paulo) the same API takes 649 ms — 2.8× 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.