Skip to main content
When reporting a problem, describe what you expected, what happened, and the steps that caused it. Include a screenshot and the page address. Keep unrelated issues in separate reports.

​
What happens to a report

Every report, whoever or whatever filed it, is one ticket in Admin → Support, and the inbox opens on Needs you: the tickets nobody has decided on yet. Each has one decision, made from the ticket’s drawer:
  • Fix it approves the ticket for the repair queue. The repair still has to pass the applicable checks and release conditions.
  • Later parks it. It stays visible under the Later view and never nags.
  • Close ends it as “won’t do”.
Failed checks are saved as ordinary Support tickets. Repeated failures update the same check ticket. Automatic repair and check-related Telegram updates are off. Choose a ticket here, then ask Codex or Claude Code to work on it when you are ready. Approval does not start a background agent. Full regression runs only when requested. Core checks still run on changes. A ticket is fixed only after the original problem has been checked again; a local patch or a queued task is not proof of a fix.

​
For administrators

Admin → Support keeps the original report, screenshots, context and investigation together. The inbox is read by what a ticket needs: Needs you, Later, Queued, Being worked on, Blocked, Checking repair, Waiting on reporter, Fixed, and Everything (the full list with status, kind and priority filters). Resolved tickets stay out of the open views; a grouped duplicate shows under its main ticket. Each ticket has a Where things stand card:
  • Current outcome describes what is known and verified, up to 500 characters. Say whether a fix is local, deployed or verified in production.
  • Next action names the owner and their next step, up to 300 characters. Write “None” when no action remains.
Choose Update summary to edit both fields. They also appear in the inbox and the copied ticket packet. Saving is internal: it does not change status or send a message to the reporter. Changed summaries leave one history entry; saving the same text again adds nothing. If someone else edited the summary, reload and reconcile their changes before saving.

​
Keep the queue useful

Search for the existing issue before adding a ticket. Continue using it across retries and chats. Update the summary when an outcome, blocker or next action changes; use comments for new evidence or decisions rather than routine progress. Use Same thing only when reports describe the same issue. Keep separate problems separate. Preserve resolved history, and mark a bug fixed after the change is deployed and the original problem has been checked. Connected agents can update the handoff through the founder-only support tools. Approval, resolution and replies remain separate controls.

​
Automatic failure investigation

Signed failure alerts create a ticket or update the existing issue for that environment. Re-delivering the same event adds neither a ticket nor an occurrence. A new dated failure after a fix reopens the issue; a delayed old alert does not. Counts represent delivered alerts, not necessarily every failed operation or affected user. Automatic AI investigation is currently off. If explicitly re-enabled, the support sweep analyses two queued tickets per run. Each investigation uses one AI request with a small, redacted evidence packet. The Investigation card shows its state, evidence, suggested next action and receipt, including the exact input and reported usage. Evidence references make observations reviewable; they do not prove the AI’s interpretation is correct. The analyst cannot browse, inspect code, run tools, change the product, contact reporters or mark a ticket fixed. It can fill an untouched handoff with a clearly marked suggestion; it preserves a human-edited handoff. Screenshots need human review. Missing context is identified rather than invented. The platform permits at most 20 attempts daily and 200 monthly, including retries and tickets without a workspace. Each episode allows two attempts, separated by at least 15 minutes after failure. Inputs are bounded to 12,000 bytes and output to 900 tokens. Budget exhaustion leaves work queued; repeated investigation failure requires attention. Repeated alerts do not repeatedly buy analysis. Similarity is advisory; grouping separate reports remains a human decision. Review the evidence, assign the next step, verify the deployed fix against the original problem, then resolve the ticket. A subsequent regression starts a new investigation episode on the same ticket.

​
Plain-English alert explanations

Sentry alerts keep their immediate notification. When a bounded investigation succeeds, Telegram receives one follow-up with the saved plain-English explanation, a suggested next check, and a link to the support ticket. It uses the same analysis, with no additional AI request. The explanation is advisory, not confirmation of a cause or fix. Duplicate deliveries and failed analyses do not send explanation messages. If Telegram is unavailable, the report remains in Admin → Support; notification delivery is best effort and does not retry the analysis. Other Telegram alert categories do not automatically receive AI explanations.

​
Approval and connection diagnostics

If an agent tries to start a ticket before it is approved, it receives an approval_required result explaining how to approve it in Admin → Support. No changes are made. This expected permission response is not reported as an internal crash. An agent requesting a newer connection version can use Memo’s compatibility fallback. The fallback and request outcome are recorded together in request logs; the version difference alone does not create a Sentry warning. Actual connection failures still follow the normal alert paths.