Escolha um produto
Hospedagem de sitesSites e WordPress em um plano de preço fixoCloudFaça deploy de apps, APIs e bancos de dados a partir do Git ou do DockerAI BuilderCrie e altere sites e apps com IAAdicione a qualquer projeto
Domínios e e-mailBancos de dadosWordPress gerenciadoAmbientes para agentesMigraçõesDesenvolvedores
Tudo sobre IADesenvolvedoresMCP para assistentes de IADocumentaçãoSegurançaStatusHostingsurge
PreçosEntrarStatus
Cada componente abaixo passou na verificação mais recente. A plataforma verifica a si mesma a cada minuto, e esta página mostra apenas o que essas verificações registraram.
Cada barra é um dia UTC: a proporção das verificações daquele dia que foram aprovadas. Passe o cursor sobre um dia para ver os números.
GET /api/health responde 200 com {"status":"ok"}.
Operacional
GET /api/v1/me sem credenciais recebe 401 da API: ela está no ar e recusa chamadas anônimas.
Operacional
POST /mcp como cliente MCP sem credenciais recebe 401: o servidor está no ar e pede OAuth.
Operacional
Nenhum deploy esperou na fila por mais de 20 minutos nem está em build há mais de 90 minutos.
Operacional
O destino CNAME para o qual os clientes apontam seus domínios resolve para o nosso ingress, e o proxy edge conclui o TLS e responde via HTTP.
Operacional
O servidor de caixas de e-mail responde via HTTPS e sua porta SMTP de envio responde com a saudação 220.
Operacional
O endpoint web e de API do Postal responde via HTTPS e sua porta SMTP responde com a saudação 220.
Operacional
Abertos automaticamente após 3 verificações com falha seguidas e fechados após 3 verificações aprovadas seguidas. Os últimos 90 dias, os mais recentes primeiro.
Nenhum incidente desde o início das medições, em 24 de set. de 2026.
As regras por trás de cada número acima. Nada nesta página é digitado à mão, exceto as notas da equipe sobre incidentes.
Um verificador no serviço de API da plataforma chama cada componente pelo mesmo caminho que a requisição de um cliente percorre — DNS público, o proxy edge e depois o serviço — e salva cada resultado no banco de dados da plataforma.
Três verificações com falha seguidas abrem um incidente; três verificações aprovadas seguidas o fecham. Ele começa na primeira verificação com falha e termina na primeira aprovada.
Verificações aprovadas divididas pelas verificações registradas no período, arredondado para baixo com duas casas decimais — uma única falha nunca aparece como 100 %. Dias sem verificações aparecem como sem dados, não como disponíveis.
O verificador roda no serviço de API. Enquanto esse serviço está fora do ar, nada é registrado: esses minutos aparecem como dados ausentes em vez de indisponibilidade, e esta página não consegue carregar. As verificações partem da própria rede da plataforma, não de outras regiões.
Os mesmos dados em JSON, de leitura livre sem conta: GET /api/v1/status
A documentação mostra onde cada recurso fica no painel e na CLI; a página para desenvolvedores cobre a API, e /api/v1/openapi.json documenta cada endpoint, incluindo este documento de status.
Estes números são medições, não uma promessa: nenhuma garantia de disponibilidade nem nível de serviço (SLA) é oferecido durante o período de desenvolvimento ativo. Termos de serviço