Cursor opened an incident at 21:26 UTC on September 15, flagging degradation across Composer and its xAI-backed surfaces. A fix was marked implemented between 21:38 and 21:41 UTC, putting the active window at roughly twelve to fifteen minutes. That is short as outages go. But the detail worth tracking is not the duration. It is the scope change mid-incident: Cursor initially named two surfaces, Composer and xAI, then revised the writeup to say only Grok 4.6 non-fast was affected.
That revision matters because it changes what teams should have checked during the window versus what they actually needed to check. Anyone paging on Composer failures at 21:30 UTC was responding to a surface later excluded from the confirmed cause. Cursor's status page does not explain what distinguished the non-fast variant from other Grok 4.6 paths, nor does it say whether fast-mode requests were ever at risk. That gap is not filled anywhere in the incident record. The company has not disclosed root cause, only the timestamp of detection and the timestamp of a fix.
For on-call engineers, the practical exposure is retries and fallback routing, not the five-minute spike itself. If a pipeline pinned to Grok 4.6 non-fast during that window, requests may have queued, errored, or silently downgraded depending on how the client handled model unavailability. Worth checking: logs between 21:26 and 21:41 UTC for elevated latency or error rates scoped specifically to non-fast calls, not aggregate Composer traffic, since the aggregate signal was the misleading one here. Anyone who alerted on Composer broadly and found nothing wrong by 21:45 UTC should not assume the incident was a false alarm. It wasn't. The scope was just narrower than first reported.
The sequence is a small case study in how fast a status page scope can move, and why first-hour incident text should be treated as provisional. Composer is a wide surface; Grok 4.6 non-fast is one model variant behind it. Cursor's own update structure, opening broad and narrowing later, is common for API-dependent tools where the first signal comes from downstream error rates before the vendor isolates which backend call is failing. Operators who build dashboards off upstream status pages should weight the final incident text over the first, and log which systems paged on the initial broad language.
No customer-facing impact numbers, request counts, or root cause have been published. The incident entry gives three data points: open time, scope correction, and fix-implemented time. Everything else, including why non-fast specifically degraded while other paths apparently did not, sits outside what Cursor has confirmed.
The fix was marked implemented at 21:41 UTC, nine minutes after Cursor first said Composer was affected and before it said only one model variant was.