Last reviewed: 2026-07-21
Direct answer
Use customer impact tiers to separate a CometAPI incident into what users can feel, what operators can verify from the current API references, and what should wait for account-specific evidence. The tier label should describe the product effect, not the suspected provider cause. That keeps the incident note useful even when the first symptom is ambiguous, such as a timeout, an unexpected response shape, or a feature path that only fails for one request family.
A safe three-tier working model is:
- Tier 1: contained degradation, where a small feature path has slower, incomplete, or lower-quality responses but the main user workflow still completes.
- Tier 2: partial interruption, where a supported chat or response path fails for a meaningful share of users and fallback routing may be considered after route-specific checks.
- Tier 3: broad interruption, where the main user workflow cannot complete, customer communication is needed, or support escalation needs a clean evidence packet.
Before changing routes, compare your request assumptions against the official Chat Completions and Responses references, then attach support-ready notes if the incident needs escalation. For adjacent route evidence, see Check CometAPI Response Shape Before Promoting Fallback Traffic and Build a CometAPI Support Packet for Incident Handoffs .
The practical rule is simple: tier the customer impact first, then decide whether the technical evidence is strong enough to route, retry, roll back, communicate, or escalate. A Tier 2 note with clean evidence is more useful than a Tier 3 label based on a guess.
Smoke-test workflow
Setup assumptions: the operator has a valid CometAPI account, a credential stored outside the runbook, a chosen route family, and a non-production test input. Use <API_KEY_PLACEHOLDER> in shared notes instead of copying credentials. Confirm whether the incident concerns Chat Completions, Responses, or an application layer that sits above both. Keep these families separate because their request and response contracts are documented separately.
Happy-path request plan: send one minimal request against the same route family involved in the incident, using only fields confirmed in the relevant CometAPI reference. Record whether the request returns a valid response shape for that route. Do not use the happy-path result to claim broad availability, pricing, quota, or model behavior. It only proves that the chosen test path completed at the time of the check.
Error-path check: send one deliberately incomplete request in a controlled environment, such as omitting a required request field shown in the reference, and confirm the client captures the error shape without retrying endlessly. This test is not meant to create customer impact. It is meant to prove that the application can classify a bad request, avoid a retry loop, and preserve enough evidence for a human handoff.
Minimum assertions: record route family, request timestamp, status category, response-shape category, whether the customer workflow completed, whether fallback was used, whether the user saw a degradation message, and whether support evidence is ready. If any field is unknown, write unknown rather than filling the gap with a theory.
Pass/fail logging fields:
incident_id: "INC-PLACEHOLDER"
impact_tier: "tier_1|tier_2|tier_3"
route_family: "chat_completions|responses"
status_category: "success|client_error|service_error|timeout|unknown"
response_shape_category: "expected|unexpected|missing|unknown"
workflow_completed: "yes|no|partial"
fallback_used: "yes|no"
customer_message_shown: "yes|no|not_applicable"
support_packet_ready: "yes|no"
operator_note: "sanitized summary only"
Do not assert model availability, pricing, quota, latency targets, billing outcome, uptime, or provider-specific behavior unless those exact facts are verified in the linked source for the account and model in use. Customer impact tiers are operational labels, not evidence substitutes.
Who this is for
This guide is for on-call engineers, support engineers, customer-facing technical teams, and product owners who need a consistent way to describe customer-visible impact during CometAPI-backed LLM incidents. It is especially useful when technical symptoms are mixed: one route may still answer, another route may return an error, and product teams need a clear escalation label that does not overstate the evidence.
It also helps teams that already have fallback code but lack a shared language for deciding when to use it. A fallback route can reduce user pain, but it can also hide a contract mismatch, introduce response-shape drift, or create more load if retries are not bounded. The tier should therefore stay tied to user outcome and observable request evidence, not to a preferred mitigation.
Key takeaways
- Classify impact by the user workflow first, then attach the technical evidence.
- Keep route checks separate for Chat Completions and Responses because the references describe distinct API surfaces.
- Treat fallback as an operational decision, not a proof that the upstream issue is solved.
- Escalation notes should include sanitized request context, response category, user-visible effect, and reproducible steps.
- A Tier 1 issue can still deserve a fix, but it should not trigger broad routing changes without evidence that the main workflow is at risk.
- A Tier 3 label should be reserved for broad interruption, missing recovery path, customer communication need, or support escalation that cannot wait.
Sources checked
- CometAPI documentation - accessed 2026-07-21; purpose: verify current CometAPI documentation navigation.
- CometAPI chat completions reference - accessed 2026-07-21; purpose: verify chat completion contract areas.
- CometAPI responses reference - accessed 2026-07-21; purpose: verify responses endpoint contract areas.
- CometAPI help center - accessed 2026-07-21; purpose: verify support and escalation documentation areas.
Contract details to verify
| Area | What to verify | Source URL | Accessed | Safe candidate wording |
|---|---|---|---|---|
| Documentation location | The current docs pages are reachable and relevant before an incident runbook links to them. | https://apidoc.cometapi.com/ | 2026-07-21 | Use the current CometAPI documentation map before relying on older saved links. |
| Chat Completions route | The request plan matches the current chat completions reference for the route family being tested. | https://apidoc.cometapi.com/api/text/chat | 2026-07-21 | A chat completions smoke test should verify the route family and response shape before changing traffic. |
| Responses route | The request plan matches the current responses reference when the incident involves that route family. | https://apidoc.cometapi.com/api/text/responses | 2026-07-21 | A responses smoke test should be tracked separately from chat completions evidence. |
| Support evidence | The escalation packet includes sanitized notes that support can use without exposing credentials or full prompts. | https://apidoc.cometapi.com/support/help-center | 2026-07-21 | Escalate with reproducible, sanitized evidence rather than screenshots alone. |
Failure modes
- Evidence gap: the team cannot inspect the failing log, source page, pull request, or local command output. The safe action is to stop and record the missing evidence instead of guessing.
- Scope drift: the repair expands beyond the observed customer impact. Keep the change tied to the failing signal and leave unrelated cleanup for a separate task.
- Environment mismatch: the local check uses different versions, credentials, feature flags, or runtime settings than the hosted path. Record the mismatch before treating the result as proof.
- Unreviewed fallback: the team changes models, endpoints, permissions, or retry behavior to make a run pass without preserving the review boundary. Treat access and provider failures as operational blockers, not topic failures.
- Retry amplification: repeated retries turn a partial interruption into a broader one. Bound attempts per user action and compare the result with Cap CometAPI Fallback Attempts per User Action .
- Weak handoff: the final note says the issue is fixed but omits the customer effect, route family, result, changed behavior, and remaining uncertainty. That makes the next operator repeat the investigation.
Reader next step
For the next CometAPI-related incident, add an impact-tier field to the first incident note before anyone changes fallback routing. Write the tier as a temporary classification, then attach the evidence that supports or weakens it. Start with these five fields: affected workflow, route family, observed status category, response-shape category, and customer-visible outcome.
Then run one clean happy-path check and one controlled error-path check for the relevant route family. If the incident involves Chat Completions, compare the request and response assumptions with the Chat Completions reference. If it involves Responses, use the Responses reference instead. If support escalation is needed, prepare sanitized reproduction steps, request timing, status category, and the impact tier. Keep credentials, full prompts, full responses, private account data, prices, limits, and model availability claims out of the shared note unless they are explicitly verified for the account and safe to disclose.
Use Cap CometAPI Fallback Attempts per User Action as the next comparison point. Keep Verify Prompt Templates Before CometAPI Fallback nearby for setup and permission checks.
FAQ
Are these official CometAPI severity levels?
No. They are operator-facing customer impact tiers for incident notes. Use them to describe what users experienced while keeping CometAPI contract checks tied to the linked documentation.
Should every error become a Tier 3 incident?
No. A single controlled error-path check can be useful during validation, but the tier should reflect customer-visible workflow impact and the breadth of the interruption.
Can the tier prove that fallback routing is safe?
No. The tier helps prioritize response. Fallback still needs route-specific request checks, response-shape checks, retry boundaries, and rollback notes.
What should stay out of the shared incident note?
Do not include credentials, full prompts, full generated responses, private account data, pricing assumptions, quota assumptions, unsupported model availability claims, or account-specific details that are not needed for the handoff.
When should a tier change during an incident?
Change the tier when customer-visible impact changes or when better evidence shows the first label was too broad or too narrow. Keep the old label in the timeline so the incident history remains understandable.