MetisRouter Status
Status guidance for production users debugging API availability, provider responses, timeouts, and model routing issues.
Last verified: 2026-06-05
How to interpret API issues
When a request fails, compare the HTTP status, request ID, endpoint, and Usage Logs entry before retrying or escalating.
- A missing log usually means the request failed before routing.
- A logged upstream error can indicate provider-side failure or model-specific rejection.
- Keep timestamps and request IDs for support.
Escalation
Use support channels for production incidents and commercial contacts for high-volume planning.
- Support: support@metisrouter.com
- High-volume sales inquiry: hello@metisrouter.com
- Include model ID, endpoint, region/client, timestamp, and observed error.
Public status scope
This public page documents how to evaluate availability and escalate incidents. It does not publish fabricated uptime percentages. A production status record should be backed by real request outcomes, provider route health, incident timestamps, and support follow-up notes.
- Use the page as an incident triage entry point while request-level evidence comes from Usage Logs.
- When a dedicated uptime feed or incident history is available, it should be published here with timestamps and affected endpoints.
- Until then, do not treat missing public uptime numbers as proof that a model route is healthy; test the exact model and endpoint before scaling.
Incident triage checklist
Status checks should start from evidence, not repeated retries. For each incident, capture whether the request created a Usage Logs entry, whether the error happened before routing or after upstream routing, which endpoint was used, and whether the selected model supports that endpoint and modality.
- Missing log: check API key, base URL, request path, account balance, and client-side network behavior.
- Logged platform error: inspect error code, model ID, endpoint type, reserve behavior, and request parameters.
- Logged upstream error: keep provider response, request ID, model ID, timestamp, and retry count before escalating.
Production readiness signals
A workflow is healthier when it has bounded output settings, retry discipline, model fallback candidates, and a clear owner for request IDs. For long-running coding agents, video generation, transcription, or automation jobs, the first successful request should be treated as calibration rather than proof that the workflow is ready for high volume.
- Track p50 and p95 latency, error rate, retry rate, and charged USD for the workflow.
- Use the pricing page and cost calculators before increasing monthly volume.
- Document the exact model ID and endpoint so future incidents are reproducible.
Support escalation path
For production incidents, email support@metisrouter.com with concrete evidence. For high-volume usage planning, email hello@metisrouter.com with expected monthly request volume, candidate model IDs, and whether the workflow is text, image, video, audio, embedding, automation, or coding-agent based.
- Include account email, API key name if relevant, model ID, endpoint, timestamp, and request ID.
- Do not retry expensive or ambiguous long-running requests before checking whether a billable log already exists.
- For customer-facing incidents, include first user impact time and whether the issue is still active.
FAQ
Where should support requests go?
Email support@metisrouter.com with request IDs and account context.
Where should high-volume usage requests go?
Use the High-volume sales inquiry contact for high-volume usage and commercial account questions.