Por que o monitoramento de API é diferente#

Seu site pode estar "up" enquanto sua API está quebrada. Os usuários veem uma homepage que carrega bem, mas a funcionalidade do app da qual eles dependem está completamente inoperante.

Exemplo: sua página de checkout carrega (o site está no ar ✅), mas a API de pagamentos falha (o site está quebrado ❌). Os clientes não conseguem finalizar as compras. A receita para.

O monitoramento de API detecta essas falhas invisíveis.

O que precisa de monitoramento de API#

Gateways de pagamento (Stripe, PayPal, Square)
Endpoints de autenticação (login/logout)
APIs de dados (listagens de produtos, dados de usuários)
Webhooks (dados recebidos de terceiros)
Endpoints de busca
APIs de upload de mídia

Códigos de status HTTP em APIs#

APIs usam códigos de status HTTP de forma diferente de sites:

Site:

200 OK: a página carrega
500 Server Error: o site está quebrado

API:

200 OK: requisição bem-sucedida
400 Bad Request: o cliente enviou dados errados
401 Unauthorized: falha na autenticação
403 Forbidden: permissão negada
404 Not Found: endpoint não existe
429 Too Many Requests: limite de taxa atingido
500+ Server Error: backend quebrado

Diferença principal: uma API pode retornar 200 OK com um erro no corpo JSON.

Exemplo:

{
  "status": 200,
  "success": false,
  "error": "Payment processing failed"
}

O HTTP diz "OK", mas a API na verdade falhou. O monitoramento básico de uptime não percebe isso.

Configurando monitoramento de API#

Passo 1: identifique endpoints de API críticos#

Liste todo endpoint de API que é crítico para o seu negócio:

/api/auth/login (usuários não conseguem fazer login se isso falhar)
/api/payments/create (usuários não conseguem fazer checkout)
/api/users/profile (o app trava se isso falhar)
/webhooks/stripe (pagamentos não são registrados se isso falhar)

Passo 2: defina a validação de resposta#

Para cada endpoint, decida o que significa estar "up":

Verificação básica (status HTTP):

Endpoint retorna 200 ou 201 = OK

Verificação intermediária (status + tempo de resposta):

Endpoint retorna 200 E responde em menos de 1 segundo

Verificação avançada (status + conteúdo do corpo):

Endpoint retorna 200 E o corpo da resposta contém os dados esperados

Passo 3: configure a ferramenta de monitoramento#

No Nova Uptime:

Adicione o domínio: https://api.yourdomain.com
Para cada endpoint crítico, adicione como um monitor separado:
- /api/auth/login
- /api/payments/create
- etc.
Configure validação do corpo da resposta, se disponível
Defina limiares de alerta (2 falhas consecutivas antes de alertar)

Avançado: validação do corpo da resposta#

Alguns endpoints exigem um formato de resposta específico.

Exemplo: endpoint de criação de pagamento

Resposta esperada:

{
  "success": true,
  "payment_id": "pay_12345",
  "amount": 99.99
}

Configuração de monitoramento:

Verifique se a resposta contém "success": true
Se estiver faltando, o endpoint está "quebrado" mesmo que o status HTTP seja 200

O Email Health Checker do Nova Uptime valida corpos de resposta — esse mesmo princípio se aplica ao monitoramento de API.

Tokens de autenticação no monitoramento de API#

A maioria das APIs exige autenticação. Para monitorá-las:

Opção 1: criar uma chave de API de teste

Gere uma chave de API dedicada para o monitoramento
Use essa chave em todas as requisições de monitoramento
Essa chave só tem permissões de leitura (não pode modificar dados)
Use essa chave na ferramenta de monitoramento

Opção 2: endpoint público

Algumas APIs têm endpoints sem autenticação (health check, status)
Monitore esses no lugar
Exemplo: GET /api/health (público, sem auth necessária)

Monitoramento de webhooks#

Webhooks são mais complicados. Eles são recebidos (você os recebe, não envia para eles).

Monitore o endpoint que recebe os webhooks:

Exemplo: a Stripe envia POST para https://yourdomain.com/webhooks/stripe

Como monitorar:

Crie um remetente de webhook de teste (disparado manualmente)
Verifique se o endpoint o aceita e retorna 200
Cheque os logs para confirmar que o webhook foi processado

Ou use monitoramento sintético:

Configure uma requisição POST sintética para o endpoint do webhook
Inclua um payload de teste
Verifique se ele foi recebido e processado

Monitoramento do tempo de resposta#

APIs não são só sobre estar no ar ou fora do ar. Elas também são sobre velocidade.

API lenta = API quebrada (do ponto de vista do usuário).

Defina limiares de tempo de resposta:

Endpoint de autenticação: menos de 200ms
Endpoint de pagamento: menos de 500ms
Endpoint de busca: menos de 1000ms (mais complexo)

Se um endpoint leva 5 segundos para responder, mesmo que ele "funcione", os usuários enfrentam timeouts e abandonam.

Considerações sobre rate limiting#

APIs frequentemente aplicam rate limit para prevenir abuso.

Problema: seu monitoramento envia uma checagem por minuto. Com 1.000 monitores, isso dá 1.000 requisições por minuto. Se sua API tem rate limit de 100/minuto, o monitoramento é bloqueado.

Solução:

Crie uma chave de API separada para monitoramento (com rate limit alto)
Ou reduza a frequência das checagens (a cada 5 minutos em vez de 1)
Ou use um endpoint interno /health que não tenha rate limit

Erros comuns no monitoramento de API#

Erro 1: monitorar produção com operações destrutivas#

Não monitore:

POST /api/users/delete    ← Deleta usuários a cada checagem
POST /api/billing/charge  ← Cobra o cartão a cada checagem

Monitore operações somente leitura no lugar:

GET /api/users/{id}
GET /api/health

Erro 2: incluir autenticação na URL#

Não faça:

GET /api/endpoint?auth_token=SECRET

Isso coloca segredos nos logs. Use headers no lugar:

Authorization: Bearer SECRET_TOKEN

Erro 3: não testar endpoints de webhook#

Webhooks são críticos, mas frequentemente não são testados. Seu processador de webhook pode estar completamente quebrado e você nunca vai saber.

Solução: envie webhooks de teste regularmente e verifique se eles estão sendo processados.

Monitorando dependências da API#

Sua API pode depender de serviços externos:

Banco de dados (se ele cair, a API cai)
Fila de mensagens (Redis, RabbitMQ)
Cache (Memcached)
APIs externas (Stripe, Twilio)

Monitore essas separadamente:

Endpoint de health check do banco de dados
Endpoint de status do cache
Página de status da API de terceiros

Configurando alertas para falhas de API#

Quando o monitoramento de API detecta uma falha:

O alerta deve incluir:

Qual endpoint falhou
Qual foi a falha (timeout vs erro 500)
Quando começou
Mudanças recentes (se disponíveis)

Severidade do alerta:

Crítica: API de pagamento/autenticação (usuários bloqueados)
Alta: API de busca/dados (usuários frustrados)
Média: analytics/logging (erros visíveis aos usuários)

Monitoramento de API no Nova Uptime#

O Nova Uptime monitora o uptime da API junto com o uptime do site:

Adicione o domínio da sua API: https://api.yourdomain.com
Configure o monitoramento dos endpoints
Receba alertas via email/Slack
Veja o histórico de incidentes e os tempos de resposta
Screenshots automáticos das falhas (para debug)

Mais o monitoramento de email health — se sua API envia emails transacionais, o Nova Uptime checa automaticamente SPF/DKIM/DMARC no mesmo dashboard.

Resumo#

Liste os endpoints de API críticos
Defina o que "up" significa para cada um (código de status, tempo de resposta, conteúdo do corpo)
Crie monitoramento para cada um
Defina limiares de tempo de resposta
Monitore dependências (banco de dados, cache, terceiros)
Teste webhooks regularmente
Alerte sobre falhas imediatamente

Comece a monitorar sua API hoje: Monitoramento de API do Nova Uptime. Inclui uptime + email health no mesmo dashboard. 🚀

Monitoramento de Uptime para APIs: Monitorando Endpoints e Webhooks