FONTES E METODOLOGIA

O que o status significa.

Relatórios, observações e dados ausentes são mantidos distintos.

Relatórios oficiais

O diretório inclui 56 serviços de IA de assistentes e busca, programação, mídia criativa, APIs de modelos, inferência e nuvem GPU e bancos de dados vetoriais. 37 têm fontes automáticas configuradas, junto com 11 serviços gerais. É uma seleção editorial, não uma classificação de popularidade medida ou inventário completo do setor. Salvamos relatórios do provedor e não confirmamos a disponibilidade de serviços de IA de forma independente.

Os resumos do Claude e GitHub incluem componentes, incidentes e manutenção. Outros endpoints de resumo compatíveis podem omitir listas de eventos; a omissão é exibida explicitamente. O endpoint coletado da OpenAI fornece atualmente status de componentes sem listas de incidentes ou manutenção. Os resumos do ChatGPT e da API são derivados separadamente de IDs de componentes fixos e verificados; IDs novos ou ausentes exigem revisão. Sua disponibilidade não é uma afirmação sobre um modelo, nível ou conta específicos.

Copilot, v0, Replicate, Workers AI e AI Gateways são lidos dos seus componentes específicos em páginas compartilhadas do provedor. O indicador geral da página principal e incidentes sem relação não são atribuídos a esses produtos. A ausência de um componente selecionado impede salvar um novo relatório.

Hugging Face, Together AI, Modal, Runpod e Qdrant usam o formato JSON público do Better Stack. Recursos referenciados e atualizações do relatório devem estar presentes. Relatórios resolvidos são excluídos mesmo sem hora de término. Horários de atualização de recursos não são inventados a partir do horário da página. Os status publicados de serviços e modelos da DeepInfra são observações do provedor; respostas marcadas como desatualizadas por ele são rejeitadas. Este adaptador não importa detalhes de incidentes ou manutenção.

Vercel e Cloudflare têm visualizações de relatórios da plataforma e visualizações separadas para produtos específicos. A visualização do Supabase usa o indicador publicado da plataforma e os componentes listados atualmente; eles podem cobrir apenas parte da plataforma e não verificam todas as regiões ou projetos. Notion e Resend usam seus domínios atuais verificados; os resumos coletados omitem listas de incidentes e manutenção. A API atual versão 2 do Slack fornece status e registros de incidentes, com nomes de funcionalidades afetadas nas atualizações; não fornece uma matriz completa de componentes. Registros programados são mantidos separados sem inventar janelas de manutenção.

Stripe usa seu novo domínio de status verificado para relatórios de componentes, incidentes e manutenção. A página oficial do Auth0 fornece JSON incorporado de resumos de dez regiões públicas de produção; scripts não são executados, e nuvem privada, integridade de tenants, detalhes de incidentes e manutenção não são importados. Regiões ausentes ou identidade da página alterada rejeitam um novo relatório. AWS Health fornece eventos públicos no formato UTF-16 big-endian atualmente verificado. Serviços, regiões, atualizações e códigos numéricos do provedor são mantidos, mas não interpretados como gravidade ou resolução. O agregado permanece neutro e não estabelece a integridade da conta ou disponibilidade geral da AWS.

O feed público de incidentes do Google Cloud é verificado com seu próprio catálogo de produtos. Incidentes encerrados ou futuros não se tornam atuais. Sem incidentes públicos ativos, o resumo permanece neutro; não descreve Personalized Service Health nem estabelece a disponibilidade de um projeto de forma independente. Os nomes de produtos e locais do provedor são mantidos nas atualizações.

A fonte Gemini é o feed de incidentes Gemini do Google Workspace, verificado com seu catálogo oficial. Incidentes encerrados, futuros ou sem relação não se tornam incidentes atuais do Gemini. Sem incidentes ativos, o rótulo é “Sem incidentes relatados”, não uma afirmação de que Gemini está operacional. A última atualização de um incidente Gemini difere da hora de coleta; um feed sem incidentes Gemini não tem uma hora publicada de atualização Gemini.

Grok / xAI lê quatorze componentes verificados do JSON público usado pela página oficial de status, validando IDs, nomes e o conjunto selecionado completo sem executar scripts. Gráficos ao vivo e detalhes de incidentes não são importados. DeepSeek importa o resumo estruturado de alterações ativas da sua página pública; sem alterações relatadas, a disponibilidade geral permanece desconhecida. Nenhuma página fornece hora de publicação verificada para esses campos coletados. fal usa seu resumo versão 3 e sete componentes verificados; ambas as respostas devem ser validadas, e detalhes de avisos ou horários de publicação ausentes permanecem ausentes. CoreWeave usa a API pública Status.io com códigos de status, componentes e locais do provedor verificados; manutenção atual e futura são separadas.

Midjourney usa o feed JSON de produção vinculado por sua própria página oficial de status. Os resumos de serviço são separados das estimativas de espera Fast e Relax. As cores de espera não são interrupções ou medições independentes de latência. O horário do feed do provedor é mantido, e relatórios com mais de quinze minutos ou mais de trinta segundos no futuro são rejeitados.

Google Cloud AI filtra o feed público de incidentes da nuvem por 23 IDs de produtos Vertex verificados. Outros incidentes do Google Cloud são excluídos; produtos selecionados ausentes rejeitam um novo relatório. Esta visualização é separada do aplicativo Gemini e Gemini API / AI Studio. Codex coleta somente o componente Codex in ChatGPT Desktop do relatório da OpenAI, que não estabelece a disponibilidade da CLI, extensão de IDE ou tarefas na nuvem.

Gemini API, Google AI Studio e Google Cloud AI são separados deste feed do aplicativo Gemini. Gemini API / AI Studio tem sua própria página oficial de status; a coleta automática dessa página não está implementada. “Somente página oficial” significa uma página de status com link, sem coleta automática. “Não conectado” significa ausência de dados de status; qualquer site do produto com link é identificado como site.

Coleta e atualidade

O processo de coleta verifica cada fonte configurada a cada 120 segundos, com até 15 segundos de variação aleatória. As páginas leem dados salvos e atualizam a cada 30 segundos enquanto visíveis. A atualização manual também lê dados salvos.

Uma coleta válida fica desatualizada após 6 minutos. Seu último relatório conhecido permanece visível com um aviso de desatualização. A hora de coleta indica quando recebemos e validamos os dados. A hora de atualização da fonte é fornecida pelo provedor ou identificada explicitamente como a última atualização de um incidente; um horário da fonte sem alterações não significa, por si só, que a coleta esteja desatualizada.

Cada coleta tem um prazo de 10 segundos e cada resposta é limitada a 512 KiB. Gemini e Google Cloud exigem que seus próprios catálogos fixos de produtos e feeds de incidentes passem pela validação antes de salvar um relatório. Falhas de coleta usam espera progressiva de até uma hora, considerando um Retry-After interpretável. Uma falha é registrada separadamente e nunca transforma o relatório do provedor em uma interrupção.

Valores de status desconhecidos permanecem desconhecidos. Campos ausentes de incidentes ou manutenção são identificados como não fornecidos. Manutenção futura programada é exibida separadamente e não conta como interrupção atual. Um incidente ausente no feed não estabelece seu histórico completo nem confirma a recuperação de forma independente.

Histórico diário e cobertura

O diretório mostra as últimas sete datas UTC; os detalhes oferecem trinta ou sete dias. Cada ponto representa o status salvo mais grave do dia, separado do atual. Verde significa relatório normal ou verificação bem-sucedida; amarelo, degradação ou verificação sendo refeita; vermelho, interrupção relatada ou falha confirmada; azul, manutenção em andamento. Cinza cobre observações ausentes ou inconclusivas; a explicação indica o motivo.

Um ponto preenchido pela metade indica cobertura incompleta ou um dia ainda não concluído. O anel tracejado de hoje significa que o dia está em andamento. A cobertura de status conhecido conta registros interpretáveis ao longo do dia completo ou do tempo decorrido hoje. É cobertura de registros, não disponibilidade medida.

Os status salvos são limitados pela próxima observação e pela atualidade existente: seis minutos para relatórios oficiais e quinze para verificações. O histórico de sondas reutiliza as regras de falhas consecutivas e recuperação. Falhas de coleta são contadas separadamente e nunca se tornam status de interrupção. As durações descrevem status salvos de relatórios ou verificações, não durações exatas de incidentes. Datas anteriores à primeira observação ficam cinza; não importamos nem afirmamos ter o histórico completo de incidentes do provedor.

Observações regionais

Os agentes de sondas independentes verificam a página inicial pública do GitHub e leem metadados de um repositório público pela GitHub API. Usam HTTPS IPv4, validam o certificado e o conteúdo esperado e registram tempos de resolução, conexão, TLS, cabeçalhos e total. Uma verificação bem-sucedida da página inicial não estabelece que login, operações Git ou Actions funcionam. Uma leitura pública de API não estabelece que operações autenticadas funcionam.

O resolvedor selecionado é exibido com cada nó. Agentes podem usar o resolvedor do sistema ou Cloudflare DNS sobre HTTPS. Este último não testa o resolvedor do sistema e pode selecionar outros endereços de destino. Endereços privados ou especiais são rejeitados; os destinos são fixos, endereços públicos validados são fixados para a solicitação e redirecionamentos não são seguidos.

Cada agente verifica dois controles fixos de conectividade, operados pela Cloudflare e Mozilla. Pelo menos um deve passar antes que falhas nos destinos contem para confirmação. Se nenhum passar, os resultados indicam “Conectividade da sonda incerta”. É um teste limitado de conectividade, não uma prova de que o nó ou todos os caminhos de rede estejam funcionando.

As verificações são executadas a cada 5 minutos, com até 15 segundos de variação aleatória. A primeira falha indica “Reverificando falha”; duas falhas consecutivas confirmam uma verificação com falha naquele nó. A recuperação de uma falha confirmada e atual exige dois sucessos; após um intervalo desatualizado, uma verificação bem-sucedida inicia uma nova referência. A confirmação exige observações e recebimentos com pelo menos 4 minutos de intervalo, sem lacunas de 15 minutos ou mais. Acesso negado, limites de solicitações, redirecionamentos e destinos rejeitados são inconclusivos e não confirmam uma falha do serviço.

Observações e heartbeats ficam desatualizados após 15 minutos. Verificações desatualizadas não mantêm um selo atual de sucesso ou falha. A hora da observação é quando o agente terminou um ciclo; a hora do recebimento é quando o servidor o aceitou. Relatórios ausentes, falhas de coleta e falhas de serviço permanecem distintos.

As verificações de destinos de serviço são executadas em nós independentes. O centro coleta relatórios oficiais e recebe resultados; não sonda destinos de serviço. Locais não verificados não aparecem no histórico regional. Ashburn, Frankfurt e Tokyo exigem nós remotos reais; o registro, por si só, não estabelece cobertura. A localização e a rede do nó são configuradas pelo operador, sem verificação automática. Não inferimos acessibilidade regional de um relatório oficial global, não combinamos votos de nós em um status global nem inferimos a causa de uma interrupção.

Ver cobertura real

Dependências e causalidade

Nenhum registro verificado de dependências a montante é publicado ainda. Um incidente do provedor, sozinho, não estabelece qual aplicativo afetou ou a causa do problema de um usuário.

Acesso gratuito e medição mínima

As consultas de status são gratuitas e não exigem conta. Notificações por email estão planejadas; esta versão não envia emails nem coleta endereços.

Registramos visitas a páginas de serviços, cliques em fontes oficiais e feedback opcional com um identificador aleatório no sessionStorage desta aba. Não armazenamos IPs, emails ou User-Agent completo nesses registros. Atualizações automáticas não contam como novas visitas. Filtramos bots conhecidos na medida do possível.

Os eventos de desenvolvimento são marcados como internos. Os dados são armazenados no banco de dados configurado pelo operador. A limpeza automática por retenção ainda não foi implementada; a implantação pública exige uma política de retenção e sua aplicação.