xAI says its Grok Bot cleared 204 support tickets in about 10 minutes: what the post states and what it does not

204 tickets in about 10 minutes works out at under 3 seconds each, and the post does not say what was sent

On 20 October 2026 SpaceXSI, the company behind Grok (the page footer reads SpaceXAI LLC and the page markup names xAI as publisher), published a post about two AI teammates in its own customer support. It says that during one incident on 18 September a Grok Bot teammate called IncidentSweep "cleared 204 tickets in about 10 minutes with a support engineer reviewing and approving the batch". Two hundred and four tickets in about 10 minutes is 20.4 tickets a minute, or 2.9 seconds a ticket (derived). That is far too short for anyone to read and answer a ticket, so (inference) the figure describes one approved batch going out, not 204 separate decisions. If the 10 minutes includes the engineer's review, the send itself took less than that, and the post does not say.

This briefing reads the post and the documents it points to. The post's page text was saved from a browser between 09:30 and 09:36 GMT on Monday 26 October 2026. The live page was fetched again at 09:40 GMT and matched it, and its page markup gives the date as 20 October, which is 32 days after the incident (derived). The Grok Bot documentation, the legal pages, the sub processor lists and both companies' status pages were read between 09:40 and 10:05 GMT. Nothing was filled in, submitted or downloaded.

What the post does not establish is most of what a buyer would want to know. It does not identify the incident, say how many tickets IncidentSweep set aside, give an error or wrong send rate, or say which model did the work. It is a vendor describing its own use of its own product: the page carries buttons marked Download for macOS and Contact sales, and the company sells Grok Bot. No outside party is named as having checked any figure.

The record around the post is not empty, and it matters more than the post. The company's own documentation says "An approval controls the proposed action. It does not reverse work already completed." It also tells users "Do not use separate Bots as a security boundary." The public status pages show no incident on 18 September on the company's own page, and two Grok Bot degradations that day on Cursor's page. The sections below set out what is stated, what is not, what the post's labels hide, and what a team evaluating this kind of tool should ask.

The three jobs the post describes, and the one human gate it names

The post describes three Grok Bot jobs inside SpaceXSI's support team. The first two are named in its subtitle. The third, Support Bot, is the customer facing Bot that the post says answers the tickets IncidentWatch holds. The table sets each one beside the control the post names for it.

The gate the post names is a person approving a batch before IncidentSweep sends it. For the replies Support Bot sends to held tickets, the post names no approval step. xAI's earlier support blog, dated 22 September 2026, shows why that is worth asking about. It says the team began with Grok Bot "limiting it to internal notes and requiring human approval for every write action", then, after reviewing a first day on the least complex tickets, let it begin answering customers directly, and that "99% of all refund requests are resolved without human intervention" for refunds where it was given clear instructions. It also says that when ticket volume on an issue reaches a set threshold, Grok Bot "can declare an incident automatically". The 20 October post says instead that a support engineer decides whether reports point to an incident. Whether practice changed in the 28 days between the two posts (derived) is not stated.

The numbers, computed from the post and the documentation

Every figure below in the Value column is derived by this site from numbers printed on the pages named, and each is labelled. The by hand figures are an illustration of scale, not a claim about the company's team.

Two rows carry the argument. The send rate shows the 204 is a throughput figure, which says nothing about whether the right 204 people received the right message. The cadence and run history rows show that a monitor on the shortest allowed schedule keeps a short visible history, so a team that wants to audit a detector, or a sweep, cannot rely on the app alone to hold the evidence.

Stated and not stated: the record, line by line

"Not stated" means not found in the post, which was read in full. It does not mean the information does not exist.

One gap in this table is also a gap between the company's own pages. The post says the team posts a confirmed incident to "our public status page". It does not say which page. The next section reads both.

What the public status pages show for 18 September

The post gives a date but no description, so the status pages are the only public place to look for the incident. There are two, status.x.ai and status.cursor.com, and they disagree by omission. Nothing below shows that either page records the incident the post means. The post does not identify it.

So "our public status page" is a friendly name that does not name a page. If the 204 tickets belong to one of the two Grok Bot degradations on Cursor's page, they belong to a Grok Bot degradation that the company's own status page never listed. If they belong to something else, the post is describing an incident that neither page shows. The record cannot decide between these, and naming the incident would have. The 22 September blog says Cursor "became part of SpaceXSI on August 14", which is 35 days before the incident (derived). Cursor's page also carries a scheduled notice that its status updates move to status.x.ai from 26 October, the day of this reading, and says "Incidents from the last 90 days can be found on status.x.ai." Its scheduled window runs from 19 October 15:00 UTC to 27 October 01:00 UTC, so the move may have been under way. The history page on status.x.ai printed "Updated Oct 26, 9:45 AM GMT" and did not list the Cursor incidents; at the final re-read it printed "Updated Oct 26, 10:00 AM GMT" and still did not.

Friendly names, and what the same company's documents say about each

The post uses comfortable words: teammate, approved, records, stops, status page. Each is a label doing the work of a control. The table sets each label beside what xAI's own documentation says, so a reader can see the distance.

The point is not that these controls are weak. Several are what a careful team would want. The point is that the post uses the label where the control's limits belong, and a buyer who reads only the post takes the label for the control. On the first row, the post describes a detector and a sender as two teammates. The documents say the way to get a separate credential set is to "give it its own Cursor user". The post does not say whether it did.

Controls named, controls not named: the questions a buyer should ask

These are questions, not faults. A control missing from a short blog post may exist in the product. The right column says what xAI's documentation prints on each, so a buyer knows where to push.

Zoom

The last row is the one the post is least likely to have in mind. IncidentWatch reads customer text to decide what to hold, and IncidentSweep reads it to decide what to set aside. A separate briefing on this site covers poisoned instruction files steering coding assistants, which is the same class of risk in a different feed. Whether it applies here depends on controls the post does not describe.

What the data terms say about ticket content, and where they stop

A support ticket carries a customer's name, contact details and often account facts, which is personal data in most jurisdictions. The post does not say where its own tickets are processed. The documents a buyer would be pointed to say this, and none of them settles it.

Cursor's own help page, in a question about price, mentions Opus 5.5 as a model a Grok Bot task can be routed to. Opus 5.5 is a model from Anthropic, which competes with xAI in AI models (this site covered its launch in an earlier briefing). The page does not say that Opus 5.5, or any outside model, handled a ticket for SpaceXSI or anyone. SpaceXSI is both the operator and, per its own blog, the parent of a Cursor that joined it on 14 August, so the post cannot show how a buyer's ticket data would be handled. That is what the contract, the DPA and a written answer on model routing are for.

Technical details

The post prints no configuration, query or log line. It prints a process, and the documentation prints the settings that bound it. This section reproduces both as printed, with the page and the time each was read. Nothing here is derived except where marked. No credential, token or ticket content is shown.

First, the process parameters from the post. These are the sentences that carry the cadence, the window, the gate and the stop condition. A buyer can turn each into a test case: change the window, interrupt a batch, add a ticket after approval.

Every five minutes, it reviews the previous 15 minutes of tickets for spikes around the same problem. If the pattern does not match a known incident, IncidentWatch alerts the support engineer on call with the apparent issue, number of matching tickets, and examples to investigate.
A support engineer decides whether the reports point to an incident and works with engineering to investigate. In the meantime, IncidentWatch holds tickets that clearly match the issue.

A support engineer starts by telling IncidentSweep which tickets to consider, which to exclude, and exactly what message to send. IncidentSweep finds the matching tickets, reviews each one, and sets aside any it cannot confidently connect to the incident.
Before sending anything, IncidentSweep shows the engineer the proposed batch, the tickets it included, and the exact message they will receive. The engineer can spot-check the tickets and make changes before approving the send.
IncidentSweep then sends the approved message in small batches and records each action. It never adds tickets after approval, and if anything fails, it stops and reports what happened.

Once the team confirms the incident, we post it to our public status page. Support Bot, our primary customer-facing Bot, returns to the held tickets, checks them against the incident, and responds to customers whose reports match. As the incident progresses, it can return with updates.

Second, the boundary settings the documentation tells a team to write. These are the examples docs.x.ai prints for stating a boundary in the request and for Auto Review rules. A defender copies the shape, not the example: a boundary for a support Bot would name sending customer messages and closing tickets.

Reconcile the campaign data and draft a recommended budget change. Do not
change the campaign or message the agency. Ask for approval after showing the
current value, proposed value, and expected impact.

Ask first before sending any external email.
Ask first before changing a production dashboard.
Allow automatically when running `git status` in `/workspace/reports`.

Third, the limits on routines, which bear on how a five minute detector can be run and audited, and the logging text, which bears on the claim that each action is recorded.

A Bot can own up to 50 routines, and the app keeps the 20 most recent run
records for each routine. Routine schedules must be at least five minutes
apart. Deleting a routine is immediate and has no undo.

Action Recording captures Bot actions, and OpenTelemetry Export sends those events to your collector when configured, tagged `cursor.surface=grok_bot`.
When a team enables it, Cursor records Bot actions, including scrubbed shell commands, in an internal store with a 90-day retention. Action Recording events do not appear on the Audit Log page.
Tool arguments and results, file paths and names, and message bodies are never exported on these events;

Fourth, what the status pages printed. These are the update texts posted on 18 September for the two Grok Bot degradations, and the 13 October text about routines, copied from the pages as read in a headless browser and from Cursor's history feed. They are the only incident text the record offers for the day the post describes, and they do not mention tickets.

status.cursor.com, incident 1, Sep 18, 2026:
  Resolved       14:33 UTC  This incident has been resolved.
  Investigating  11:37 UTC  We are investigating a service degradation affecting Grok Bot. Users may experience degraded performance or bots that don't respond.

status.cursor.com, incident 2, Sep 18, 2026:
  Resolved       23:02 UTC  This incident has been resolved.
  Monitoring     19:53 UTC  A fix has been implemented and we are monitoring for service restoration. Grok Bot should be responding normally again.
  Identified     19:01 UTC  The root cause has been identified and a fix is being rolled out. Some users may see Grok Bot respond slowly or not respond at all. We will provide another update shortly.
  Investigating  17:19 UTC  We are investigating a service degradation affecting Grok Bot.

Between 10:52 AM and 1:29 PM PT on October 13, many Grok Bot routines started by webhooks, Slack, git, email and Linear events didn't run. Webhook callers may have seen an HTTP 400 "Automation run rate limit exceeded" error, and other triggers failed without an error.

https://status.x.ai/history
https://data.x.ai/status/incidents.json
https://data.x.ai/status/uptime.json
https://status.cursor.com/history
https://status.cursor.com/history.rss

A note on the evidence. The status page times above are the pages' own and are UTC. The daily uptime data on status.x.ai appears to bucket days by US Pacific time: its 22 September 01:02 UTC outage is filed under 21 September (inference from the dates). That does not change the reading, because every component shows as available on each day from 16 to 20 September under either convention.

What to do, in the order worth doing it

The question that exposes the gap

The post names six controls, and every one of them acts before or during the send. If one of the 204 messages had gone to the wrong person, which control would have caught it, and which record would show it afterwards? The post does not say, and the documentation says the approval does not reverse what was sent.

Key facts