uptimelens/claude-plugins

Monitoreo de UptimeLens

Configura y ejecuta el monitoreo de uptime de UptimeLens en los propios recursos del cliente, a través del servidor MCP de UptimeLens. Esta habilidad convierte una solicitud de monitoreo ("monitorea esta URL", "¿qué debería vigilar después de este despliegue?", "¿qué está caído?", "abre un incidente") en la secuencia correcta de llamadas a herramientas MCP.

Cuándo usar esta habilidad

Úsala para la parte de configuración de monitoreo y gestión de incidentes del producto:

• Crear monitores HTTP/HTTPS, y recomendar cobertura después de un despliegue o para un nuevo servicio.
• Verificar qué está actualmente caído y hacer una investigación ligera (historial de estado, causa raíz por sonda, tiempo de respuesta/disponibilidad).
• Programar una ventana de mantenimiento para que un despliegue o trabajo planificado no notifique a nadie.
• Modelar dependencias de monitores para que una verificación descendente no alerte cuando su ascendente ya está caído.
• Abrir, actualizar o resolver incidentes.

Transfiere el control cuando la solicitud sea sobre responder a una notificación en lugar de monitorear: para confirmar o posponer una escalada activa, cubrir un turno, o inspeccionar ejecuciones de escalada, usa la habilidad uptimelens-on-call. Para una investigación profunda y guiada de la causa raíz de un incidente, prefiere el prompt MCP de solo lectura triage_incident (y la herramienta get_root_cause) en lugar de programar todo el análisis aquí.

Prerrequisitos

1. El servidor MCP de UptimeLens está conectado a este cliente. Las herramientas de lectura funcionan en todos los planes.
2. Acciones de escritura (create_monitor, update_monitor, pause_monitor, resume_monitor, register_monitor_dependency, delete_monitor_dependency, create_incident, post_incident_update, resolve_incident, cancel_incident, reopen_incident, save_postmortem, add_incident_action_item, create_maintenance, delete_maintenance) requieren un token de API de lectura-escritura y un plan Pro o superior. Con un token de solo lectura, las herramientas de escritura ni siquiera aparecen listadas; en el plan Gratuito devuelven FeatureNotAvailable.
3. Algunas herramientas de lectura están limitadas por plan. get_root_cause (de pago) y get_incident_analytics (Pro+) están restringidas estrictamente — por debajo del plan devuelven un error FeatureNotAvailable; manéjalo como los prerrequisitos de las herramientas de escritura a continuación (informa al usuario que el plan no es suficiente, no reintentes). Los percentiles de query_metrics están restringidos suavemente — los campos de percentiles devuelven null por debajo del plan Team, no un error.

Si una herramienta de escritura falta o devuelve FeatureNotAvailable, informa al usuario qué prerrequisito no se cumple en lugar de reintentar.

Herramientas

Estas herramientas provienen del servidor MCP de UptimeLens. Refiérete a ellas con el nombre completo como UptimeLens:<tool> — reemplaza UptimeLens por el nombre que se le haya dado al conector en este cliente, de lo contrario la herramienta podría no encontrarse.

Lectura (descubrimiento y contexto):

• UptimeLens:get_overview — empieza aquí para "¿qué está roto ahora mismo?": recuentos de monitores por estado, uptime de 24 horas, incidentes abiertos, y las fallas distintas agrupadas — cuarenta monitores que fallaron de la misma manera en el mismo objetivo vuelven como UNA interrupción en lugar de cuarenta filas. Usa list_monitors cuando necesites el inventario en sí (nombres, etiquetas, ids).
• UptimeLens:list_monitors — monitores con salud actual; filtra por status (up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance), nombre o etiquetas. La fuente de monitorId para casi todo lo demás, y la respuesta a "¿qué está caído?".
• UptimeLens:get_monitor — configuración y salud actual de un monitor (sin credenciales).
• UptimeLens:list_status_changes — historial de subida/bajada/degradación de un monitor con duraciones; la fuente del statusChangeId que necesita get_root_cause.
• UptimeLens:get_status_change — un cambio de estado con su contexto (cambio anterior y siguiente, el incidente y las ejecuciones de escalada que lo cubren) y un resumen por ubicación de las verificaciones a su alrededor: cuántas fallaron, firstDownAt, y la errorCategory más frecuente. Úsalo para saber dónde comenzó una interrupción y cómo se confirmó; disponible en todos los planes.
• UptimeLens:get_root_cause — diagnósticos de red por sonda para un cambio de estado: tiempos de DNS/conexión/TLS, traceroute, versión de TLS, días restantes de SSL, categoría de error. La fuente más rica de "por qué estaba caído" (plan de pago).
• UptimeLens:query_metrics — estadísticas de tiempo de respuesta y uptime para un monitor durante un período (resumen del período, no una serie completa; percentiles desde Team+).
• UptimeLens:get_monitor_availability — vista de SLA para un monitor: % de uptime, tiempo de inactividad, recuento de incidentes, MTTR, MTBF, estadísticas de tiempo de respuesta. Al leerlo: un uptimePct ausente significa que el período NO tuvo mediciones — NO es 100, así que di que el monitor no fue medido; longestIncidentSec es el tiempo de reloj de un incidente y PUEDE exceder el totalDowntimeSec medido — eso es esperado, no un error de datos; uptimePct está redondeado a dos decimales, por lo que una interrupción muy corta puede mostrar 100.00 junto a un tiempo de inactividad positivo; un mtbfSec/mttrSec ausente NO es cero.
• UptimeLens:get_uptime_report — la misma pregunta para toda la cuenta durante un período: uptime ponderado por tiempo, tiempo de inactividad, presupuesto de errores contra un objetivo de SLA, más lo que se rompió (causes) y dónde se confirmó (locations). Elige un período con un valor predefinido (last_month, last_30d, …) o fechas explícitas. Usa esto para "¿cómo fue el mes pasado?"; usa get_monitor_availability para un solo monitor.
• UptimeLens:list_monitor_dependencies — los monitores padre de los que depende un monitor (lo que debe estar arriba para que sus alertas se activen).
• UptimeLens:list_monitor_dependents — lo inverso: monitores que dependen de este — su radio de explosión, para distinguir causa raíz de síntoma.
• UptimeLens:list_incidents — incidentes, del más reciente al más antiguo; por defecto son los últimos 7 días a menos que pases startDate/endDate. Filtra por status, monitorId o source.
• UptimeLens:get_incident — detalle de un incidente más su línea de tiempo de actualizaciones y los monitores afectados.
• UptimeLens:get_incident_analytics — métricas de incidentes a nivel de flota durante un rango de fechas (MTTR, volumen/tendencia, desglose por gravedad/fuente, monitores principales) — Pro+.
• UptimeLens:list_maintenance — ventanas de mantenimiento; status=active responde a "¿hay algo en mantenimiento ahora mismo?".
• UptimeLens:list_status_pages / UptimeLens:get_status_page — lo que se publica a los clientes y qué monitores aparecen en una página (útil al decidir la cobertura).

Escritura (cambian el estado — ver "Confirmar antes de escribir"):

• UptimeLens:create_monitor — crea un monitor HTTP/HTTPS a partir de una URL. Consulta "Qué puede y no puede hacer create_monitor".
• UptimeLens:update_monitor — edita el nombre y/o intervalo de verificación de un monitor existente (id + name y/o intervalSeconds, al menos uno). Todos los demás ajustes (URL, tipo, autenticación, cabeceras, umbrales, regiones) se conservan intactos y no se pueden cambiar a través de MCP. Reversible e idempotente.
• UptimeLens:pause_monitor / UptimeLens:resume_monitor — detiene o reinicia el monitoreo activo de un monitor. Entrada: id. Reversible e idempotente.
• UptimeLens:register_monitor_dependency — declara una dependencia hijo→padre: mientras el padre esté caído, las alertas de caída del hijo se suprimen. Entrada: monitorId (hijo), parentId. Solo padre directo; se rechazan ciclos/auto-referencias.
• UptimeLens:delete_monitor_dependency — elimina un borde de dependencia por su id de registro (de list_monitor_dependencies); no elimina ningún monitor.
• UptimeLens:create_incident — abre un incidente. Consulta "Los incidentes se abren como borradores".
• UptimeLens:post_incident_update — agrega una actualización a la línea de tiempo (investigando/identificado/monitoreando) con un mensaje. Los suscriptores no reciben correo a menos que pases notifySubscribers=true (y solo si el incidente ya está publicado).
• UptimeLens:resolve_incident — marca un incidente como resuelto. Los suscriptores no reciben correo a menos que pases notifySubscribers=true (y solo si está publicado). Reversible mediante reopen_incident.
• UptimeLens:cancel_incident — cancela como false_alarm/duplicate/test; terminal (no se puede reabrir), excluido de analíticas. Silencioso por defecto.
• UptimeLens:reopen_incident — reabre un incidente previamente resuelto (uno cancelado no se puede reabrir).
• UptimeLens:save_postmortem — escribe (o sobrescribe) el cuerpo del postmortem de un incidente como markdown; status opcional de draft o in_review. Aquí es donde va la salida del prompt postmortem_draft — sin él, el borrador solo existe en el chat. La publicación sigue siendo un paso humano en el dashboard.
• UptimeLens:add_incident_action_item — agrega un elemento de acción de seguimiento a un incidente (título, más tipo, prioridad y fecha de vencimiento opcionales). La mitad de un postmortem que realmente cambia algo.
• UptimeLens:create_maintenance / UptimeLens:delete_maintenance — programa o cancela una ventana de mantenimiento que suprime alertas para sus monitores durante la ventana.

Flujo de trabajo principal: configurar monitoreo (especialmente después de un despliegue)

El descubrimiento es lo primero: casi toda escritura necesita un ID, o una decisión que solo el inventario actual puede informar. Copia esta lista de verificación y trabaja a través de ella:

Configurar monitoreo:
- [ ] 1. Ver la cobertura actual (list_monitors) — qué existe, qué falta, qué ya está caído
- [ ] 2. Para una nueva URL/servicio: verificar list_monitors en busca de un duplicado (create_monitor NO es idempotente)
- [ ] 3. Confirmar la(s) URL con el usuario, luego create_monitor (solo HTTP/HTTPS)
- [ ] 4. Conectar la topología si es relevante (register_monitor_dependency: la nueva verificación bajo su ascendente)
- [ ] 5. Si se está produciendo un despliegue/mantenimiento, silenciar el ruido (create_maintenance para la ventana)

Paso 1 — inventario. Llama a list_monitors. Para responder "¿qué está caído?", pasa status=["down"] (agrega degraded/unconfirmed-down si el usuario se refiere a "no saludable"). Esta es también la forma de detectar brechas: un servicio que el usuario acaba de desplegar sin un monitor coincidente.

Pasos 2-3 — crear, con cuidado. create_monitor no es idempotente — llamarlo dos veces para la misma URL crea dos monitores. Verifica primero list_monitors en busca de uno existente, y confirma la URL exacta con el usuario antes de crear. Consulta las restricciones a continuación.

Paso 4 — topología (opcional). Si el nuevo monitor está aguas abajo de algo que ya monitoreas (una aplicación detrás de una puerta de enlace, un servicio detrás de su base de datos), usa register_monitor_dependency con el nuevo monitor como monitorId y el ascendente como parentId para que el hijo no notifique cuando el ascendente sea el problema real.

Paso 5 — silenciar ruido de despliegue (opcional). Si el usuario está desplegando o haciendo trabajo planificado, usa create_maintenance para los monitores afectados durante la ventana para que el trabajo en sí no notifique.

Qué puede y no puede hacer create_monitor

create_monitor es una adición rápida: dale una URL, crea un monitor HTTP/HTTPS (se asume https cuando no se proporciona un esquema), el nombre por defecto es el host, y el intervalo de verificación y el grupo de alertas usan los valores predeterminados del inquilino.

No puede, a través de MCP: crear monitores que no sean HTTP (TCP/UDP, DNS, ping/ICMP, SSH, SMTP, etc.), o establecer autenticación, cabeceras personalizadas, aserciones de palabra clave/cuerpo, un intervalo específico, o grupos de alertas. Para cualquiera de esos, dile al usuario que termine la configuración en el dashboard — no finjas que el MCP puede configurarlos. Después de la creación, update_monitor puede cambiar el nombre y el intervalo de verificación de un monitor (solo esos dos — todo lo demás permanece en el dashboard). No existe una herramienta delete_monitor: para eliminar un monitor, dirige al usuario al dashboard.

Los incidentes se abren como borradores

create_incident siempre abre un borrador no publicado: no se muestra en ninguna página de estado y los suscriptores no son notificados. Un humano lo publica desde el dashboard. Dilo cuando crees uno, para que el usuario sepa que aún no es público. post_incident_update, resolve_incident, cancel_incident y reopen_incident envían correo a los suscriptores solo cuando pasas explícitamente notifySubscribers=true — el valor predeterminado de MCP es silencioso, porque el correo a los propios clientes del cliente no se puede recuperar. (El dashboard se comporta de manera opuesta: allí un humano presiona el botón.) cancel_incident es terminal (false_alarm/duplicate/test) y no se puede reabrir; resolve_incident es reversible mediante reopen_incident. Usa cancel para "esto no era real", resolve para "esto terminó".

Confirmar antes de escribir

Lee y recomienda libremente. Antes de cualquier escritura, indica lo que estás a punto de hacer y obtén la aprobación del usuario — estos cambios afectan lo que se monitorea, lo que notifica, o lo que se registra:

• Crear monitor: nombra la URL exacta. Como no es idempotente, confirma que ya no existe un monitor para ella (verificaste list_monitors).
• Pausar/reanudar: pausar detiene el monitoreo, por lo que una interrupción real no notificará mientras está pausado — confirma que el usuario realmente quiere silenciarlo.
• Mantenimiento: nombra los monitores y la ventana exacta (RFC3339; UTC por defecto, o pasa una timezone IANA como Europe/Madrid — las ventanas recurrentes son conscientes de DST); durante ella, las alertas se suprimen.
• Abrir/actualizar/resolver/cancelar incidente: nombra el incidente y, para resolver/cancelar, di si estás solicitando un correo al suscriptor (notifySubscribers=true) — por defecto no se envía ningún correo.

Prefiere la acción menos sorprendente, recomienda en lugar de crear a gran escala, y nunca abras o resuelvas incidentes en lote sin confirmación por incidente.

Escenarios comunes

"Monitorea https://api.ejemplo.com." list_monitors (verifica que no esté ya monitoreado) → confirma la URL → create_monitor(url). Si el usuario quería autenticación, una verificación de palabra clave o un protocolo que no sea HTTP, crea el monitor HTTP básico y dile que termine esos ajustes en el dashboard.

"Acabo de desplegar el servicio de facturación — ¿qué debería monitorear?" list_monitors para ver la cobertura actual → identifica las brechas (los nuevos endpoints públicos / verificaciones de salud sin monitor) y recomiéndaselos al usuario, en lugar de crearlos silenciosamente → tras confirmación, create_monitor para cada uno → si el nuevo monitor está detrás de algo que ya vigilas, register_monitor_dependency para ponerlo bajo ese ascendente. Señala lo que no se puede crear automáticamente (no HTTP, autenticación, palabras clave) y remítelo al dashboard.

"¿Qué está caído ahora mismo?" get_overview primero — responde "qué está caído" en lugar de listar cada monitor, agrupando interrupciones relacionadas → luego, list_monitors con status=["down"] para obtener la lista de IDs reales → para obtener más detalles sobre las fallas y determinar la causa raíz, usa get_status_change con cada statusChangeId único de los resultados de la lista: te da un resumen por ubicación de las verificaciones fallidas y la categoría de error más frecuente, suficiente para la mayoría de las preguntas iniciales sin necesidad del plan de pago get_root_cause, a menos que necesites diagnósticos de red por sonda.

"Programa una ventana de mantenimiento para el despliegue de esta noche." Confirma la lista de monitores afectados y la ventana exacta (inicio y fin en RFC3339, o con una zona horaria IANA) → create_maintenance. Advierte que las alertas de esos monitores se silenciarán durante la ventana.

"Abre un incidente para la interrupción de la API." create_incident con un título descriptivo → explica que se abre como borrador y no se publica en la página de estado hasta que un humano lo publique → si corresponde, pide más contexto (gravedad, monitores afectados) para adjuntarlo como actualización.

"Resuelve el incidente INC-123." Antes de resolver, confirma: get_incident para ver si sigue abierto, y luego pregunta al usuario si debe notificar a los suscriptores (notifySubscribers=true o no). Después de la resolución, sugiere redactar un postmortem si el incidente amerita uno.

"Escribe un postmortem para el incidente INC-123." Usa el prompt postmortem_draft para generar un borrador basado en los datos del incidente (puedes pasar incidentId y monitorId del contexto) → confirma el contenido con el usuario → save_postmortem para guardarlo como borrador → sugiere que un humano lo revise y publique en el dashboard. Si el usuario quiere un seguimiento, add_incident_action_item para cada elemento de acción.

Notas

• Zonas horarias para create_maintenance: El campo timezone acepta identificadores de zona horaria IANA (por ejemplo, America/New_York, Europe/Berlin, Asia/Tokyo, Australia/Sydney). Por defecto, la ventana está en UTC. Las ventanas recurrentes respetan los cambios de horario de verano. Pasa la zona horaria explícitamente cuando el usuario la mencione; de lo contrario, usa UTC.
• Los incidentes resueltos se pueden reabrir si realmente es necesario con reopen_incident, pero uno cancelado no. Usa cancel_incident para falsas alarmas, duplicados o pruebas.
• No existe delete_monitor en MCP. Eliminar un monitor requiere el dashboard.
• No existe delete_incident en MCP. Eliminar un incidente no es compatible; usa cancel_incident si no debería haber existido.
• El prompt postmortem_draft está disponible en el servidor MCP de UptimeLens (si tu cliente lo admite) para generar borradores de postmortem a partir de datos de incidentes. Úsalo antes de save_postmortem.