Páginas de status
Uma página que os seus próprios clientes podem ler, mostrando o que está no ar e o que não está, hospedada por nós para que responda quando a sua infraestrutura não responde.
Como construir uma
Crie a página e depois adicione componentes a ela. Um componente é um monitor que você escolheu publicar, com um nome que os seus clientes vão entender — “Checkout” em vez de prod-api-lb-01. Agrupe-os em seções se houver o bastante para precisar disso.
Adicionar um componente é o ato de publicar aquele monitor. O estado dele, o histórico e os incidentes passam a ser visíveis para qualquer pessoa que tenha o link. Nada mais do monitor é exposto — nem a URL, nem a configuração, nem de onde a verificação foi feita — mas o fato de estar no ar ou fora do ar se torna público. Esse é o objetivo, e vale a pena ser deliberado sobre quais monitores você adiciona.
Você só pode adicionar monitores do mesmo espaço de trabalho da página. Em uma conta de agência, é isso que impede que o monitor de um cliente apareça na página de outro.
Onde ela fica
Toda página recebe imediatamente um endereço no nosso domínio. A partir do Starter, você pode apontar o seu próprio domínio para ela — status.suaempresa.com.br — e nós cuidamos do certificado.
A partir do Pro, a página pode levar a sua marca: o seu logo e as suas cores, e nenhuma menção a nós.
Incidentes na página
Um incidente aberto pelo monitoramento aparece automaticamente. Você também pode publicar um à mão para algo que não conseguimos ver — um terceiro degradado, uma migração planejada — e atualizá-lo conforme ele evolui. As atualizações têm data e hora e são mantidas, de modo que a página é um registro depois, e não apenas um retrato durante.
Uma janela de manutenção programada é publicada na página — o título, a descrição e quando é a próxima — desde que “mostrar nas páginas de status” esteja ligado, e ela também aparece nos feeds da página. Os assinantes podem ser avisados de quando ela começa e de quando termina. Ela segura os alertas enquanto está aberta, mas não reescreve o número de disponibilidade: a menos que você também desligue “continuar verificando”, as verificações rodam como sempre e contam como sempre.
Assinantes
Os visitantes podem se inscrever para receber um e-mail quando algo mudar. Eles confirmam primeiro, e toda mensagem leva uma saída que funciona sem entrar na conta: quem recebe uma atualização de status é cliente de outra pessoa, e pedir que crie uma conta para parar de receber mensagens não solicitadas é como uma página ganha uma reclamação de spam.
Esses endereços são dados pessoais que você coletou e que guardamos para você. Eles são seus: exporte-os ou apague-os quando quiser.
Páginas privadas
Defina uma senha e a página vai pedi-la antes de mostrar qualquer coisa. Útil para uma página interna ou para uma compartilhada com um único cliente sob acordo.
O desbloqueio fica lembrado em um cookie daquela página específica, então desbloquear uma não desbloqueia outra — e um visitante que desbloqueou uma página sempre recebe a versão ao vivo, e não uma cópia em cache.
O que deliberadamente não mostramos
Em nenhum lugar de uma página de status nomeamos de onde uma verificação foi feita. Nem na página, nem em um incidente, nem na API. Onde uma verificação roda é decisão nossa e mudança nossa — as sondas se movem entre hosts e localidades — então um código de região diante dos seus clientes é uma afirmação sobre a nossa infraestrutura que envelhece sem ninguém notar, e não é algo sobre o qual eles possam agir.
Feeds
Toda página pública publica seus incidentes como feed, nos dois formatos que os leitores entendem: /feed.xml para RSS e /atom.xml para Atom, cada um ao lado do endereço da própria página. Os dois são linkados a partir da página, então a maioria dos leitores os encontra só pela URL.
Um feed é como alguém acompanha você sem entregar um endereço de e-mail. Ele leva exatamente o que a página leva — os incidentes dos últimos trinta dias, as atualizações que você marcou como públicas e as janelas de manutenção que você escolheu publicar — e nada além disso: nenhuma nota interna, nenhum post-mortem e nada sobre de onde uma verificação foi feita.
Uma página protegida por senha ou restrita não serve nenhum feed. Não há como pedir uma senha a um leitor de feeds, então ali um feed seria um jeito de contornar a barreira, não um recurso.
Velocidade e disponibilidade
As páginas de status são cacheadas na borda e servidas a partir de uma cópia que sobrevive à queda da nossa própria origem. Essa é toda a razão de hospedar uma página de status em outro lugar que não aquilo sobre o que ela informa: uma página inacessível exatamente durante a queda pela qual alguém a acompanha falhou na sua única tarefa.