Owl Keeper

Funciones

Comprobar si responde es la mitad fácil.

Cualquier cosa puede avisarte de que un servidor dejó de responder. Los fallos que de verdad te cuestan dinero —un certificado caducado un domingo, un dominio que nadie renovó, un correo en el que dejaron de confiar sin avisar, un noindex publicado por error— responden todos con un 200 perfectamente sano. Owl Keeper vigila todo eso en la misma página, para cada sitio y en todos los planes.

Lo que la mayoría de las herramientas te deja a ti

Las dos primeras filas son la categoría. El resto es la razón de ser de esto.

La pregunta Una herramienta de monitorización típica Owl Keeper
¿Responde el sitio? Comprobaciones HTTP, TCP y de correo, con la frecuencia que elijas.
¿Está a punto de caducar el certificado? Y si la cadena está completa y cubre realmente el nombre de host.
¿Está a punto de expirar el dominio? Leído del registro, no deducido de un raspado de WHOIS. A veces
¿Se ha quitado el bloqueo del registrador? La señal que precede al robo de un dominio. También DNSSEC. No
¿Llegará tu correo a una bandeja de entrada? SPF, DKIM, DMARC, MTA-STS y BIMI: con las consultas SPF contadas a través de cada include. No
¿Le está diciendo el sitio a los buscadores que se vayan? Un noindex olvidado o un robots.txt de staging que llegó a producción. No
¿Hacen algo las cabeceras de respuesta? HSTS, CSP, marcas de las cookies y si el HTTP sin cifrar sigue respondiendo. No
¿Hay alguien leyendo tus cookies? Una cookie de sesión sin Secure viaja en texto claro la primera vez que alguien escribe la dirección sin https. No
¿Puede un agente de IA usar este sitio? llms.txt, un catálogo de API, una ficha de servidor MCP y sobre qué rastreadores de IA opina el archivo robots. No
¿El formulario de contacto sigue aceptando envíos? Enviado de verdad, desde una dirección marcada, de modo que un formulario que ha dejado de entregar en silencio se detecta en horas. No
¿La copia de seguridad nocturna llegó a ejecutarse? La tarea llama a una URL cuando termina. Te enteras de la noche en que no lo hace. No
¿Qué ha cambiado desde la semana pasada? Solo se anotan las diferencias, así que el historial es la lista de lo que realmente cambió. No

Autenticación de correo

Las comprobaciones que otros venden como producto aparte

La autenticación del correo es el fallo de mecha más larga: nada se rompe, nada avisa y las facturas simplemente dejan de llegar. Normalmente es una suscripción aparte, de otro proveedor y con otro precio. Aquí es una de las pasadas diarias sobre cada dominio que añades.

SPF, contado como es debido

Se sigue cada include y se cuentan las consultas DNS por el camino. Pasar de diez es un error permanente que deja el registro con un aspecto perfectamente razonable: es la forma más común de que un dominio que entregaba deje de hacerlo.

DKIM y DMARC

Si los selectores que publicas resuelven y qué le indica realmente tu política DMARC al receptor. Una política «none» se informa como lo que es: publicada y sin efecto alguno.

MTA-STS y BIMI

La mitad más reciente: si el correo dirigido a ti debe viajar cifrado y si tu logotipo puede aparecer junto a él. Se informan como hechos, nunca como fallos.

MX que resuelve

Los registros existen, los hosts detrás de ellos existen y el servidor de correo responde de verdad a un saludo y ofrece STARTTLS.

Listas de bloqueo

Si el dominio o su host emisor ha aparecido en una lista que los receptores consultan antes de aceptar nada tuyo.

Se avisa una vez, no cada día

Un registro roto sigue roto hasta que alguien lo arregla. Se te avisa cuando se rompe, no cada mañana hasta que lo arregles: así es como un recordatorio acaba en un filtro.

Tareas programadas

La copia de seguridad que nadie notó que se había detenido

Una entrada de cron se pierde en una migración de servidor y la copia nocturna se detiene en silencio. No se rompe nada, no salta ninguna alerta y el sitio sigue respondiendo 200 durante meses, hasta la mañana en que alguien necesita restaurar, que es el día más caro posible para enterarse.

Esta es la única comprobación de aquí que funciona al revés. Tu tarea llama a una URL cuando termina y te avisamos cuando esa llamada no llega.

Una línea en un crontab

Añade un curl al final de la tarea que ya ejecutas. No hay nada que instalar, ningún agente y ninguna biblioteca que mantener.

Funciona detrás de un cortafuegos

No se solicita nada desde este lado, así que una tarea en una máquina sin dirección pública —un servidor de compilación, un portátil, el servidor de un cliente— informa exactamente igual.

Un periodo de gracia, para que no sea ruido

Una tarea que tarda cuatro minutos no va tarde a los cuatro minutos. Tú decides cuánto margen tiene una ejecución antes de contar como perdida.

La alerta dice cuándo se ejecutó por última vez

No «la tarea está caída», sino «la última ejecución fue hace nueve horas», que es la diferencia entre una pregunta y una respuesta.

Cuánto duró la ejecución

Una tarea que informa de su propia duración obtiene un historial de ella, así que la semana en que empezó a tardar cuatro veces más se ve antes de que empiece a fallar.

Se avisa una vez, no cada noche

Una tarea detenida sigue detenida hasta que alguien la arregla. Te enteras cuando se rompe, no cada mañana hasta que lo hagas.

Seguridad de la respuesta

Evaluadas, no solo enumeradas

Cualquier cosa puede imprimir las cabeceras que devuelve un sitio. La pregunta útil es cuáles faltan, cuáles están puestas en algo que no hace nada y cuál de ellas es un agujero y no una tarea de refuerzo pendiente.

HSTS con un número que va en serio

Presente no es lo mismo que efectivo. Un max-age de menos de unos seis meses lo olvida el navegador antes de que la mayoría renueve nada, y las listas de preload lo rechazan, así que uno corto se informa en lugar de darse por bueno.

Las cookies, que es donde suele estar el agujero

Una cookie de sesión sin Secure viaja en texto claro la primera vez que alguien escribe la dirección sin https. Es el único hallazgo aquí tratado como problema; el resto son refuerzos, y esa diferencia es justo el punto.

Una política de contenido y los marcos

Si existe siquiera una Content-Security-Policy y si algo impide que el sitio se muestre dentro de un marco, sea por la cabecera o por la política, ya que cualquiera sirve y solo una de ellas es la forma antigua.

Lo que el servidor reconoce

Server y X-Powered-By con números de versión son reconocimiento gratuito para cualquiera que busque un fallo conocido justo en esa versión.

Si el HTTP simple sigue respondiendo

Una redirección a HTTPS está bien. Que el puerto 80 rechace directamente la conexión es mejor, y la diferencia se informa en lugar de aplanarse.

Una cabecera que desaparece es un evento

Una política que estaba la semana pasada y hoy no está queda escrita en el historial del sitio, porque eso es un despliegue que nadie pretendía hacer.

Preparación para IA y agentes

¿Cuáles de tus clientes están listos para que los lea algo que no es una persona?

Una pregunta que ahora mismo nadie puede responder sobre su propia cartera y que los clientes empiezan a hacer. Cada sitio que añades se revisa buscando las convenciones que espera un agente de IA, en cuatro áreas: si se puede descubrir, si se puede leer su contenido, qué dice sobre los rastreadores y qué puede hacer realmente.

Se registran como hechos, nunca como fallos. No publicar nada de esto es un sitio web corriente, no uno roto, y para bastantes clientes rechazar a los rastreadores es precisamente el encargo.

llms.txt y Markdown

Si hay un resumen en texto plano en la raíz y si las propias páginas responden en Markdown cuando algo lo pide, en lugar de servir una página de marcado de framework.

Dieciocho rastreadores de IA por su nombre

GPTBot, ClaudeBot, PerplexityBot, Google-Extended y los demás. Que se nombre a uno ya es la señal: significa que alguien decidió, en vez de heredar lo que viniera por defecto. Si permitieron o bloquearon se informa, nunca se juzga.

Content Signals

La convención más reciente para decir qué puede hacer un rastreador con lo que se lleva: buscar, entrenar o responder directamente. Publicada o no, conviene saber cuál de las dos.

Un catálogo de API

Si existe /.well-known/api-catalog, que es como un sitio le dice a un agente qué ofrece en lugar de dejar que lo adivine a partir del HTML.

MCP y habilidades de agente

Una ficha de servidor en /.well-known/mcp o un índice de habilidades: las dos maneras de que un sitio entregue a un agente sus propios procedimientos en vez de confiar en que los deduzca.

Peticiones firmadas

Si el sitio está preparado para verificar firmas de mensajes HTTP, que es como acabará distinguiendo un agente real de algo que lleva puesto su user agent.

Certificados y dominios

Las dos fechas que sacan un sitio de internet

Certificados, comprobados más allá de la fecha de caducidad

Cuándo caduca, quién lo emitió, si la cadena está completa y si cubre el nombre de host que realmente sirve, incluidos los comodines, que cubren un nivel y no dos. Avisos a 30, 14, 7, 3 y 1 días.

El registro del dominio, leído del registro

Caducidad, registrador y estado directamente desde RDAP, no raspados de una página WHOIS. Los avisos empiezan a los 60 días, porque recuperar un dominio caducado es lento y caro, mientras que un certificado se reemite en minutos.

Bloqueo del registrador y DNSSEC

Que se quite el bloqueo es el paso previo a mover un dominio. Verlo como un cambio un martes es la diferencia entre una llamada y una recuperación.

Servidores de nombres y delegación

Quién es autoritativo para el dominio y si esa respuesta ha cambiado desde ayer. Se anota junto a todo lo demás del sitio, no en una página aparte.

Alertas

Una alerta que puedes permitirte creer

Una herramienta de monitorización solo vale la pena si sigues leyendo sus mensajes en el sexto mes. Todo aquí está pensado para no gastar tu atención.

Rechazado no es caído

Un cortafuegos que responde 401, 403 o 429 no te dice nada sobre si los visitantes llegan al sitio. Se informa como que se rechazó al comprobador, en ámbar, y la alerta nombra el agente de usuario que hay que permitir para arreglarlo en un solo paso.

Confirmación antes de la interrupción

Nada se da por caído hasta que ha fallado tantas veces seguidas como decidas. Un paquete perdido en una red inestable nunca se convierte en un mensaje.

La recuperación, no solo el fallo

Se te avisa cuando vuelve y cuánto tiempo estuvo caído, así que el incidente se cierra solo en vez de dejarte a ti comprobarlo.

Slack, Discord o JSON firmado

Pega una URL de Slack o Discord y los mensajes se formatean para ella. Cualquier otra cosa recibe JSON firmado con un HMAC, para que el receptor distinga nuestro POST del de cualquiera que haya averiguado la dirección.

En el idioma de quien la lee

Las alertas se escriben en el idioma de la cuenta a la que van dirigidas, así que a una persona se le puede avisar en rumano mientras un compañero recibe la misma alerta en inglés.

Pausar sin perder el historial

El mantenimiento planificado se salta la programación en vez de generar un incidente falso, y nada de lo ya registrado se descarta.

Cuando cuidas sitios de otros

La unidad es el sitio, no el monitor

Un cliente con un sitio web, una API, un servidor de correo y un certificado es una sola cosa que cuidar, y cuatro filas facturables en una herramienta que cobra por fila. Aquí un sitio lleva consigo su certificado, su registro, su DNS y sus registros de correo sin contar de más.

Etiquetas que filtran una cartera

Etiqueta por cliente, por proveedor de alojamiento o por como pienses de verdad, y reduce sesenta sitios a los cuatro por los que te preguntan.

Una página de estado que puedes enviar a un cliente

Disponibilidad, qué está respondiendo y cuándo se renuevan el certificado y el registro, en un enlace imposible de adivinar que nunca muestra nombres de monitores, direcciones ni nada de las comprobaciones de seguridad. Lo retiras y el enlace deja de funcionar.

Un historial hecho solo de cambios

Una comprobación que encuentra lo mismo que ayer no registra nada. Lo que puedes enseñarle a un cliente es la lista de lo que realmente cambió —el emisor, los servidores de nombres, la política DMARC— en vez de un año de filas idénticas.

Nada que rastree a tus clientes

Sin analítica, sin píxeles de rastreo, sin publicidad y sin scripts de terceros en ninguna parte del producto. Aquí no hay nada que tengas que meter a regañadientes en un acuerdo de tratamiento de datos.

Todas las comprobaciones, en todos los planes

Nada de esta página se reserva para un plan superior. Los planes se diferencian en cuántos sitios vigilas y con qué frecuencia, nunca en qué se comprueba.