Relatório de disponibilidade: template

O problema de quem factura manutenção é que o sucesso é invisível. Um mês em que nada correu mal parece, do lado de lá, um mês em que ninguém fez nada — e é sempre nesse mês que alguém pergunta ao que corresponde aquela linha da factura.

Um relatório de disponibilidade — template em baixo, pronto a copiar — resolve isto por um custo desproporcionado ao efeito: vinte minutos, uma vez por mês, por cliente.

As cinco regras que decidem se é lido.

Antes da estrutura, o que importa mais.

Uma página. Não duas. Um relatório de três páginas não é lido, é arquivado. O que não couber numa página não é para o relatório — é para uma conversa.

Escrito para quem paga, não para quem monitoriza. Um percentil 95 não convence ninguém de nada. “O site esteve acessível 99,94% do tempo” convence.

O número primeiro, o detalhe depois. Quem lê quer saber se correu bem antes de saber porquê.

Sem gráficos que precisem de legenda. Se é preciso explicar o eixo, o gráfico está a trabalhar contra ti.

Sempre, e não só quando corre bem. Um relatório que só aparece nos meses bons é publicidade, e o cliente vai reparar. O mês mau é precisamente aquele em que enviar isto vale mais.

O relatório de disponibilidade: template para copiar.

Copia, substitui o que está entre parênteses rectos, e apaga o que não se aplicar.

Relatório de disponibilidade — [Cliente] — [Mês de Ano]

Resumo

O site esteve acessível [99,94]% do tempo em [Março]. Houve [1] interrupção, com a duração total de [26 minutos].

[Se houver compromisso contratual:] O compromisso do contrato de manutenção é de [99,5]%.

Incidentes

Início	Fim	Duração	O que aconteceu
[14/03, 09:12]	[14/03, 09:38]	[26 m]	[O servidor do alojamento reiniciou e o site demorou a voltar. Ficou resolvido sem intervenção.]

[Se não houve nenhum:] Não houve interrupções registadas neste período.

Tempo de resposta

Tempo médio de resposta: [340 ms]. [No mês anterior foi de 310 ms / Sem alteração significativa face ao mês anterior.]

Outras verificações

Certificado de segurança: válido até [12 de Junho]. [Renovação automática a funcionar.]
Registo do domínio: válido até [3 de Novembro].
Cópias de segurança: [diárias, última verificação de restauro a 2 de Março].

Notas

[Uma a três linhas. O sítio para o que não cabe nas tabelas: uma actualização feita, uma recomendação, um risco identificado. Se não houver nada, apaga a secção.]

Como isto é medido

O site é verificado a cada [minuto] a partir de [Portugal]. Uma falha só é contada depois de confirmada por uma segunda verificação, para que um problema momentâneo de rede não conte como interrupção.

Porque é que cada peça está lá.

O resumo é a única coisa que muita gente vai ler. Tem de funcionar sozinho, e tem de ter o número. Se a pessoa parar na primeira linha, ficou a saber o que precisava.

A tabela de incidentes é a prova. Sem datas e durações concretas, o relatório é uma opinião. Com elas, é um registo — e é o que impede a discussão de “o site esteve em baixo várias vezes este mês” no trimestre seguinte.

O tempo de resposta faz o trabalho nos meses em que não há nada a relatar. Mostra que a vigilância aconteceu mesmo, e apanha a degradação lenta antes de ela virar falha.

A secção “como isto é medido” é a que mais gente corta e a que mais evita conflitos. Duas ferramentas dão números diferentes para o mesmo mês, consoante o intervalo, a origem da verificação e o que contam como estar em baixo. Declarar o método uma vez, em três linhas, resolve a discussão antes de ela existir.

Os quatro erros mais comuns.

Mandar a captura de ecrã do painel. Não é comunicação, é matéria-prima. Se o cliente tem de interpretar, não comunicaste.

Escrever códigos de estado em bruto. 502 Bad Gateway não diz nada a quem paga. “O servidor do alojamento não respondeu” diz.

Não enviar nos meses limpos. São os mais valiosos: um relatório com zero incidentes é a prova mais barata de que a manutenção está a fazer o que promete.

Culpar o alojamento em todos os relatórios. É verdade em muitos casos e péssimo em série — o cliente não distingue “o alojamento falhou” de “vocês escolheram este alojamento”.

O que é preciso para o produzir.

Três dados, e um deles é onde isto costuma encalhar:

A percentagem de disponibilidade do período. Qualquer ferramenta de monitorização a dá.
A lista de incidentes com início e fim. Idem.
O histórico do mês inteiro, disponível quando fores escrever o relatório. É aqui que os planos gratuitos ficam pelo caminho: com sete ou trinta dias de retenção, um relatório mensal escrito no dia 5 já perdeu o princípio do mês anterior.

Se a tua ferramenta apaga, a solução caseira é exportar todos os meses para uma folha de cálculo. É trabalho manual e resolve.

Onde a De Olho entra, e onde não entra.

O relatório de disponibilidade — template gerado por nós — é uma das peças do lançamento: uma página com a disponibilidade do período, os incidentes e a marca de quem envia em vez da nossa. É para isso que o histórico não expira nos planos pagos — um relatório anual, na altura da renovação da avença, é o momento em que este tipo de produto se paga a si próprio. Está descrito em relatórios por cliente.

O que não vamos fazer no lançamento: enviar o relatório ao cliente por ti. Geramos a página; quem decide o que sai e quando és tu. E não vamos ter cálculo de penalizações contratuais — isso é território de SLA e exige um rigor de medição que não prometemos.

Também vale dizer o óbvio: um relatório não melhora a disponibilidade em nada. Não muda o alojamento nem previne falhas. O que faz é transformar o teu trabalho invisível em qualquer coisa que existe do lado de lá — e, no mês em que correu mal, ser tu a contar a história primeiro.

Se o contrato tiver uma percentagem prometida, o relatório deixa de ser um resumo e passa a ser prova — e isso é SLA de disponibilidade, que tem regras próprias sobre o que se exclui e como se mede.

A De Olho abre em 2026. Quem entrar na lista de espera sabe primeiro e fica com o preço de lançamento enquanto a subscrição durar.