> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ttapi.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Reliability

> Where to check status, what TTAPI controls, and how to troubleshoot availability issues

This page answers three practical questions:

* Where to check service status
* Which problems are on the TTAPI side
* Which problems come from upstream models or third-party platforms

<CardGroup cols={3}>
  <Card title="Status" icon="signal" href="http://54.211.73.9:8020/">
    Current temporary monitoring page. The public status domain will be `https://status.ttapi.io`.
  </Card>

  <Card title="Midjourney Hosting" icon="user-shield" href="/grids/en/development/midjourney-hold-account">
    Hosting setup, execution modes, and account-level considerations.
  </Card>

  <Card title="Claude Code" icon="terminal" href="/grids/en/development/claude-code">
    Configure Claude Code to use TTAPI's Claude-compatible endpoint.
  </Card>
</CardGroup>

## Check the status page first

If you suspect a service issue, check the status page before retrying aggressively.

| Purpose                 | URL                                                  | Notes                       |
| :---------------------- | :--------------------------------------------------- | :-------------------------- |
| Current monitoring page | [http://54.211.73.9:8020/](http://54.211.73.9:8020/) | Available now               |
| Public status page      | [https://status.ttapi.io](https://status.ttapi.io)   | Public domain after rollout |

## Service boundaries

TTAPI controls the gateway, auth layer, submission path, and result-fetch flow. But many generation products still depend on upstream providers such as Midjourney, Sora, Suno, Claude, and others.

That means service availability does not always equal instant execution with zero upstream variance.

| Situation                                       | What it usually means                                       | Suggested action                                    |
| :---------------------------------------------- | :---------------------------------------------------------- | :-------------------------------------------------- |
| Request succeeds but jobs are slower than usual | Upstream congestion, queue pressure, or provider throttling | Check status, then keep polling                     |
| Request fails with `4xx`                        | Request, auth, balance, or permission issue                 | Fix the request before retrying                     |
| Request fails with `5xx`                        | Temporary gateway or upstream error                         | Retry once or twice, then contact support if needed |
| One model is failing while others work          | Single product line or provider issue                       | Switch models or wait for recovery                  |

## Troubleshooting flow

<Steps>
  <Step title="Check whether it is a broader incident">
    Start with the status page and see whether there is an ongoing alert, maintenance event, or recovery note.
  </Step>

  <Step title="Look at the error type">
    `400-499` usually points to request-side issues. `500-599` is more likely a service-side or upstream issue.
  </Step>

  <Step title="Separate submit failures from pending results">
    If submission succeeded but the task remains `PENDING_QUEUE` or `ON_QUEUE`, the job is usually still alive and waiting.
  </Step>

  <Step title="Send support the right context">
    If the status page is normal and the issue persists after a small retry, include the endpoint, request time, status code, response body, and `jobId` where relevant.
  </Step>
</Steps>

## Retry guidance

| Case                                          | Retry? | Recommendation                         |
| :-------------------------------------------- | :----- | :------------------------------------- |
| Invalid params, bad key, insufficient balance | No     | Fix the request or account state first |
| A single `500`, `502`, or `504`               | Yes    | Retry once or twice with a short delay |
| Task is queued                                | No     | Keep polling instead of resubmitting   |
| Status page shows an active incident          | No     | Wait for recovery or use another model |