27. Information needed when contacting support

Back to overview · Full table of contents · Download full PDF

This chapter: gather the information in this chapter before you submit an issue. That shortens the time to locate the cause. It covers the usual evidence entries, which fields to record, what must be redacted, and how to organize the material for support.

27.1 Confirm three things yourself first

Before you contact support, confirm these three points. They rule out most cases that only look like a fault:

1. Is it a permission or scope issue: when the call returns 403, first confirm the caller is in the available scope of a model group that contains that model, and that the key status is usable.
2. Is it a quota issue: when the call returns 429 and the reason code is POOL_EXHAUSTED, the quota is exhausted; it is not a service fault. Adjust the quota or wait for the period to reset.
3. Is it a rule block: when the request status in 「Operations overview › Requests」 is 「Blocked」, open 「Routing & changes › Hit records」 in the detail. You can see which rule matched and on which conditions.

All three have a conclusion on the console; engineering does not need to be involved.

27.2 Information to record

Note: the request ID and trace ID are also in the response headers (for example x-trace-id, x-lp-data-plane-request-id). When the caller is a business system, have developers log these two response headers; later troubleshooting is much faster.

27.3 Content that must be redacted

Before you submit screenshots and logs, check the items below one by one. Do not send them as-is:

• API keys, upstream vendor keys, access-key pairs (AK/SK), database passwords, master keys;
• Two-factor seeds, passkeys, recovery codes;
• Real customer data in request and response bodies (names, mobile numbers, ID numbers, bank-card numbers, addresses, ticket numbers, and similar);
• Internal domains, intranet IPs, and topology (if they are unrelated to the issue).

The product already handles most of this on the console: the authorization header in the request detail is shown as 「Redacted · length N」, and key plaintext does not appear in call records. Still confirm before you take a screenshot that the page has no plaintext-key dialog.

27.4 Organize the material into one write-up

Write in this order; support can pick it up most easily:

1. One-sentence conclusion: which function, what happened, how many people are affected.
2. Blast radius: which callers, which models or model groups, and whether all traffic is affected.
3. Time and frequency: first occurrence; continuous failure or intermittent.
4. What you already did: which rule you disabled, which configuration you changed, and the result.
5. Locating fields: Trace ID, request ID, error code (see the table in 27.2).
6. Attachments: redacted screenshots and log fragments.

Capability notes

---

Previous: 26. Go-live checks, stable operation, and management handover · Next: Appendix A. Role and entry quick reference