Como monitoramos

Várias fontes, uma resposta

Para cada serviço, coletamos até quatro sinais independentes. Qualquer um deles pode soar o alarme, e o mais grave que ainda seja recente define o que você vê. Se uma fonte parar de responder ou ficar desatualizada, ela é descartada.

Requisições de teste enviadas por nós

Onde temos acesso via API, um robô envia um prompt curto com streaming direto para a API do próprio provedor a cada um ou dois minutos e mede o tempo de resposta do primeiro token. Se uma tentativa falha, ela é repetida duas vezes com intervalo de vinte segundos antes de ser contabilizada. Respostas de limite de taxa (rate limit) e erros na nossa própria configuração são descartados para não sinalizar problemas onde não existem.

• Fora do ar as últimas três verificações consecutivas falharam
• Parcialmente fora metade ou mais das verificações nos últimos dez minutos falharam
• Lento ou com falhas pelo menos uma em cada cinco verificações falhou, ou o primeiro token demora mais de 3 segundos e três vezes mais que a mediana das últimas 24 horas

A página de status do próprio provedor

Lemos as páginas de status oficiais a cada minuto e analisamos apenas as partes relevantes para o serviço em questão — os componentes do ChatGPT para o ChatGPT, e não tudo o que a OpenAI opera. Se uma página não atualiza há quinze minutos, nós a ignoramos: uma página de status travada não deve manter um serviço verde nem vermelho.

Tráfego real pelo OpenRouter

O OpenRouter divulga quantas requisições têm sucesso para cada modelo em cada provedor. Monitoramos os modelos de um provedor servidos por seus próprios endpoints. Quando pelo menos dois deles, e no mínimo metade do conjunto, caem para menos de 80% de sucesso ao longo de 30 minutos e ficam dez pontos abaixo da média do dia, o serviço é marcado como lento ou com falhas; se cair para menos de 50% na média, como parcialmente fora.

Se três ou mais provedores caírem no mesmo instante, o problema comum é o próprio OpenRouter. Nesse caso, esse sinal é desconsiderado para todos.

Relatos de usuários

Cada página de serviço tem um botão “Estou com problemas”. Dez ou mais relatos em quinze minutos, a quatro vezes o ritmo normal daquele serviço, o marcam como lento ou com falhas. Relatos de usuários sozinhos nunca marcam um serviço como fora do ar, e cada visitante é contado apenas uma vez a cada meia hora, com um limite por hora.

Evitando alarmes falsos

O veredito é recalculado a cada 30 segundos. Para voltar a “operacional”, o serviço precisa permanecer estável por três minutos completos. Assim, uma API com oscilações rápidas não fica alternando de status na página o tempo todo.

Como interpretar as barras coloridas

A barra de 24 horas tem 48 blocos de meia hora cada; a de 30 dias tem um bloco por dia. Cada bloco assume a cor do pior estado registrado no período. Cinza significa que não tínhamos dados no momento — e não que estava tudo bem.

O que não conseguimos ver

Nossos robôs rodam a partir de um data center na Europa. Por isso, uma falha limitada a um só país, operadora de celular ou rede de escritório pode não chegar até nós. Também não vemos limites da sua conta ou cobrança. Além disso, alguns serviços, como o Midjourney, não têm API pública nem página de status; para eles, dependemos só dos relatos dos usuários.

De onde vêm os números

O isAIlive é um projeto irmão do llmlive.ai, que opera o monitoramento em si; ambos os sites usam as mesmas medições. Este site mostra apenas uma coisa: se a ferramenta que você precisa está funcionando agora.

llmlive.ai →

O que significam os estados

• Operacional Nenhuma fonte detectou problemas.
• Em manutenção A empresa anunciou uma manutenção programada.
• Lento ou com falhas Erros ou lentidão, mas a maioria das requisições passa.
• Parcialmente fora Uma parte considerável das requisições ou um recurso inteiro está falhando.
• Fora do ar O serviço está fora do ar para a maioria dos usuários.
• Sem dados Sem dados recentes de nenhuma fonte.