UptimeLens Plantão

Plantão UptimeLens

Opere fluxos de trabalho de plantão e escalonamento do UptimeLens nos próprios recursos do cliente, através do servidor MCP UptimeLens. Esta skill transforma uma pergunta de alerta ("quem está de plantão?", "reconhecer página", "cobrir meu turno") na sequência correta de chamadas de ferramentas MCP.

Quando usar esta skill

Use-a para o lado operacional do alerta de incidentes:

• Descobrir quem está atualmente de plantão (ou por que ninguém está).
• Reconhecer ou silenciar um escalonamento ativo que está paginando alguém.
• Cobrir um turno substituindo uma rotação de plantão por um intervalo de tempo.
• Inspecionar execuções de escalonamento (páginas ativas + histórico) e políticas de escalonamento.

Para análise de causa raiz de um incidente (em oposição a gerenciar a página), prefira o prompt MCP somente leitura triage_incident ou as ferramentas de leitura get_incident, get_root_cause, list_status_changes e query_metrics. Esta skill permanece na camada de plantão/escalonamento e vincula ao contexto do incidente apenas quando ajuda a decidir quem deve agir.

Pré-requisitos

1. O servidor MCP UptimeLens está conectado a este cliente. As ferramentas de leitura funcionam em todos os planos.
2. Ações de escrita (acknowledge_escalation, bulk_acknowledge_escalation, resolve_escalation, snooze_escalation, escalate_escalation, create_on_call_override, update_on_call_override, delete_on_call_override, create_cover_request, accept_cover_request, decline_cover_request) exigem um token de API leitura-escrita e um plano Pro ou superior. Com um token somente leitura, as ferramentas de escrita nem sequer são listadas; no plano Gratuito, elas retornam FeatureNotAvailable.
3. Algumas destas ferramentas têm um segundo bloqueio por funcionalidade, além do bloqueio de plano, e nem todas são iguais:
   • create_on_call_override, update_on_call_override e accept_cover_request precisam do recurso substituição de plantão. Aceitar conta porque produz uma substituição ativa — exatamente o que o recurso vende. (Uma solicitação pendente criada em um plano pago e aceita após um downgrade criaria, de outra forma, uma substituição que o plano não inclui mais; essa lacuna foi fechada deliberadamente.)
   • create_cover_request precisa de um recurso diferente — solicitações de cobertura de plantão — para que um plano possa incluir um e não o outro.
   • delete_on_call_override e decline_cover_request são deliberadamente sem bloqueio: desfazer algo deve continuar possível após um downgrade; caso contrário, uma troca de turno que você não pode mais editar também é uma que você não pode mais cancelar. Qualquer uma delas pode retornar FeatureNotAvailable mesmo com um token de leitura-escrita.

Se uma ferramenta de escrita estiver faltando ou retornar FeatureNotAvailable, informe ao usuário qual pré-requisito não foi atendido, em vez de tentar novamente.

Ferramentas

Essas ferramentas vêm do servidor MCP UptimeLens. Referencie-as totalmente qualificadas como UptimeLens:<ferramenta> — substitua UptimeLens pelo nome que o conector recebeu neste cliente; caso contrário, a ferramenta pode não ser encontrada.

Leitura (descoberta e contexto):

• UptimeLens:list_on_call_schedules — horários; fonte do scheduleId que who_is_on_call e create_on_call_override precisam.
• UptimeLens:who_is_on_call — quem está de plantão para um horário agora mesmo; retorna gapReason quando ninguém está.
• UptimeLens:get_on_call_schedule — a escala futura para um horário nos próximos N dias (padrão 7, máx. 90): cada turno (quem, quando, rotação vs substituição), lacunas de cobertura com sua razão e um resumo de cobertura. Use para cobertura futura; who_is_on_call é apenas agora.
• UptimeLens:list_on_call_overrides — as substituições ativas e futuras para um horário; a fonte do id que update_on_call_override e delete_on_call_override precisam. Cada entrada carrega o usuário (quem assume o turno), o solicitante (requestedBy, definido apenas para uma solicitação de cobertura pendente — quem pediu a cobertura), janela, motivo e estado. Apenas uma substituição active é editável; uma entrada pending é uma solicitação de cobertura ainda aguardando aceitação do usuário alvo, e update_on_call_override a rejeitará. Substituições passadas não são listadas.
• UptimeLens:list_escalation_runs — execuções de escalonamento (páginas ativas + histórico); fonte do runId que acknowledge_escalation, snooze_escalation e escalate_escalation precisam. O progresso é baseado em 1: currentStep (o passo que o escalonamento atingiu), nextStep (dispara a seguir), totalSteps.
• UptimeLens:get_escalation_run — o estado completo de uma execução: qual passo o escalonamento atingiu e qual dispara a seguir (currentStep/nextStep de totalSteps), progresso de repetição, urgência, método de ack/resolução (POR QUE terminou), prazos de silêncio e timeout de ack, nextActionAt, incidente/monitor desencadeador.
• UptimeLens:get_escalation_run_timeline — o registro cronológico de eventos de uma execução: notificações, resultados de entrega, timeouts de ack, alvos ignorados, repetições, resolução — a fonte mais rica de "o que aconteceu / por que escalou".
• UptimeLens:list_escalation_policies — as regras de alerta de plantão.
• UptimeLens:get_escalation_policy — detalhes de uma política: passos ordenados numerados 1..N (os números currentStep/nextStep em list_escalation_runs se referem a eles), atraso de cada passo, estratégia de alvo e alvos. Resolva alvos de horário via who_is_on_call, alvos de usuário via list_team_members.
• UptimeLens:list_team_members — pessoas na equipe; fonte do userId que create_on_call_override precisa.

Escrita (mudança de estado — veja "Confirmar antes de escrever"):

• UptimeLens:acknowledge_escalation — parar de paginar para uma execução ativa. Entrada: runId.
• UptimeLens:resolve_escalation — fechar a página permanentemente. Entrada: runId. Ao contrário de reconhecer, uma execução resolvida nunca re-pagina, então use quando o problema subjacente estiver confirmado como corrigido — não como uma forma de fazer um alerta barulhento parar.
• UptimeLens:bulk_acknowledge_escalation — reconhecer muitas execuções ativas de uma vez. Entrada: runIds (1–50). Sucesso parcial: execuções já resolvidas/desconhecidas são contadas como ignoradas, não como erros. Use após list_escalation_runs(state=active) para limpar um lote.
• UptimeLens:snooze_escalation — pausar a paginação para uma execução por um número de minutos. Entrada: runId, durationMinutes (1–240).
• UptimeLens:escalate_escalation — paginar o próximo passo ainda não paginado agora em vez de esperar seu timer ("escalonar agora"). Entrada: runId. Nada é ignorado: o passo mostrado como nextStep dispara; após o último passo, a próxima repetição começa imediatamente e, sem repetição restante, a execução é fechada como exausta (nextStep é 0 — informe ao usuário que não há mais ninguém para paginar). A execução volta a ser ativa e sua urgência se torna high. Rejeitado para execuções de teste e execuções concluídas.
• UptimeLens:create_on_call_override — colocar um usuário de plantão para um horário durante uma janela. Entrada: scheduleId, userId, endAt; startAt opcional (padrão agora), reason. Requer o recurso de substituição de plantão (veja pré-requisitos).
• UptimeLens:update_on_call_override — editar uma substituição existente no local: alterar seu endAt ou reason e (apenas antes de começar) seu userId ou startAt. Entrada: id (do resultado de create_on_call_override, ou descoberto via list_on_call_overrides quando você não acabou de criá-lo) mais os campos a serem alterados; omita um campo para deixá-lo inalterado. É assim que você encurta, estende ou reassina uma cobertura; use delete_on_call_override quando a troca não deve acontecer. Requer o recurso de substituição de plantão.
• UptimeLens:delete_on_call_override — excluir uma substituição completamente: a troca é cancelada e a rotação regular se aplica novamente. Entrada: id. Use isto em vez de editar quando a cobertura não deve acontecer.
• UptimeLens:create_cover_request — pedir a um colega para assumir uma janela em vez de atribuí-la: cria uma solicitação pending e envia um e-mail ao alvo, que deve aceitar antes que se torne uma substituição ativa. Entrada: scheduleId, userId (quem está sendo perguntado), startAt, endAt; reason opcional. Use create_on_call_override quando pretende atribuir o turno imediatamente sem perguntar.
• UptimeLens:accept_cover_request — aceitar uma solicitação de cobertura pending → ela se torna uma substituição ativa (o usuário alvo assume o turno). Entrada: id (uma entrada pending de list_on_call_overrides). Apenas o usuário alvo ou um administrador pode aceitar.
• UptimeLens:decline_cover_request — recusar uma solicitação de cobertura pending (nenhuma substituição é criada). Entrada: id (uma entrada pending de list_on_call_overrides). Apenas o usuário alvo ou um administrador pode recusar.

Fluxo de trabalho principal: lidar com um alerta de plantão

A maioria das ferramentas de escrita precisa de um ID que apenas uma ferramenta de leitura pode fornecer, então sempre descubra primeiro. Copie esta lista de verificação e trabalhe através dela:

Resposta de plantão:
- [ ] 1. Encontre as execuções de escalonamento ativas (list_escalation_runs, state=active, isTest=false)
- [ ] 2. Escolha a execução em questão (classifique por startedAt; verifique urgência e currentStep/totalSteps)
- [ ] 3. Adicione contexto se útil (incidentId → get_incident; triggeringMonitorId → list_status_changes → get_root_cause)
- [ ] 4. Decida: reconhecer (assumir, paginação para) ou silenciar (pausar N minutos, paginação retoma)
- [ ] 5. Confirme a ação com o usuário e, em seguida, chame a ferramenta de escrita com o id da execução

Passo 1 — encontrar execuções ativas. Chame list_escalation_runs com state="active". Use isTest=false para páginas reais desencadeadas por incidentes; isTest=true são execuções de teste "pagie-se" e não devem ser tratadas como incidentes ao vivo.

Passo 2 — escolher a execução. Cada execução tem um id (este é o runId para ferramentas de escrita), urgency (alta/baixa), currentStep de totalSteps (até onde o escalonamento subiu — baseado em 1; maior significa que mais pessoas foram paginadas; nextStep é quem será pago a seguir) e startedAt. Quando várias estão ativas, classifique por startedAt (mais antigo primeiro) e destaque urgência high primeiro.

Passo 3 — contexto (opcional). Se a execução tiver um incidentId, chame get_incident para impacto e linha do tempo. Se tiver um triggeringMonitorId, chame list_status_changes com esse id de monitor para ver suas mudanças recentes de up/down e, em seguida, get_root_cause com um statusChangeId dessa lista para diagnósticos de rede por sonda. Use isso apenas para ajudar o usuário a decidir; não inicie uma investigação completa aqui.

Passo 4 / 5 — agir. Escolha entre reconhecer, silenciar ou escalonar (abaixo), confirme, então escreva.

Reconhecer, resolver, silenciar ou escalonar

• Reconhecer (acknowledge_escalation) significa "eu assumo isso agora" — a paginação para enquanto você trabalha. Esta é a resposta certa para "assumir", "entendi" ou "silenciar" uma página. Reconhecer uma execução que não está mais ativa retorna um erro EscalationRunAlreadyResolved — inofensivo (já foi reconhecida ou resolvida); relate como já tratada e não tente novamente.

• Resolver (resolve_escalation) significa "isso acabou" — a execução é fechada permanentemente e nunca re-pagina. Use quando o usuário disser que o problema subjacente está corrigido, não apenas que estão cuidando dele. Uma execução também se resolve sozinha quando seu incidente é resolvido, então resolver manualmente é para o caso em que a página sobreviveu ao problema. Como não pode ser desfeito, prefira reconhecer quando estiver em dúvida.

• Silenciar (snooze_escalation) significa "silencie por durationMinutes, depois pagine novamente" — um adiamento, não uma assunção. Não é idempotente: cada chamada redefine a janela de silêncio para agora + N minutos, então chamá-lo novamente estende o silêncio. Use a menor duração que se encaixe (1–240) e nunca silencie em vez de reconhecer quando o alerta realmente precisa de um responsável.

• Escalonar agora (escalate_escalation) significa "isso precisa de mais pessoas, agora" — o nextStep da execução é pago imediatamente em vez de após sua espera, a urgência se torna high (horários de silêncio não se aplicam mais) e uma execução reconhecida se torna ativa novamente. Use quando o usuário disser que o respondedor atual não pode lidar com isso ou ninguém está respondendo; é o oposto de silenciar, então nunca chame ambos na mesma execução em um único ciclo. Informe ao usuário qual passo será pago (nextStep de get_escalation_run).

Reconhecer a execução errada silencia uma página real e ninguém é alertado, então confirme que o runId corresponde ao alerta que o usuário quer.

Lacunas de cobertura

who_is_on_call retorna um gapReason quando ninguém está de plantão:

• schedule_disabled — o horário está desligado; a política depende de outros alvos.
• no_active_rotations / no_rotation_members — o horário não tem ninguém designado para paginar agora.
• outside_active_window — está fora do horário ativo deste horário.

Quando há uma lacuna e alguém precisa assumir a página, create_on_call_override coloca um usuário específico de plantão por uma janela. Descubra scheduleId via list_on_call_schedules e userId via list_team_members (membros da equipe não expõem email ou telefone — corresponda por nome/função).

who_is_on_call apenas relata a lacuna acontecendo agora. Para encontrar lacunas antes que paginem alguém, chame get_on_call_schedule para o horário — seu array gaps lista cada janela descoberta nos próximos N dias com as mesmas razões, e coveragePercent resume quão bem o período está coberto. Este é o companheiro proativo de who_is_on_call.

Confirmar antes de escrever

Leia e trie livremente. Para as ferramentas de escrita, declare o que você está prestes a fazer e obtenha a aprovação do usuário primeiro — estas mudam quem é paginado:

• Reconhecer / silenciar: nomeie a execução (urgência, o que a desencadeou) e, para silenciar, os minutos.
• Resolver: diga claramente que a página está sendo fechada para sempre e não re-paginará. Pergunte se o problema subjacente está realmente corrigido — "faça parar" é um pedido para reconhecer ou silenciar, não resolver.
• Substituição: nomeie o horário, o usuário e a janela exata (startAt–endAt, UTC RFC3339). Se a janela ultrapassar a meia-noite, a data de endAt é o dia seguinte; endAt deve ser depois de startAt.
• Excluir substituição / recusar solicitação de cobertura: nomeie de quem é o turno que volta para a rotação regular. Cancelar uma cobertura muda quem é paginado tanto quanto criar uma.

A maioria destas são reversíveis — uma substituição pode ser editada ou encurtada, um ack ou silêncio pode re-escalonar — então o objetivo é uma decisão humana clara, não uma barreira de permissão. Duas não são:

...