Watchbit, el monitor de uptime ultraligero

Hace años que gestiono varias páginas web y siempre he tenido la misma preocupación: enterarme antes que nadie de que una de ellas ha caído. No hay nada peor que recibir un mensaje de un usuario preguntando si la web está funcionando, tener que ir a comprobarlo tú mismo, y descubrir que efectivamente lleva horas caída. Por eso, hace tiempo instalé Uptime Kuma, una herramienta fantástica, muy fácil de configurar, y que durante años me ha salvado de más de un disgusto. Sin embargo, con el tiempo empecé a notar algo que no terminaba de gustarme. El consumo. Y no hablo de un par de megas aquí y allá. Hablo de 140 megas de RAM, una imagen Docker de 400 megas, y un uso de CPU que no es despreciable cuando tienes varios servicios monitorizados. Así que después de darle muchas vueltas, decidí hacer lo que cualquier informático haría en mi situación: crearme mi propia herramienta. Y así nació Watchbit, un monitor de uptime ultraligero escrito en Rust con frontend en React, base de datos SQLite y autenticación OIDC contra Pocket ID. El resultado es que he pasado de 140 megas de RAM a unos 7 megas. La imagen Docker apenas pesa 20 megas. Y la CPU ni se entera. Te cuento la historia completa.

El problema: Uptime Kuma y su apetito voraz

No quiero que malinterpretes lo que voy a decir. Uptime Kuma es una herramienta extraordinaria. De hecho, es el monitor de uptime open-source más popular con diferencia, más de 91.000 estrellas en GitHub y cerca de 200 millones de descargas Docker hablan por sí solas. Está escrito en Node.js con Vue 3, Vite y Socket.io, y su punto fuerte es la facilidad de uso. Lo configuras en dos minutos, tienes un panel precioso con gráficos, estadísticas, y un montón de notificadores. Es, sin duda, la opción recomendada para el 90% de los casos.

Pero tiene un problema, y es que Node.js no es precisamente conocido por su eficiencia en recursos. Cada proceso Node.js lleva consigo todo el runtime, el event loop, el garbage collector, y una capa de abstracción que, para una tarea relativamente simple como hacer peticiones HTTP cada cierto tiempo y comprobar si el servicio responde, resulta excesivo.

En mi servidor, Uptime Kuma consumía de forma consistente entre 130 y 150 megas de RAM en reposo. La imagen Docker, basada en Node.js, pesaba unos 400 megas comprimida. Y el uso de CPU, aunque no era dramático, se notaba. Sobre todo cuando tienes el monitor haciendo checks cada minuto a varios servicios. Con el tiempo, y a medida que fui añadiendo más sitios web que monitorizar, empecé a preguntarme si no habría una alternativa más ligera.

Y no es que tenga un servidor justo de recursos. Pero soy de los que piensan que cada mega cuenta. Si una herramienta puede hacer el mismo trabajo con 7 megas en lugar de 140, ¿por qué conformarse con lo que consume más?

Probé algunas alternativas. Gatus, escrito en Go, prometía un consumo mucho menor, unos 15-25 megas de RAM, pero su configuración es puramente YAML, sin interfaz gráfica que permita gestionar los monitores de forma visual. Vigil, escrito en Rust, bajaba el consumo a 5-10 megas, pero tampoco tiene una interfaz web que permita ver el estado de los servicios de un vistazo. Statping estaba bien, pero el proyecto quedó abandonado. Upptime es interesante porque funciona sobre GitHub Actions y no consume recursos locales, pero depende de un servicio externo.

Ninguna me acababa de convencer. Así que tomé una decisión drástica: iba a crear mi propia herramienta.

Watchbit: la solución ultraligera

Watchbit nace de esa necesidad. Un monitor de uptime que hiciera exactamente lo que necesito, comprobar que mis servicios responden, avisarme cuando fallan, y consumir lo mínimo posible, pero sin renunciar a una interfaz gráfica decente.

El resultado es una herramienta que, en su estado actual, consume unos increíbles 7 megas de RAM. Siete. La imagen Docker pesa 20 megas. El uso de CPU es de aproximadamente un 0.2%. Para que te hagas una idea, esos números son tan pequeños que podrías ejecutar Watchbit en una Raspberry Pi Zero y te sobrarían recursos para otras cosas. De hecho, ese era uno de mis objetivos: que funcionara en cualquier sitio, incluso en el hardware más limitado.

Pero no solo de consumo vive el monitor. Watchbit incluye:

• Un dashboard con diseño por tarjetas donde ves de un vistazo el estado de todos tus servicios
• 8 tipos de notificadores diferentes para que te avisen cuando algo falla
• Heartbeats para monitorizar servicios que no tienen una URL accesible
• Autenticación OIDC contra un proveedor externo, sin gestionar usuarios tú mismo
• Backup con un solo comando — la base de datos es un archivo SQLite
• Un solo binario estático que funciona en cualquier sistema Linux

La filosofía es clara: minimalismo sin sacrificar funcionalidad. No tiene todas las campanas y silbatos de Uptime Kuma, pero tiene lo necesario. Y lo que no tiene, probablemente no lo necesitas.

Stack técnico: Rust + React + SQLite + OIDC

Vale, vamos al meollo técnico, que sé que es lo que más os interesa. ¿Cómo está construido Watchbit para conseguir ese consumo tan ridículo?

Backend en Rust con Axum y Tokio

El backend está escrito en Rust, y no es casualidad. Rust tiene varias ventajas que lo hacen ideal para una herramienta de monitorización:

1. Cero runtime. No hay garbage collector, no hay máquina virtual, no hay nada que consuma memoria innecesaria. Lo que ves es lo que hay.
2. Compilación a binario estático. Un solo archivo, sin dependencias externas. Lo copias donde quieras y funciona.
3. Concurrencia eficiente. Con tokio como runtime async, puedes tener cientos de tareas simultáneas, cada una haciendo un check HTTP, sin apenas consumo adicional.
4. Seguridad de memoria. El compilador garantiza que no haya null pointers, buffer overflows, ni fugas de memoria. Para un servicio que tiene que estar funcionando 24/7, esto es oro.

El framework web es Axum, construido sobre tokio y tower, que proporciona un ecosistema de middlewares muy completo. ¿Por qué Axum y no Actix-web? La verdad es que los dos son excelentes, pero Axum me pareció más natural si ya estás usando tokio. Se integra de forma nativa con tower para temas como CORS, compresión, rate limiting, y el sistema de extractors es muy limpio. Además, al estar mantenido por el equipo de tokio, la compatibilidad está garantizada. Actix-web tiene un modelo de actores que, siendo potente, añade complejidad que para un proyecto como Watchbit no necesitaba. Con Axum tienes un router funcional, extractors tipados, y middlewares encadenables. Suficiente y sin sobreingeniería.

Para las peticiones HTTP a los servicios monitorizados, se usa reqwest, el cliente HTTP más popular del ecosistema Rust. Lo elegí porque soporta HTTP/2, timeout configurables, cabeceras personalizadas, y redirecciones de forma nativa. Todo lo que necesita un monitor de uptime para hacer peticiones a servicios web. Además, al usar reqwest con tokio, las peticiones son asíncronas y no bloquean el hilo principal, lo que permite tener decenas de monitores ejecutándose en paralelo sin apenas impacto en el consumo.

Para la base de datos, rusqlite, que son bindings directos a SQLite. Podría haber usado diesel o sqlx, que son ORMs más completos, pero para un proyecto pequeño como Watchbit añaden complejidad sin aportar mucho valor. rusqlite te da acceso directo a la API de SQLite con tipado seguro en tiempo de compilación, sin capas de abstracción intermedias. Las queries son SQL plano, que es lo más eficiente que puedes tener. Y al no haber un ORM de por medio, el binario resultante es más pequeño y arranca más rápido.

En cuanto al motor de plantillas, uso minijinja, que es un port de Jinja2 a Rust. Sí, en el frontend uso React, pero para cosas como los emails de notificación o la página de estado pública, tener un motor de plantillas del lado del servidor es mucho más práctico que montar un componente de React para cada cosa. minijinja es ultraligero, no tiene dependencias pesadas, y la sintaxis es la misma que la de Jinja2, con la que llevo años trabajando en Python.

Frontend en React y TypeScript

El frontend está hecho con React y TypeScript. No es el típico React hinchado con mil dependencias. Es un React funcional, con componentes sencillos, que muestra el estado de los monitores en un diseño de tarjetas. Sin librerías de estado global, sin routers complejos, sin toolchains enormes. Un create-react-app ligero, con TypeScript para tener tipado seguro, y Tailwind CSS para los estilos. Justo lo que necesita un dashboard de monitorización.

La comunicación con el backend es vía REST API, con alguna pequeña parte de WebSocket para actualizaciones en tiempo real. Cuando un monitor cambia de estado, de online a offline o viceversa, el dashboard se actualiza al instante sin necesidad de recargar la página. Esto lo conseguí con tokio-tungstenite en el backend y el API nativa de WebSocket en el navegador, sin librerías intermedias como Socket.io. Menos dependencias, menos consumo, menos cosas que pueden fallar.

Base de datos SQLite

Aquí he tomado una decisión que quizá no guste a todos, pero que tiene todo el sentido del mundo: SQLite como base de datos. Sin servidor, sin demonio, sin configuración. La base de datos es un solo archivo que puedes copiar con un cp y tienes el backup hecho.

Para el volumen de datos que maneja Watchbit, unos cuantos checks cada minuto, el histórico de eventos, la configuración de los monitores, SQLite es más que suficiente. Y al estar embebido dentro del binario de Rust, no hay procesos adicionales, ni conexiones pool, ni memoria caché innecesaria. La base de datos está en el mismo proceso que la aplicación, sin latencia de red, sin sockets, sin nada.

La crate rusqlite proporciona bindings directos a la API de SQLite, con tipado seguro en tiempo de compilación. Es rápido, fiable, y no necesita mantenimiento. Y si en el futuro necesito más concurrencia de lectura, SQLite soporta modo WAL (Write-Ahead Logging) que permite lecturas concurrentes sin bloqueos. Para el uso que le doy, ni siquiera he necesitado activarlo.

Autenticación OIDC con Pocket ID

Otra decisión de diseño interesante es que Watchbit no gestiona usuarios. No hay registro, no hay recuperación de contraseña, no hay 2FA que implementar. Toda la autenticación se delega en un proveedor OIDC externo.

En mi caso uso Pocket ID, un proveedor OIDC ultraligero escrito en Go que solo permite autenticación con passkeys (WebAuthn). Sin contraseñas. Te identificas con tu huella dactilar, con tu cara, o con una llave USB. Es rápido, seguro, y no tienes que recordar ninguna contraseña.

El flujo de autenticación es el estándar OIDC Authorization Code Flow:

1. Intentas acceder a Watchbit
2. Watchbit te redirige a Pocket ID
3. Te autenticas con tu passkey
4. Pocket ID te redirige de vuelta a Watchbit con un código
5. Watchbit intercambia el código por tokens y te deja pasar

La ventaja de este enfoque es que un solo proveedor OIDC sirve para todas tus aplicaciones autohospedadas. Configuras Pocket ID una vez, y todas las herramientas que tengas, Watchbit o cualquier otra que soporte OIDC, lo usan sin tener que crear usuarios en cada una. Y si algún día quieres cambiar de proveedor, puedes pasar de Pocket ID a Authentik, a Authelia, o incluso a Keycloak, sin tocar una línea de código en Watchbit. Solo cambias las variables de entorno de OIDC y listo.

Comparativa de consumo: números que hablan solos

Vamos a los números, que es lo que realmente importa. He hecho mediciones en mi servidor con ambos contenedores ejecutándose simultáneamente, monitorizando exactamente los mismos servicios.

Recurso	Uptime Kuma	Watchbit	Reducción
RAM	~140 MB	~7 MB	95%
Imagen Docker	~400 MB	~20 MB	95%
CPU (reposo)	~2%	~0.2%	90%
Disco (datos)	~50 MB	~5 MB	90%

La diferencia es abismal. Y no es que Uptime Kuma esté mal hecho, es que Node.js, por su propia naturaleza, necesita todos esos recursos. El runtime de Node.js, el event loop, el garbage collector, todo eso ocupa. Y para una aplicación que básicamente hace peticiones HTTP cada cierto tiempo y actualiza una base de datos, es como usar una excavadora para plantar una maceta.

Con Watchbit, el binario estático de Rust ocupa unos 8 megas. La base de datos SQLite, con varios meses de histórico, ocupa unos pocos megas. Y la memoria RAM se mantiene estable en torno a los 7 megas, independientemente del número de monitores que tengas configurados.

En mi servidor, ejecuto Watchbit junto a una docena de otros servicios en un VPS de 2 gigas de RAM. Antes, solo Uptime Kuma se llevaba 140 megas. Ahora, Watchbit consume 7. La diferencia es que puedo tener un par de servicios más sin preocuparme por la memoria.

Instalación y configuración

La instalación de Watchbit es sencilla, sobre todo si ya tienes Docker y docker-compose en tu servidor. El docker-compose.yml tiene un aspecto como el que te muestro a continuación:

services:
  watchbit:
    image: atareao/watchbit:latest
    container_name: watchbit
    restart: unless-stopped
    ports:
      - 3000:3000
    volumes:
      - ./watchbit-data:/data
    environment:
      - WATCHBIT_OIDC_ISSUER=https://pocketid.tudominio.com
      - WATCHBIT_OIDC_CLIENT_ID=watchbit
      - WATCHBIT_OIDC_CLIENT_SECRET=tu-secreto
      - WATCHBIT_OIDC_REDIRECT_URI=https://watchbit.tudominio.com/auth/callback
      - WATCHBIT_DATABASE_PATH=/data/watchbit.db
      - WATCHBIT_PORT=3000

Como ves, la configuración se hace mediante variables de entorno. Vamos a repasar cada una para que sepas exactamente qué hace:

• WATCHBIT_OIDC_ISSUER: la URL de tu proveedor OIDC. En mi caso, Pocket ID. Esta URL es la que Watchbit usa para descubrir los endpoints de autenticación mediante el well-known endpoint (/.well-known/openid-configuration). Asegúrate de que sea accesible desde el contenedor de Watchbit.
• WATCHBIT_OIDC_CLIENT_ID: el identificador que le das a Watchbit en tu proveedor OIDC. En Pocket ID, lo configuras desde el panel de administración, creando una nueva aplicación. Yo lo llamé simplemente watchbit.
• WATCHBIT_OIDC_CLIENT_SECRET: el secreto compartido entre Watchbit y tu proveedor OIDC. Lo generas desde Pocket ID cuando creas la aplicación. Guárdalo en un lugar seguro, porque si lo pierdes, tienes que generar uno nuevo.
• WATCHBIT_OIDC_REDIRECT_URI: la URL a la que Pocket ID redirigirá al usuario después de autenticarse. Debe coincidir exactamente con la que configures en Pocket ID, si no, el flujo OIDC fallará. El formato es siempre https://tu-dominio/auth/callback.
• WATCHBIT_DATABASE_PATH: dónde quieres que Watchbit guarde la base de datos SQLite. Yo la pongo en /data/watchbit.db porque es el volumen que he montado, pero puedes ponerla donde quieras. Recuerda que si no montas un volumen, perderás los datos al recrear el contenedor.
• WATCHBIT_PORT: el puerto en el que Watchbit escuchará. Por defecto es el 3000, pero si ya tienes algo en ese puerto, puedes cambiarlo.

Si no tienes Pocket ID instalado, te recomiendo que le eches un vistazo. Su instalación es igual de sencilla:

services:
  pocketid:
    image: ghcr.io/pocket-id/pocket-id:latest
    container_name: pocket-id
    restart: unless-stopped
    ports:
      - 8443:8443
    volumes:
      - ./pocketid-data:/data
    environment:
      - POCKET_ID_PUBLIC_URL=https://pocketid.tudominio.com

Una vez que tienes ambos servicios funcionando, el siguiente paso es configurar un notificador. Watchbit incluye 8 tipos de notificadores, así que tienes donde elegir.

Notificadores: cómo te avisa Watchbit

De nada sirve un monitor de uptime si no te avisa cuando algo falla. Watchbit incluye 8 tipos de notificadores diferentes, cada uno con sus ventajas. Te explico cómo configurar los más importantes:

Telegram

El que uso yo personalmente. Creas un bot con @BotFather, obtienes un token, y configuras el chat al que enviar los mensajes. Las notificaciones llegan al instante, con el nombre del servicio que ha caído y el código de error.

Para configurarlo, necesitas dos cosas: el token del bot y el chat ID. El token lo consigues así: abres Telegram, buscas @BotFather, envías /newbot, sigues los pasos, y te da un token con este formato: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11. El chat ID es el identificador numérico de la conversación. Puedes obtenerlo enviando un mensaje a @userinfobot o, si eres más técnico, haciendo una petición a la API de Telegram.

curl -s -X POST "https://api.telegram.org/bot<TOKEN>/sendMessage" \
  -d "chat_id=<CHAT_ID>" \
  -d "text=🔴 atareao.es ha caído - HTTP 503"

En el panel de Watchbit, solo tienes que seleccionar Telegram como notificador, pegar el token y el chat ID, y ya está. Las notificaciones te llegarán con el nombre del servicio, el código de error, y la hora exacta de la caída.

NTFY

Un sistema de notificaciones basado en pub-sub HTTP. Te suscribes a un tópico y recibes las notificaciones en tu móvil. Es increíblemente simple: un curl a una URL y ya está. Tiene apps nativas para Android e iOS, y puedes auto-hospedarlo tú mismo.

Para configurarlo en Watchbit, solo necesitas la URL del tópico. Si usas la instancia pública de NTFY, sería algo como https://ntfy.sh/mi-topic-watchbit. Si lo auto-hospedas, sería https://ntfy.tudominio.com/mi-topic. Además, NTFY soporta autenticación básica si quieres proteger tu tópico, y puedes configurar prioridades y etiquetas para que las notificaciones sean más informativas. En Watchbit, seleccionas NTFY, pones la URL del tópico, y si tu instancia requiere autenticación, introduces usuario y contraseña.

Gotify

Similar a NTFY, pero 100% auto-hospedado. Tiene app para Android y una API REST muy limpia. Si quieres mantener todo en tu infraestructura sin depender de servicios externos, Gotify es tu opción.

La configuración es sencilla: instalas Gotify en tu servidor, creas una aplicación desde su panel web, y te genera un token. En Watchbit, seleccionas Gotify como notificador, pones la URL de tu servidor Gotify (por ejemplo, https://gotify.tudominio.com) y el token de la aplicación. Y listo. Las notificaciones te llegarán con el título del monitor y el mensaje de error.

Matrix

Para los que ya están en el ecosistema Matrix descentralizado. Configuras un bot y recibes las notificaciones en tu sala de Matrix. Es más complejo de configurar que Telegram o NTFY, pero si ya usas Matrix, la integración es natural.

Necesitas un homeserver de Matrix, una sala donde recibir las notificaciones, y un token de acceso. Puedes obtener el token usando el cliente de Matrix o con una llamada a la API. En Watchbit, introduces el homeserver (por ejemplo, https://matrix.tudominio.com), el room ID (el identificador interno de la sala, que empieza por !), y el token de acceso. A partir de ahí, cada vez que un monitor falle, recibirás un mensaje en tu sala de Matrix.

Discord Webhooks

Si tienes un servidor de Discord, los webhooks son la forma más rápida de recibir notificaciones. Un simple POST a la URL del webhook y tienes el mensaje con formato rico, colores, y todo.

Para configurarlo, vas a la configuración de tu canal de Discord, entras en Integraciones, creas un Webhook, y copias la URL. En Watchbit, seleccionas Discord, pegas la URL del webhook, y ya está. Las notificaciones llegarán con el nombre del servicio en negrita, el código de error, y un color rojo si está caído o verde si se ha recuperado.

Email SMTP

El clásico de toda la vida. Configuras un servidor SMTP, puede ser el de Gmail, el de tu proveedor de correo, o uno propio con Postfix, y recibes los avisos por correo electrónico. No requiere apps adicionales, pero tiene el inconveniente de que puede acabar en la carpeta de spam.

En Watchbit, necesitas configurar el servidor SMTP (host y puerto), si usa TLS o SSL, tu usuario y contraseña, y la dirección de correo desde la que se enviarán los avisos. Luego, introduces las direcciones de correo a las que quieres que lleguen las notificaciones. Puedes poner varias separadas por comas.

La configuración de los notificadores se hace desde el propio panel de Watchbit, sin necesidad de tocar archivos de configuración. Añades el notificador, introduces los parámetros necesarios, y ya está listo para funcionar. Y lo mejor es que puedes tener varios notificadores activos a la vez. En mi caso, tengo Telegram como principal y email como backup, por si acaso.

Heartbeats y monitores en Watchbit

Una de las características que más me gustan de Watchbit son los heartbeats. No todos los servicios tienen una URL accesible para hacer un check HTTP. Por ejemplo, un servicio que corre en segundo plano, un proceso que no expone un puerto, o un dispositivo IoT que envía datos periódicamente.

Para estos casos, Watchbit permite configurar un heartbeat. El servicio envía un ping periódico a Watchbit, una simple petición HTTP, y si el heartbeat deja de recibirse durante un tiempo configurado, Watchbit dispara la notificación.

Te pongo algunos casos de uso concretos que tengo en mi propio servidor:

• Backup programado con cron. Tengo un script que hace backup de mis bases de datos cada noche a las 3 AM. Al final del script, añadí una línea que hace una petición HTTP a Watchbit para indicar que el backup se ha completado. Si un día el heartbeat no llega, significa que el backup falló, y Watchbit me avisa al instante. Así no tengo que esperar al día siguiente para darme cuenta de que algo fue mal.
• Script de mantenimiento. Ejecuto un proceso semanal que rota logs y limpia archivos temporales. Mismo patrón: al terminar, envía un heartbeat. Si no lo recibo, sé que el script no se ejecutó y puedo revisarlo.
• Proceso batch de sincronización. Tengo un trabajo que sincroniza datos entre dos servidores cada hora. El heartbeat me confirma que la sincronización se ha completado sin errores. Si el heartbeat se pierde, puedo actuar antes de que los datos se desincronicen por completo.
• Conexiones VPN. Tengo un túnel VPN que debe estar siempre activo. Un script en el servidor envía un heartbeat cada 5 minutos. Si Watchbit deja de recibirlo, es que la VPN ha caído, y me entero antes de que nadie me lo diga.

El heartbeat se configura indicando la URL que Watchbit debe exponer para recibir los pings, y el intervalo máximo de tiempo sin recibir un ping antes de considerar que el servicio ha fallado. Por ejemplo, si un backup se ejecuta cada 24 horas, pones un timeout de 26 horas para dar margen. Si no llega el ping en ese tiempo, Watchbit dispara la alerta.

Los monitores tradicionales, por otro lado, funcionan como esperarías: Watchbit hace una petición HTTP a la URL que le configures, comprueba que el código de respuesta es el esperado (200, 301, etc.), y si no lo es, o si la petición timed out, marca el servicio como caído y envía la notificación.

Puedes configurar el intervalo de check, el timeout, y el método HTTP. También puedes añadir cabeceras personalizadas para servicios que requieran autenticación. Por ejemplo, si monitorizas una API interna que necesita un token Bearer, puedes configurar la cabecera Authorization: Bearer tu-token directamente desde el panel.

7 razones para migrar de Uptime Kuma a Watchbit

Si todavía no te he convencido, aquí van siete razones de peso para dar el salto:

1. Consumo de recursos. Esta es la razón principal, la que me llevó a crear Watchbit. 7 megas de RAM frente a 140. 20 megas de imagen Docker frente a 400. 0.2% de CPU frente a 2%. Los números no engañan. Y no es solo la diferencia en frío, es que cuando tienes varios servicios monitorizados y el número de checks crece, la diferencia se acentúa. Con Watchbit, añadir un monitor más apenas incrementa el consumo. Con Uptime Kuma, cada monitor adicional se nota en la RAM y la CPU. Para que te hagas una idea, con Watchbit puedes monitorizar 50 servicios y el consumo seguirá siendo de unos 7-8 megas. Con Uptime Kuma, con 50 servicios estarías rondando los 200 megas.

2. Binario estático. Un solo archivo. Lo descargas, le das permisos de ejecución, y funciona. Sin Node.js, sin npm, sin dependencias. En cualquier Linux, en cualquier arquitectura. Esto es especialmente útil si quieres ejecutarlo en un contenedor mínimo desde scratch, sin una imagen base de 400 megas. El binario de Rust incluye todo lo necesario, compilado de forma estática. Lo mueves a un servidor sin runtime instalado y funciona a la primera.

3. Backup con un cp. La base de datos es SQLite. Para hacer un backup, copias el archivo. Para restaurar, pegas el archivo. No hay volcados SQL, no hay comandos complejos, no hay que parar servicios. En mi servidor tengo un cron que cada noche ejecuta cp /data/watchbit.db /backups/watchbit-$(date +%Y%m%d).db y ya tengo el backup hecho. Si algo falla, restauro el archivo y Watchbit arranca exactamente donde lo dejó, con todo el histórico de eventos y la configuración de los monitores.

4. Autenticación delegada. No gestionas usuarios. No hay registro, no hay recuperación de contraseñas, no hay 2FA que mantener. Pocket ID hace todo eso por ti, y encima con passkeys. Te autenticas con tu huella dactilar o con una llave USB, sin escribir contraseñas. Y si tienes otras aplicaciones que soporten OIDC, todas comparten el mismo inicio de sesión. Un solo punto de autenticación para todo tu ecosistema self-hosted.

5. Ideal para Raspberry Pi. Si tienes una Raspberry Pi Zero o un servidor con recursos limitados, Watchbit es perfecto. Consume tan poco que puedes tenerlo funcionando junto a otros servicios sin notarlo. En una Raspberry Pi 3, que tiene 1 giga de RAM, tener Uptime Kuma consumiendo 140 megas es un lujo que no te puedes permitir si ya ejecutas Pi-hole, un servidor DNS, y un par de cosas más. Con Watchbit, esos 7 megas pasan totalmente desapercibidos.

6. Docker image mínima. La imagen Docker está construida desde scratch, el mínimo absoluto. Solo contiene el binario estático de Rust. Nada más. Ni siquiera una shell, ni busybox, ni nada. Por eso pesa 20 megas. Esto no solo ahorra espacio en disco, sino que también reduce la superficie de ataque. Menos cosas dentro del contenedor significa menos vulnerabilidades potenciales. Y las descargas son instantáneas.

7. Código abierto y transparente. Watchbit es software libre, puedes revisar el código, modificarlo, y contribuir. No hay sorpresas, no hay telemetría oculta, no hay limitaciones en la versión gratuita porque solo hay una versión. Si algo no te gusta, lo cambias. Si encuentras un bug, lo reportas o lo arreglas tú mismo. Es la filosofía del software libre llevada a la práctica.

Conclusión

Llevo meses usando Watchbit en producción y no he mirado atrás. Todos los servicios que monitorizaba con Uptime Kuma están ahora en Watchbit, funcionando exactamente igual, con las mismas notificaciones, pero consumiendo una fracción de los recursos.

¿Es Watchbit para todo el mundo? Probablemente no. Si necesitas una página de estado pública con estadísticas elaboradas, o si quieres monitorizar cientos de servicios con gráficos históricos detallados, quizá Uptime Kuma sigue siendo la mejor opción. Pero si lo que buscas es un monitor de uptime ligero, eficiente, y que haga bien su trabajo sin derrochar recursos, Watchbit es exactamente lo que necesitas.

Y oye, si te animas a probarlo, ya me contarás qué tal te va. Yo por mi parte, estoy encantado de haber recuperado 133 megas de RAM que ahora puedo dedicar a otros servicios. Que al final, en esto del selfhosted, cada mega cuenta 😊

---

Más información,

• Repositorio de Uptime Kuma — El monitor de uptime open-source más popular, escrito en Node.js
• Repositorio de Pocket ID — Proveedor OIDC ultraligero con autenticación solo con passkeys
• Documentación de NTFY — Sistema de notificaciones pub-sub HTTP, auto-hospedable
• Repositorio de Gotify — Servidor de notificaciones auto-hospedado con app Android
• Gatus — Monitor de uptime en Go — Alternativa ligera a Uptime Kuma con configuración YAML
• Vigil — Monitor en Rust — Monitor de uptime escrito en Rust, sin interfaz gráfica
• Upptime — Monitor basado en GitHub Actions — Monitorización serverless con GitHub Actions
• Axum web framework — Framework web async para Rust, construido sobre tokio y tower
• Tokio async runtime — Runtime asíncrono para Rust, estándar de facto
• Rusqlite — SQLite bindings para Rust — Bindings seguros a SQLite desde Rust
• Documentación de SQLite — Documentación oficial de SQLite, la base de datos embebida más popular
• Especificación OpenID Connect — Estándar OIDC para autenticación descentralizada
• reqwest — Cliente HTTP para Rust — Cliente HTTP async para Rust, usado para los checks de monitorización
• minijinja — Motor de plantillas para Rust — Port de Jinja2 a Rust, ultraligero y sin dependencias