Recover From a Problem
Recover From a Problem
Start with the affected receipt, query, export or alert. Preserve its identifier and safe error message; do not resend accepted data merely because a later query is incomplete.
| Symptom | Likely subsystem |
|---|---|
| Events accepted but not appearing | Follow the receipt in Ready data; respect its poll/retry bounds. |
| Partial or stale report | Check coverage and the same time range in Events; keep the warnings visible. |
| Export failed or expired | Inspect the job error and create a corrected/new export. |
| Credential rejected | Confirm tenant and scope; use your administrator's credential lifecycle if rotation is required. |
| Notification failed | Fix the receiver, then replay the failed delivery. |
| Privacy/offboarding incomplete | Keep its request ID and resolve the reported blocker before confirmation. |
Start with See What Is Happening. If the status page points to an operator-only repair, capture the failing subsystem, time range, and tenant before handing the issue to your Custd operator.
Example: a receipt returning poll should be refreshed after its supplied wait,
using the same UUID. Recovery succeeds when that receipt is ready and the intended
query has coverage. A cleared browser error alone is not that proof. Database
restore, queue administration and platform cleanup are not tenant repair steps.