Documentação

Use o token do monitor ou um token de integração. Check-ins aceitos retornam 204. GET e HEAD também funcionam, então qualquer ferramenta de ping HTTP consegue fazer check-in.

• 401 quando o token de integração expirou.
• 404 quando o token não existe.
• 4xx para payloads JSON inválidos.

Reporte cada etapa de uma execução. Os três aceitam POST, GET e HEAD.

• /checkin/<token>/start: a execução começou. Não muda o estado do monitor.
• /checkin/<token>: a execução deu certo. Se vier depois de um start, a duração é registrada.
• /checkin/<token>/fail: a execução falhou. Você recebe um alerta na hora, com exitCode e message, sem esperar o intervalo e a tolerância.

Envie o mesmo runId (no corpo ou como ?rid=) no início e no fim para ligar os dois quando as execuções se sobrepõem. Sem ele, o fim fecha a execução aberta mais recente.

Defina a Duração máxima no monitor (maxRuntimeSeconds na API): uma execução que começou e não deu certo nem falhou dentro desse tempo gera um alerta de travada, uma única vez.

runId, exitCode e message ligam a execução e explicam uma falha. Para agentes de IA e jobs de LLM:

Todas as chaves são opcionais e ficam guardadas com a execução. Sozinhas, elas não disparam alertas.

GitHub Actions

Agende o workflow e envie um check-in no fim do job. Guarde o token em secrets.

- name: CronObserver check-in
  if: success()
  run: curl -fsS --retry 3 -X POST "$CRONOBSERVER_CHECKIN_URL"
  env:
    CRONOBSERVER_CHECKIN_URL: ${{ secrets.CRONOBSERVER_CHECKIN_URL }}

GitLab CI

Use os agendamentos do GitLab e um stage final de notificação para enviar o check-in.

cronobserver:checkin:
  stage: notify
  image: curlimages/curl:8.11.1
  script:
    - curl -fsS --retry 3 -X POST "$CRONOBSERVER_CHECKIN_URL"
  only:
    - schedules

Kubernetes CronJob

Guarde a URL em um Secret e injete no container do CronJob. O check-in acontece depois que o script termina. Sua imagem precisa ter curl (alpine: apk add --no-cache curl).

env:
- name: CRONOBSERVER_CHECKIN_URL
  valueFrom:
    secretKeyRef:
      name: cronobserver-checkin
      key: url
...
command: ["sh", "-c", "run-job && curl -fsS --retry 3 -X POST $CRONOBSERVER_CHECKIN_URL"]

AWS Lambda

Use um agendamento do EventBridge para invocar a função e envie um check-in no fim.

await fetch(process.env.CRONOBSERVER_CHECKIN_URL, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ status: "success", message: "Lambda ok" })
});

Docker Compose

Defina a URL como variável de ambiente e rode o curl depois que o job terminar. Sua imagem precisa ter curl (alpine: apk add --no-cache curl). O $$ impede que o Compose substitua a variável antes de o container subir.

services:
  job:
    image: curlimages/curl:8.11.1
    environment:
      - CRONOBSERVER_CHECKIN_URL=https://cronobserver.com/checkin/<token>
    command: sh -c "run-job && curl -fsS --retry 3 -X POST $$CRONOBSERVER_CHECKIN_URL"

Há dois tipos de token para check-ins:

• Token do monitor: permanente e ligado ao monitor.
• Token de integração: temporário, revogável e com validade (formato it_*). Ideal para CI/CD e ambientes compartilhados.

Guarde os tokens em secrets ou variáveis de ambiente e evite comitá-los em repositórios.

Disponível no Orbital (US$ 1,90/mês). No plano Free, os alertas são só por e-mail.

Checks sintéticos são sondas ativas executadas pelo CronObserver. Em vez de esperar um check-in, o sistema envia requisições HTTP para uma URL configurada e valida se a resposta é a esperada.

• Tipos suportados: httpGet e httpPost.
• Validação pelo status esperado (por exemplo, 200). Se o status for diferente, o check falha.
• Controle de timeout e medição do tempo de resposta.
• Proteção contra SSRF: bloqueia IPs privados e localhost (allowlist opcional).

Quando um check sintético falha, o monitor registra o erro e envia alertas. Quando ele se recupera, um evento de recuperação também é enviado.