Monitores de disponibilidade

Um monitor checa periodicamente um recurso seu do mesmo jeito que o usuário final o vê: de fora da plataforma, a partir de sondas em mais de uma região e em mais de um provedor de nuvem. Quando a queda é confirmada por mais de uma sonda, a plataforma abre um incidente, avisa pelas suas assinaturas de eventos e passa a contar o tempo fora do ar no SLA.

Tipos de checagem

Tipo	O que verifica	Sucesso
http	Uma URL HTTPS (ou HTTP, para checar o redirecionamento) do seu host	status no conjunto esperado (padrão 200-299), palavra-chave presente ou ausente nos primeiros 64 KB e resposta dentro do tempo limite
tcp	A abertura de conexão no endpoint TCP público	conexão aceita
tls	O certificado do host	handshake válido, cadeia confiável, nome coberto e dias até expirar acima dos limiares
dns	Um registro (A, AAAA, CNAME, TXT ou MX) do seu domínio	resposta igual ao valor esperado

Além de cair (DOWN), uma checagem pode ficar degradada (DEGRADED): uma resposta http acima do limiar de lentidão ou um certificado dentro do limiar de aviso (tls, padrão de 14 dias; o crítico é 7). Os motivos aparecem em cada checagem: timeout, connection_refused, dns_failure, status_mismatch, keyword_missing, keyword_present, slow, certificate_invalid, certificate_expiring e dns_mismatch.

Por padrão o monitor não segue redirecionamentos: um 301 é avaliado contra o conjunto esperado. Ligue "seguir redirecionamentos" quando quiser checar o destino.

Alvos permitidos

Os monitores só checam recursos da sua organização. O assistente de criação oferece os hosts que você já tem e nunca um campo livre:

• o hostname padrão de uma aplicação (<app>-<ambiente>-<org>.apps.<domínio>);
• um domínio próprio verificado (veja Domínios e TLS); monitores dns aceitam qualquer nome abaixo dele;
• um endpoint TCP público ativo (veja Acesso público TCP). A allowlist do endpoint precisa incluir os IPs das sondas: o portal oferece "adicionar IPs das sondas".

Qualquer outro host, um IP literal ou um domínio de outra organização é recusado com monitor.target_not_owned, sem dizer a quem ele pertence. Se o domínio, a aplicação ou o endpoint deixar a organização, o monitor é pausado com o motivo target_removed e as sondas deixam de checá-lo.

Locais e IPs das sondas

As sondas rodam fora do cluster da plataforma, em pelo menos duas regiões e com um provedor diferente:

Local	Onde
br-south	Azure, Brasil (São Paulo)
us-east	Azure, EUA (Virgínia, região diferente da do cluster)
eu-central	Hetzner, Alemanha (Falkenstein)

Os IPs de saída vigentes de cada local estão em GET /api/v1/probe-locations (e no assistente do portal). Eles já são liberados automaticamente pelo desafio de bots e nunca são banidos pela borda; se você tem um firewall próprio ou uma allowlist de endpoint TCP, libere esses IPs. As requisições usam o user-agent AtlasCloud-Monitor/1.0.

Cada sonda também recusa, por conta própria, alvos que resolvam para endereços privados, de loopback ou de metadados de nuvem.

Quórum e incidentes

Cada local muda de estado sozinho: fica DOWN depois de duas falhas seguidas, DEGRADED depois de duas checagens lentas seguidas e volta a UP na primeira checagem bem-sucedida.

O monitor só fica DOWN quando o número de locais DOWN atinge o quórum — 2 por padrão, nunca mais que o número de locais. Com um local só em falha, o monitor continua UP com o aviso "1 local com falha", sem incidente nem alerta: é a proteção contra um problema de rede de uma sonda.

Quando o quórum é atingido, um incidente é aberto com início no momento da confirmação. Ele fecha quando o número de locais DOWN fica abaixo do quórum em duas avaliações seguidas. No incidente você vê o início, o fim, a duração, os locais afetados e o primeiro motivo, e pode registrar notas (auditadas como monitor.incident_noted).

Um local sem resultado por 3 intervalos fica STALE e não conta para nenhum lado. Se todos os locais ficarem STALE, o monitor fica UNKNOWN: é uma falha das sondas, a operação da plataforma é alertada e você não recebe alerta de queda.

Alertas

Os monitores publicam eventos da categoria monitors no catálogo de notificações, entregues pelas suas assinaturas e canais (e-mail, in-app, Slack, Teams e webhook CloudEvents):

Evento	Quando
monitor.down	incidente aberto (um por incidente)
monitor.recovered	incidente fechado, com a duração
monitor.degraded	o monitor entrou em DEGRADED (só com "alertar quando degradado")
monitor.certificate_expiring	o certificado entrou no limiar de aviso ou no crítico (um por limiar e por certificado)
monitor.maintenance_started / monitor.maintenance_ended	início e fim de uma janela de manutenção

Os eventos trazem o nome do monitor, o host e os locais com falha — nunca o corpo da resposta nem o IP da sonda.

SLA

O SLA é calculado sobre os incidentes confirmados (não sobre a razão de checagens, para que um problema de uma sonda não reduza o seu número):

SLA = 1 − (tempo em incidente fora de manutenção) ÷ (duração do período − manutenção)

com 3 casas decimais. Exemplo: num mês de 30 dias com um incidente de 43 min 12 s, o SLA é 99,900%. O detalhe do monitor mostra as últimas 24 horas, 7, 30 e 90 dias e os três últimos meses civis. Um monitor mais novo que o período mostra o SLA do tempo que existe, marcado como parcial.

Janelas de manutenção

Uma janela de manutenção é pontual (início e fim) ou semanal (dias da semana, horário local e duração de até 24 horas), sempre com um fuso horário IANA explícito (como America/Sao_Paulo). Ela vale para todos os monitores de um projeto ou da organização, ou só para os monitores escolhidos.

Durante a janela as checagens continuam, mas o monitor fica MAINTENANCE, nenhum incidente é aberto e o tempo não conta no SLA. Se o serviço continuar fora do ar quando a janela termina, o incidente começa no fim da janela. Horários que não existem por causa do horário de verão andam para frente; horários repetidos usam a primeira ocorrência.

Uma janela pode ser publicada nas suas páginas de status como manutenção programada.

Histórico

Os resultados de cada checagem (local, status, tempo e motivo) ficam 7 dias, com paginação por cursor e filtro por local. Os agregados diários (checagens, falhas, tempo de resposta médio e p95, SLA do dia) ficam pela retenção do seu plano.

Planos

Chave	O que limita	Ao estourar
monitors.maxMonitors	monitores não pausados pelo plano	422 quota-exceeded ao criar ou retomar
monitors.minIntervalSeconds	menor intervalo entre checagens	400 plan.limit_exceeded no campo intervalSeconds
monitors.locations	locais por monitor	400 plan.limit_exceeded no campo locations
monitors.historyDays	retenção dos agregados diários	400 plan.limit_exceeded no campo from

Ao mudar para um plano menor, os monitores excedentes mais recentes são pausados com o motivo plan_limit (auditoria monitor.auto_paused); o intervalo e os locais gravados não mudam, mas as sondas passam a usar o piso e o teto novos. Voltando a um plano maior, retome os monitores pausados. Os valores de cada plano estão em Planos e limites.

Permissões e API

Todo membro com acesso ao projeto lê monitores, resultados, incidentes e SLA. Criar, editar (com If-Match), pausar, retomar, excluir, anotar incidentes e gerenciar janelas exige o papel Developer ou superior. Tokens de API usam os escopos monitors:read e monitors:write (veja Tokens de API).

Rota	Uso
GET/POST /api/v1/orgs/{org}/projects/{projeto}/monitors	listar e criar
GET/PUT/DELETE …/monitors/{id}	detalhe com SLA, edição e exclusão
POST …/monitors/{id}/pause e /resume	pausar e retomar
GET …/monitors/{id}/results?location=	checagens dos últimos 7 dias
GET …/monitors/{id}/stats?period=24h|7d ou ?from=AAAA-MM-DD	tempo de resposta por local ou agregados diários
GET …/monitors/{id}/incidents e POST …/incidents/{id}/notes	incidentes e notas
GET /api/v1/orgs/{org}/monitors	visão da organização
GET/POST /api/v1/orgs/{org}/maintenance-windows	janelas de manutenção
GET /api/v1/probe-locations	locais e IPs das sondas