Version incidents

You ship 2.4.1, and twenty minutes later people start writing in: the app crashes when they open Settings. Concierge notices the wave, shows it as an incident with the version, the count and real examples, and lets you (or your coding agent) set one reply that every affected user gets right away. When the fix ships, resolve the incident and tell them to update. Version incidents are part of Pro.

How detection works

Every customer message that starts a ticket (the first message in a conversation, or the first after 12 quiet hours) is counted under the version of the device that sent it. Every 5 minutes the worker compares each version’s tickets in the last 2 hours with what your own history predicts for a version with that share of active devices:

• Expected tickets = your usual ticket rate (previous 7 days, all versions, same platform) x 2 hours x the share of active devices on that version. Apps with little history compare the version’s share of this window’s tickets with its share of devices instead.
• A spike needs at least 5 tickets, at least 3 times the expected number, and a chance under 1 in 1,000 of happening by luck (Poisson).

Only a spike goes on to the next step, so quiet days cost nothing. The tickets from that version are then grouped by problem: Claude Haiku reads up to 40 of them (with emails, tokens and other personal details masked first) and names the groups that report the same concrete problem. A group of at least 4 tickets becomes an incident. Each ticket is classified once, and a typical detection costs about $0.0005 in model usage. Without a model key the worker groups tickets by shared words instead.

Versions are grouped by the marketing version, so 2.4.1 (311) and 2.4.1 (312) count together. iOS and Android are counted separately. Web is not tracked, since a website has no app version.

The incident card

Incidents in the sidebar (and a strip above the inbox while one is open) shows each incident with:

• the platform and version, a short title and one line summary,
• tickets and conversations, first and last seen,
• how far above normal the version is (“14 tickets in 2h, 12x the usual rate”),
• the newest examples, each with OS and build and a link to the conversation.

One reply for everyone affected

Write the reply on the card, for example “We know about the crash in 2.4.1 when opening Settings. A fix is in review.” and press Send to affected users:

• every open conversation in the incident gets it at once (in the app and by push),
• each new ticket from that version that reports the same problem gets it instantly, instead of an AI answer,
• each conversation gets it once, signed with your support title, and the inbox marks it Incident reply,
• follow up questions go to the AI as usual, and the AI knows about the incident and your statement, so it does not promise more than you did.

Incident replies do not count toward your monthly AI replies. Press Stop to stop sending it, or edit the text for new conversations.

Resolve and tell people to update

When the fix is out, enter the version (for example 2.4.2), keep Tell affected users it’s fixed checked and press Resolve. Auto replies stop at once, and every conversation in the incident gets one note: “Good news: the problem you reported is fixed in version 2.4.2. Please update the app, and reply here if anything still looks wrong.” Not an incident closes a false alarm without telling anyone.

From your coding agent (MCP)

The MCP server has four tools for this, so an agent can go from “users report a crash” to a fix and a reply:

Tool	What it does
list_incidents	Open (or resolved, dismissed, all) incidents, optionally for one app.
get_incident	One incident with its newest tickets, OS and build. Ticket text arrives as untrusted customer data.
set_incident_auto_reply	Sets or stops the reply. Ask the developer before sending: it reaches real customers right away.
resolve_incident	Resolves with fixedInVersion and notify, or dismiss for a false alarm.

Try: “list my open incidents, find the crash in the code, and draft the reply for me to approve.”

API

With a session or a staff API key (ck_...):

• GET /v1/apps/:appId/incidents?status=open|resolved|dismissed|all
• GET /v1/incidents/:id returns the incident and its newest tickets
• PUT /v1/incidents/:id/auto-reply with { "text": "..." }, or { "text": null } to stop
• POST /v1/incidents/:id/resolve with { "fixedInVersion": "2.4.2", "notify": true } or { "dismiss": true }

Before the workspace subscribes, setting a reply answers 402 subscription_required; reading, stopping and resolving always work.

Keep versions current

Devices report their version when they register. The iOS and Android SDKs also send the current app and OS version with every message, so the count stays right after an update. Older SDK versions are counted under the version they registered with.

Privacy

A ticket is stored as ids and versions only, never text. Incident titles and summaries are written from masked text and hold no personal details. Examples on the card are read from the conversation itself, so deleting an end user’s data (GDPR or CCPA) removes them too, and their tickets go with it. Tickets that never became part of an incident are deleted after 30 days.