[{"data":1,"prerenderedAt":215},["ShallowReactive",2],{"seo-verification":3,"blog-alertas-de-disco-lleno-y-ram-en-un-vps-sin-pila-de-supervision-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-alertas-de-disco-lleno-y-ram-en-un-vps-sin-pila-de-supervision-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":155,"ctaBody":156,"ctaButton":157,"ctaUrl":158,"relatedPosts":159},506,"alertas-de-disco-lleno-y-ram-en-un-vps-sin-pila-de-supervision",{"fr":12,"en":13,"ar":14,"es":10},"alertes-disque-ram-vps-monitoring-proactif","disk-full-and-ram-alerts-on-a-vps-no-monitoring-stack-needed","تنبيهات-امتلاء-القرص-والذاكرة-على-vps-دون-منظومة-مراقبة","Alertas de disco lleno y RAM en un VPS, sin pila de supervisión","Seis alertas en shell para sus VPS de clientes: disco, inodos, OOM, servicios systemd, certificados, copias, con un latido que vigila el propio control.",13,0,false,"2026-10-27T00:00:00+00:00","2026-10-27T23:58:39+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Falertes-disque-ram-vps-monitoring-proactif-poster.svg","Un disco se llena, la base de datos se detiene y el cliente se entera antes que usted. El coste es una intervención urgente y una confianza dañada. Una pila de supervisión completa es un segundo servidor que mantener, así que muchas agencias renuncian y no vigilan nada. Esta guía coloca seis alertas mínimas en shell en cada VPS: disco, inodos, memoria, servicios, certificados y copias. El control está vigilado a su vez por un latido externo.",[35,39,50,53,56,87,90,93,96,132,136,139,149,152],{"type":36,"title":37,"body":38},"h2","Un disco lleno no avisa a nadie","El escenario se repite. Un VPS de cliente funciona desde hace meses, la base de datos escribe sus registros, las copias de seguridad se acumulan y una mañana el servicio se detiene. No salió ninguna alerta y el cliente se entera antes que usted. En PostgreSQL, un caso comunicado en la lista oficial del proyecto muestra la línea exacta: `PANIC: could not write to file \"pg_wal\u002Fxlogtemp.11399\": No space left on device`. Un PANIC no es una simple advertencia: el servidor ya no puede registrar sus escrituras, se detiene y solo reinicia correctamente cuando se libera espacio.\n\nLa dificultad no es detectar un disco lleno, sino detectarlo antes. Entre el 80 % de ocupación y la caída suelen quedar horas o días, y esa es justo la ventana que debe captar una alerta bien ajustada. Esta guía no repite la instalación de una pila de supervisión: coloca lo mínimo útil en cada VPS, en shell, sin un segundo servidor que mantener.",{"type":40,"title":41,"items":42},"ul","Las seis alertas mínimas y el latido, en cada VPS",[43,44,45,46,47,48,49],"**Disco** — dos umbrales, 80 % como aviso y 90 % como crítico, en cada punto de montaje relevante.","**Inodos** — un disco puede rechazar escrituras aunque queden bytes libres, si los inodos están agotados.","**Memoria y OOM** — detectar que el kernel mató un proceso, y no solo que la RAM está alta.","**Servicios systemd** — recibir un aviso cuando la base de datos, el servidor web o el proxy pasa al estado failed.","**Certificados** — avisar 21 días antes del vencimiento, cuando la renovación automática ha fallado en silencio.","**Copias de seguridad** — avisar por la ausencia de un éxito reciente, no solo por un error explícito.","**El propio control** — un latido externo que avisa cuando dejan de enviarse las alertas.",{"type":36,"title":51,"body":52},"Requisitos en cifras: casi nada","Todo lo que sigue cabe en unas decenas de líneas de shell POSIX. Hace falta un VPS Linux con `curl`, `cron` o los timers de systemd, acceso root para escribir en `\u002Fusr\u002Flocal\u002Fbin` y `\u002Fetc`, y alrededor de 1 MB de disco. El coste en memoria es el de un script que dura un segundo cada cinco minutos: despreciable, incluso en el VPS más pequeño.\n\nDos elementos externos completan el dispositivo: un canal de recepción (un bot de Telegram, o cualquier webhook accesible por HTTP) y un servicio de latido, que recibe un ping regular y le avisa cuando se detiene. Para este segundo punto, Healthchecks.io ofrece un plan gratuito limitado a 20 jobs y 100 entradas de registro por job, lo que cubre de sobra un parque pequeño; compruebe esos límites en la fuente antes de fiarse. Si no quiere depender de ningún servicio externo, el modo push de Uptime Kuma cumple el mismo papel en una máquina propia.",{"type":36,"title":54,"body":55},"Disco e inodos: los umbrales y lo que los desplaza","El comando útil es `df -h --output=pcent,target`: solo muestra el porcentaje y el punto de montaje, que se lee y se procesa con facilidad. Para los inodos, la misma idea se convierte en `df --output=ipcent,target`. Una carpeta de sesiones o de pequeños archivos de caché puede consumir todos los inodos de un sistema de archivos ext4 mientras `df -h` aún muestra un 40 % de ocupación: la escritura falla igualmente con `No space left on device`.\n\nHay una segunda sutileza. En ext4, el 5 % de los bloques está reservado por defecto a los procesos privilegiados, según la página de manual de `tune2fs`; así los demonios del sistema pueden seguir escribiendo cuando un usuario ordinario ha llenado el disco. Consecuencia: un servicio que corre con una cuenta sin privilegios, como la base de datos, ve `df` marcar 100 % cuando el disco está ocupado en torno al 95 %. De ahí los umbrales elegidos: 80 % para tener tiempo de actuar, 90 % para actuar de inmediato. Esperar al 100 % es avisar después de la caída.",{"type":57,"title":58,"steps":59},"steps","Montar el dispositivo en una hora",[60,63,66,69,72,75,78,81,84],{"title":61,"body":62},"Crear el canal de alerta","Cree un bot de Telegram con BotFather, anote su token y el identificador de la conversación que debe recibir los mensajes. Todas las peticiones de la API de Bot siguen la forma `https:\u002F\u002Fapi.telegram.org\u002Fbot\u003Ctoken>\u002FMETHOD_NAME`, y el método de envío es `sendMessage`. Si prefiere un webhook (Slack, Mattermost, ntfy), solo cambia la última línea del script de envío.",{"title":64,"body":65},"Escribir el archivo de entorno","`sudo mkdir -p \u002Fvar\u002Flib\u002Falerte-vps`\n`sudo install -m 600 \u002Fdev\u002Fnull \u002Fetc\u002Falerte-vps.env`\nAñada después cuatro líneas: `TG_TOKEN=...`, `TG_CHAT=...`, `HC_URL=https:\u002F\u002Fhc-ping.com\u002F\u003Cuuid>` (check cada cinco minutos) y `HC_URL_JOUR=https:\u002F\u002Fhc-ping.com\u002F\u003Cotro-uuid>` (check diario). El modo 600 deja el token legible solo para root.",{"title":67,"body":68},"Escribir el script de envío con antirrepetición","Guarde estas líneas en `\u002Fusr\u002Flocal\u002Fbin\u002Falerte-envoi` y haga el archivo ejecutable con `sudo chmod 755`. El archivo de bloqueo por mensaje evita que le despierten cada cinco minutos por la misma alerta: un mensaje idéntico solo se reenvía pasada una hora.\n`#!\u002Fbin\u002Fsh`\n`. \u002Fetc\u002Falerte-vps.env`\n`f=\u002Fvar\u002Flib\u002Falerte-vps\u002F$(echo \"$1\" | md5sum | cut -c1-12)`\n`[ -n \"$(find \"$f\" -mmin -60 2>\u002Fdev\u002Fnull)\" ] && exit 0`\n`touch \"$f\"`\n`curl -fsS -m 10 --retry 3 \"https:\u002F\u002Fapi.telegram.org\u002Fbot${TG_TOKEN}\u002FsendMessage\" -d chat_id=\"${TG_CHAT}\" --data-urlencode text=\"$(hostname) $1\"`",{"title":70,"body":71},"Controlar disco e inodos","En `\u002Fusr\u002Flocal\u002Fbin\u002Falerte-rapide` (shebang `#!\u002Fbin\u002Fsh`), añada los dos bucles siguientes. El filtro `grep -v` descarta los sistemas de archivos que no exponen inodos y muestran un guion.\n`df --output=pcent,target -x tmpfs -x devtmpfs | tail -n +2 | while read p m; do n=${p%\\%}; if [ \"$n\" -ge 90 ]; then alerte-envoi \"CRIT disk $m\"; elif [ \"$n\" -ge 80 ]; then alerte-envoi \"WARN disk $m\"; fi; done`\n`df --output=ipcent,target -x tmpfs -x devtmpfs | tail -n +2 | grep -v '^ *-' | while read p m; do [ \"${p%\\%}\" -ge 90 ] && alerte-envoi \"INODES $m\"; done`",{"title":73,"body":74},"Detectar los procesos matados por el OOM killer","El contador `oom_kill` de `\u002Fproc\u002Fvmstat` solo crece desde el arranque. Se compara con el valor anterior, guardado en un archivo; tras un reinicio el contador vuelve a cero, la comparación falla una vez y luego se restablece.\n`n=$(awk '\u002F^oom_kill\u002F {print $2}' \u002Fproc\u002Fvmstat)`\n`old=$(cat \u002Fvar\u002Flib\u002Falerte-vps\u002Foom 2>\u002Fdev\u002Fnull || echo 0)`\n`[ \"$n\" -gt \"$old\" ] && alerte-envoi \"OOM kill\"`\n`echo \"$n\" > \u002Fvar\u002Flib\u002Falerte-vps\u002Foom`",{"title":76,"body":77},"Añadir el latido y programar","Termine `alerte-rapide` con el ping. Solo se alcanza si el script ha llegado hasta el final; si cron se detiene, si el disco pasa a solo lectura o si el script falla, el ping cesa y el servicio externo le avisa. Añada después las líneas de cron en `\u002Fetc\u002Fcron.d\u002Falerte-vps`.\n`. \u002Fetc\u002Falerte-vps.env; curl -fsS -m 10 --retry 5 -o \u002Fdev\u002Fnull \"$HC_URL\"`\n`PATH=\u002Fusr\u002Flocal\u002Fbin:\u002Fusr\u002Fbin:\u002Fbin`\n`*\u002F5 * * * * root \u002Fusr\u002Flocal\u002Fbin\u002Falerte-rapide`\n`30 7 * * * root \u002Fusr\u002Flocal\u002Fbin\u002Falerte-quotidien`",{"title":79,"body":80},"Controlar certificados y copias una vez al día","En `\u002Fusr\u002Flocal\u002Fbin\u002Falerte-quotidien`, añada estas líneas. La opción `-checkend` de `openssl x509` falla si el certificado caduca dentro del número de segundos indicado; 1814400 segundos equivalen a 21 días. La prueba de copia avisa cuando ningún archivo `.gz` no vacío es más reciente que 1560 minutos, es decir 26 horas. El script termina con su propio ping, hacia el segundo check: sin él, un control diario caído en silencio pasaría inadvertido.\n`echo | openssl s_client -servername your-domain.com -connect your-domain.com:443 2>\u002Fdev\u002Fnull | openssl x509 -noout -checkend 1814400 || alerte-envoi \"CERT your-domain.com\"`\n`find \u002Fvar\u002Fbackups\u002Fapp -name '*.gz' -mmin -1560 -size +1k | grep -q . || alerte-envoi \"BACKUP absent\"`\n`. \u002Fetc\u002Falerte-vps.env; curl -fsS -m 10 --retry 5 -o \u002Fdev\u002Fnull \"$HC_URL_JOUR\"`",{"title":82,"body":83},"Conectar los servicios críticos a OnFailure","Cree `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fnotify-failure@.service` con el contenido siguiente y luego `sudo systemctl daemon-reload`.\n`[Unit]`\n`Description=Alerte echec de %i`\n`[Service]`\n`Type=oneshot`\n`ExecStart=\u002Fusr\u002Flocal\u002Fbin\u002Falerte-envoi \"FAILED %i\"`\nPara cada servicio a vigilar, abra un drop-in con `sudo systemctl edit mariadb.service` y añada estas dos líneas.\n`[Unit]`\n`OnFailure=notify-failure@%n.service`",{"title":85,"body":86},"Forzar una alerta de prueba y limpiar","Una alerta que nunca se ha disparado no es una alerta. Compruebe primero el espacio libre, cree un archivo lo bastante grande para superar el umbral, ejecute el script a mano y borre el archivo. Si el mensaje no llega, el fallo está en el canal, y es mejor descubrirlo ahora.\n`df -h --output=pcent,target \u002Fvar\u002Ftmp`\n`sudo fallocate -l 2G \u002Fvar\u002Ftmp\u002Ftest-alerte.img`\n`sudo \u002Fusr\u002Flocal\u002Fbin\u002Falerte-rapide`\n`sudo rm \u002Fvar\u002Ftmp\u002Ftest-alerte.img`",{"type":36,"title":88,"body":89},"Memoria: OOM del kernel o límite de cgroup","Dos mecanismos matan un proceso por falta de memoria y no se leen en el mismo sitio. El primero es el OOM killer del kernel, cuando a toda la máquina le falta RAM: el registro del kernel contiene entonces un mensaje del tipo `Out of memory: Killed process`, que `journalctl -k` permite encontrar. El segundo es el límite de un cgroup. Según la documentación de systemd, cuando el uso de una unidad no puede contenerse bajo `MemoryMax=`, el OOM killer se invoca dentro de la unidad: el resto de la máquina puede tener memoria libre.\n\nEl contador `oom_kill` de `\u002Fproc\u002Fvmstat` cubre el primer caso a escala de máquina. Para una unidad concreta, el archivo `memory.events` de su cgroup expone un contador `oom_kill` propio, definido por la documentación del kernel como el número de procesos del cgroup matados por cualquier tipo de OOM killer. En un VPS que aloja una aplicación voraz, como la descrita en \u003Ca href=\"\u002Fblog\u002Fn8n-erreurs-memoire-oom-production-vps\">la guía de n8n y OOM en producción\u003C\u002Fa>, este segundo contador explica las paradas que `free -h` nunca muestra.",{"type":36,"title":91,"body":92},"OnFailure: lo que cubre y lo que no","Según la documentación de systemd, `OnFailure=` enumera las unidades que se activan cuando la unidad entra en el estado failed. La plantilla `notify-failure@.service` recibe el nombre de la unidad defectuosa gracias al especificador `%n`, y el mensaje de alerta puede añadir la salida de `systemctl status` o de `journalctl -u` como contexto.\n\nEl límite es estructural: un servicio que funciona pero ya no responde nunca pasó por el estado failed, así que `OnFailure=` no dice nada. Un servicio relanzado por `Restart=` solo llega ahí cuando se alcanza el límite de arranque. Para esos casos, añada una sonda de aplicación sencilla, por ejemplo un `curl` a la dirección de salud de la aplicación, en el script rápido. La sintaxis de timers y cron se trata en \u003Ca href=\"\u002Fblog\u002Fcron-systemd-timers-automatisation-vps\">la guía de cron y timers de systemd\u003C\u002Fa>, y no hace falta repetirla aquí.",{"type":36,"title":94,"body":95},"Certificados y copias: avisar por la ausencia de éxito","Una renovación automática de certificado puede fallar en silencio durante semanas: un registro DNS modificado, un puerto bloqueado, un complemento roto. El certificado no caduca ese día, caduca noventa días después, y nadie se acuerda. La prueba con `openssl` interroga lo que el visitante recibe realmente, lo cual vale más que leer un archivo del disco. En un servidor gestionado con Certbot, `certbot certificates` lista los certificados y su vencimiento, y `certbot renew --dry-run` comprueba que la próxima renovación saldrá bien.\n\nMisma lógica para las copias de seguridad. Una alerta disparada por el fallo de un script de copia no ve el caso en que el script nunca se ejecutó. La alerta correcta se coloca sobre la ausencia: ningún archivo reciente, o un archivo de tamaño cero. Eso hace la línea `find -mmin` del script diario, y por eso calla cuando todo va bien y habla en cuanto la cadena de copias se detiene, sea cual sea el motivo.",{"type":97,"title":98,"headers":99,"rows":103},"comparison","Scripts propios o pila de supervisión",[100,101,102],"Criterio","Scripts shell y OnFailure","Beszel o Uptime Kuma",[104,108,112,116,120,124,128],[105,106,107],"Puesta en marcha","Una hora, unos pocos archivos en `\u002Fusr\u002Flocal\u002Fbin`","Un hub que alojar, agentes que instalar en cada VPS",[109,110,111],"Parque objetivo","De 1 a 5 VPS, hasta 10 si los umbrales son idénticos","Más allá de 5 a 10 VPS, o en cuanto se necesite comparar",[113,114,115],"Historial y gráficas","Ninguno, solo el instante de la alerta","Gráficas, tendencias, comparación entre máquinas",[117,118,119],"Mantenimiento","Nada que actualizar fuera del shell","Un segundo servidor y sus actualizaciones que mantener",[121,122,123],"Servicios de aplicación","Una sonda `curl` que escribir uno mismo","Sondas HTTP y TCP y página de estado listas para usar",[125,126,127],"Caída del monitor","Detectada por el latido externo","A vigilar aparte, el hub es a su vez una máquina",[129,130,131],"Cuándo elegirlo","Alertas mínimas, parque pequeño, ningún servidor extra","Historial deseado, parque en crecimiento, equipo compartido",{"type":133,"title":134,"body":135},"tip","Vigile al vigilante","La trampa de estos scripts es convertirse en un falso seguro: callan porque todo va bien, o porque están rotos, y el silencio se parece en ambos casos. El ping de latido resuelve el problema. Ajuste el periodo esperado del check un poco por encima del intervalo de cron y añada un margen de tolerancia: una alerta de silencio que llega veinte minutos tarde vale más que un falso positivo en cada reinicio. Mantenga también `\u002Fetc\u002Falerte-vps.env` en modo 600 y no versione nunca el token.",{"type":36,"title":137,"body":138},"Solución de problemas: los errores que vuelven","Las propias alertas fallan de manera previsible. Estos son los casos que se encuentran con más frecuencia, con el mensaje o síntoma que reconocer y el remedio. Cada uno se comprueba a mano antes de buscar más lejos.",{"type":40,"title":140,"items":141},"Mensajes y síntomas con su remedio",[142,143,144,145,146,147,148],"**`PANIC: could not write to file \"pg_wal\u002F...\": No space left on device`** — el volumen que contiene los registros de PostgreSQL está lleno. Libere primero espacio fuera de PostgreSQL (registros rotados, copias antiguas), no borre nunca a mano los archivos de `pg_wal` y reinicie después el servicio.","**`No space left on device` mientras `df -h` indica espacio** — los inodos están agotados. Ejecute `df --output=ipcent,target`, localice la carpeta con millones de archivos pequeños (sesiones, caché) y purgue.","**Disco lleno pero `du` no encuentra el espacio** — archivos borrados siguen abiertos por un proceso. `sudo lsof +L1` los lista; reiniciar el proceso libera el espacio.","**`oom_kill` aumenta, nada en `journalctl -k`** — el registro del kernel rotó o la muerte viene de un límite `MemoryMax=`. Lea `memory.events` en el directorio del cgroup de la unidad y `journalctl -u` para la unidad.","**Una unidad funciona pero ya no responde, sin alerta** — es el límite de `OnFailure=`. Añada una sonda `curl` a la dirección de salud y avise según el código de retorno.","**Ningún mensaje de Telegram, ningún error visible** — cron envía la salida del script por correo local, que nadie lee. Ejecute `alerte-envoi test` a mano con `sudo` y lea la respuesta de `curl`.","**El certificado se acerca al vencimiento aunque Certbot esté instalado** — ejecute `certbot renew --dry-run` y lea el error de validación; corrija después el DNS o el puerto implicado.",{"type":36,"title":150,"body":151},"La documentación oficial","Cada comportamiento descrito aquí procede de una fuente primaria. Para `OnFailure=`, \u003Ca href=\"https:\u002F\u002Fwww.freedesktop.org\u002Fsoftware\u002Fsystemd\u002Fman\u002Flatest\u002Fsystemd.unit.html\">la página de manual de systemd.unit\u003C\u002Fa>; para `MemoryMax=`, \u003Ca href=\"https:\u002F\u002Fwww.freedesktop.org\u002Fsoftware\u002Fsystemd\u002Fman\u002Flatest\u002Fsystemd.resource-control.html\">systemd.resource-control\u003C\u002Fa>; para los contadores `oom` y `oom_kill`, \u003Ca href=\"https:\u002F\u002Fdocs.kernel.org\u002Fadmin-guide\u002Fcgroup-v2.html\">la documentación de cgroups v2 del kernel\u003C\u002Fa>; para el 5 % reservado, \u003Ca href=\"https:\u002F\u002Fman7.org\u002Flinux\u002Fman-pages\u002Fman8\u002Ftune2fs.8.html\">la página de manual de tune2fs\u003C\u002Fa>. En el envío, \u003Ca href=\"https:\u002F\u002Fcore.telegram.org\u002Fbots\u002Fapi#making-requests\">la API de Bot de Telegram\u003C\u002Fa> describe la forma de las peticiones, y \u003Ca href=\"https:\u002F\u002Fhealthchecks.io\u002Fdocs\u002Fhttp_api\u002F\">la documentación de la API de Healthchecks\u003C\u002Fa> las direcciones de ping, con \u003Ca href=\"https:\u002F\u002Fhealthchecks.io\u002Fpricing\u002F\">la página de precios\u003C\u002Fa> para los límites del plan gratuito. Para la renovación, \u003Ca href=\"https:\u002F\u002Feff-certbot.readthedocs.io\u002Fen\u002Fstable\u002Fusing.html\">la documentación de Certbot\u003C\u002Fa>. El mensaje de PostgreSQL citado procede de \u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002Fmessage-id\u002FBL0PR04MB6499BC32502F223A7BDF9BF2D0B30%40BL0PR04MB6499.namprd04.prod.outlook.com\">un hilo de la lista oficial del proyecto\u003C\u002Fa>.",{"type":36,"title":153,"body":154},"Alertas sencillas, las mismas en cada VPS","Seis alertas y un latido no sustituyen una pila de supervisión: cubren lo que realmente tumba un servidor: disco, inodos, memoria, servicios, certificados, copias. La ganancia principal es la uniformidad: mismos umbrales, mismos mensajes, mismo gesto de prueba en cada máquina del parque. Cuando el parque crece o hace falta historial, el salto a una pila se prepara en \u003Ca href=\"\u002Fblog\u002Fself-host-beszel-vps\">la guía de Beszel\u003C\u002Fa> y en \u003Ca href=\"\u002Fblog\u002Fmonitoring-alerte-proactif-self-hosted-vps\">la guía de alertas proactivas con Beszel y Uptime Kuma\u003C\u002Fa>, que tratan la instalación de principio a fin.","Un parque de VPS de clientes, umbrales homogéneos","En ServOrbit.com, los dominios, alojamientos y servidores de un parque de clientes se reúnen en un mismo lugar, con el mismo espacio de gestión. La opción de administración VPS existe para los clientes que no quieren administrar su servidor.","Ver las soluciones para agencias","\u002Fsolutions\u002Fagences",[160,176,197],{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":18,"isPinned":19,"publishedAt":170,"updatedAt":171,"category":172,"categories":173,"featuredImage":30,"bgImage":31,"posterImage":175,"relatedSolution":30},440,"monitorizacion-proactiva-vps-beszel-uptime-kuma-v2",{"fr":164,"en":165,"ar":166,"es":162},"monitoring-alerte-proactif-self-hosted-vps","proactive-vps-monitoring-beszel-uptime-kuma-v2","مراقبة-استباقية-vps-beszel-uptime-kuma","Monitorización proactiva en VPS: Beszel y Uptime Kuma v2","Despliega Beszel y Uptime Kuma v2 en un VPS para supervisar toda tu flota de servidores y recibir alertas por Telegram o SMTP antes de que tus clientes detecten la caída.",11,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[174],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg",{"id":177,"slug":178,"slugs":179,"title":183,"excerpt":184,"readTime":185,"views":186,"isPinned":19,"publishedAt":187,"updatedAt":188,"category":189,"categories":194,"featuredImage":30,"bgImage":31,"posterImage":196,"relatedSolution":30},230,"cron-vs-systemd-timers-automatizar-vps-linux",{"fr":180,"en":181,"ar":182,"es":178},"cron-systemd-timers-automatisation-vps","cron-vs-systemd-timers-automate-your-linux-vps","cron-مقابل-systemd-timers-أتمتة-vps-linux","cron vs systemd timers: automatizar su VPS Linux","Comparativa práctica de cron y systemd timers: sintaxis, logs, migración y solución de problemas para sus tareas recurrentes en un VPS Linux.",12,1,"2026-08-06T00:00:00+00:00","2026-09-20T21:13:53+00:00",{"id":190,"name":191,"slug":192,"color":193,"icon":192},2,"Automatización","automatisation","bg-brand-action\u002F10 text-brand-action",[195],{"id":190,"name":191,"slug":192,"color":193,"icon":192},"\u002Fblog\u002Fcovers\u002Fcron-systemd-timers-automatisation-vps-poster.svg",{"id":198,"slug":199,"slugs":200,"title":204,"excerpt":205,"readTime":23,"views":186,"isPinned":19,"publishedAt":206,"updatedAt":207,"category":208,"categories":209,"featuredImage":30,"bgImage":31,"posterImage":211,"relatedSolution":212},133,"alojar-beszel-hub-monitorizacion-vps",{"fr":201,"en":202,"ar":203,"es":199},"self-host-beszel-vps","self-host-beszel-multi-server-monitoring-hub-on-your-vps","استضف-beszel-على-vps-مركز-مراقبة-متعدد-الخوادم","Beszel en VPS: monitorización multiservidor, alertas y seguridad","Supervise su parque de VPS desde un único hub Beszel: alertas por Telegram y correo, 2FA, agentes declarados automáticamente y solución de conexiones silenciosas.","2026-02-14T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[210],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-beszel-vps-poster.svg",{"categorySlug":213,"appSlug":214},"monitorizacion-observabilidad","beszel",1793146052218]