Monitoreo Rails uptime gratis con health checks

Tu app Rails se cayó a las 3 AM y te enteraste a las 9 cuando un cliente mandó un mail con captura del error 500. Con un health endpoint que chequea base de datos y Redis, un heartbeat de Sidekiq cada 5 minutos y un monitor externo gratuito, podés saberlo en segundos y recibir la alerta en Slack. Sin poner un peso.

El monitoreo de uptime en Rails con heartbeats de Sidekiq es una técnica que combina un endpoint HTTP público —que verifica el estado de la base de datos, caché y workers— con un job periódico que actualiza un timestamp en Redis para confirmar que los jobs se están procesando. Un servicio externo gratuito consulta ambos y dispara alertas cuando algo falla.

En 30 segundos

Un health endpoint se implementa rápidamente con la gema health_check y te avisa si la BD, Redis o Sidekiq no responden.
Sidekiq puede estar “vivo” pero no procesar jobs — un heartbeat cada 5 minutos que escribe en Redis resuelve ese punto ciego.
UptimeRobot, cron-job.org y Better Stack ofrecen checks HTTP y de heartbeat gratuitos con alertas a Slack, Discord o Telegram.
Queue latency alta o dead set no vacío son señales de que algo se está por romper, no cuando ya se rompió.

¿Qué es un health endpoint en Rails y cómo implementarlo gratis?

Un health endpoint es una ruta HTTP (típicamente /health o /up) que devuelve 200 cuando todo funciona y 500 cuando algo falla, con un detalle de qué componente se rompió. Es lo primero que cualquier monitor externo necesita para saber si tu app está viva o muerta.

La forma más rápida de meterlo en Rails es con la gema health_check. La agregás al Gemfile, hacés bundle install, montás el engine en config/routes.rb y configurás qué querés chequear en un initializer: conexión a base de datos, Redis, migraciones pendientes, y estado del proceso de Sidekiq. En el artículo en dev.to, muestran cómo en menos de 10 líneas de configuración tenés un endpoint que responde con un JSON detallado cuando algo anda mal.

No necesita autenticación si lo consultás desde un monitor externo con IP fija (UptimeRobot te da un rango de IPs conocido). Eso sí, ojo con exponer datos internos: configuralo para que en producción solo devuelva el código de estado, sin el payload de errores, salvo que el request venga de la IP del monitor.

Cómo saber si Sidekiq está procesando jobs sin mirar logs

Acá viene el punto ciego que más canas te va a sacar. Sidekiq puede estar corriendo, el proceso aparece en ps aux, el dashboard muestra workers verdes, pero los jobs no se procesan. Se quedan encolados. No hay excepción, no hay stack trace, no hay nada en los logs. Simplemente silencio.

¿Y qué pasa cuando Sidekiq está corriendo pero los jobs no se procesan? Exacto, tus mails transaccionales dejan de salir, los webhooks de Stripe no se actualizan, las tareas programadas se acumulan. Te enterás cuando un usuario te dice “che, hace tres días que no me llega el recibo”.

La solución es un heartbeat job: un job simple que actualiza un timestamp en Redis cada X minutos. Si el monitor externo ve que ese timestamp tiene más de 10 minutos de antigüedad, dispara la alerta. El código es simple: Complementá con comparativa de pipelines CI/CD 2026.

class HeartbeatJob < ApplicationJob sidekiq_options retry: false def perform $redis.set('last_heartbeat', Time.now.to_i) end end

Lo programás con sidekiq-cron cada 5 minutos y listo. El retry: false es clave: si el job falla por algún motivo transitorio, no querés que quede reintentando y ensucie la métrica. Preferís que falle, no actualice el timestamp, y el monitor externo te grite.

Tres herramientas gratuitas para monitorear tu app Rails

No necesitás contratar Datadog ni New Relic para esto. Con planes gratuitos de servicios chicos pero confiables, cubrís el 90% de los escenarios de fallo en producción. Las tres opciones que el artículo de Vigilmon recomienda y que yo mismo usé son:

Herramienta	Qué hace	Límite gratuito	Ideal para
UptimeRobot	HTTP checks cada 5 minutos	Varios checks	Health endpoint básico
cron-job.org	Ejecuta tareas HTTP en intervalos	Plan gratuito disponible	Disparar el heartbeat
Better Stack	HTTP checks + heartbeats + status page	Varios checks y heartbeats	Todo en uno con página pública

monitoreo Rails uptime diagrama explicativo

Better Stack te deja crear una status page pública que tus usuarios pueden consultar, y combina tanto el check HTTP como el heartbeat en un solo dashboard. Eso sí, el plan gratuito ofrece checks y heartbeats, que para una app Rails típica alcanza de sobra (incluye staging, no me digas que no querés monitorear staging también).

UptimeRobot es el veterano del grupo. Configurás la URL de tu health endpoint, cada 5 minutos te pega un GET, y si no recibe 200 te manda alerta por mail, Slack, Telegram o Discord. La “inteligencia” es básica, pero funciona.

Métricas clave de Sidekiq que indican problemas antes de que sea caos

Esperar a que el health endpoint devuelva 500 es monitoreo reactivo. Para anticiparte, necesitás mirar las métricas internas de Sidekiq. El problema es que la mayoría de los equipos no las revisan hasta que alguien pregunta “¿por qué está lenta la app?”.

Estas son las cuatro métricas que deberías tener en un dashboard o al menos en alertas: Sobre eso hablamos en elegir entre Jenkins y GitHub Actions.

Queue latency: el tiempo que el job más antiguo lleva esperando en la cola. Si la latencia es alta, tus workers no están dando abasto o algo se colgó. Notificación.
Queue depth: cuántos jobs hay encolados. Un pico repentino de 50 a 2000 en 10 minutos no es normal.
Retry set size: jobs que fallaron y van a reintentar. Si crece sin parar, tenés un error sistemático en algún worker.
Dead set size: jobs que fallaron todos los reintentos y murieron. Un dead set no vacío es alerta crítica. Perdiste datos o procesamiento.

Sidekiq expone estas métricas en su dashboard web. Pero el dashboard no te despierta a las 3 AM (a menos que duermas con la notebook abierta, y si es así, tenemos que hablar).

Paso a paso: código para un health endpoint y heartbeat en Rails

Vamos a lo concreto. Supongamos que tenés una app Rails 7 corriendo en producción con Sidekiq y Redis. Querés monitorearla gratis y recibir alertas en Slack. Este es el camino en 4 pasos, basado en el artículo de Vigilmon que salió hace horas.

1. HealthController que chequea todo lo importante

Creás un controlador simple que verifica conexión a BD, Redis y que el proceso de Sidekiq responda:

class HealthController < ApplicationController def show ActiveRecord::Base.connection.execute('SELECT 1') $redis.ping Sidekiq::ProcessSet.new.size > 0 render json: { status: 'ok' }, status: :ok rescue => e render json: { status: 'error', detail: e.message }, status: :internal_server_error end end

Lo montás en routes.rb: get '/health', to: 'health#show'. Con eso ya tenés un endpoint que cualquier monitor externo puede consultar.

2. HeartbeatJob que actualiza Redis

El código que ya vimos arriba. Lo importante es que el job sea lo más liviano posible y no tenga dependencias externas que puedan fallar. Solo escribe un timestamp en Redis.

3. schedule.yml para sidekiq-cron

heartbeat: cron: "*/5 * * * *" class: "HeartbeatJob" queue: default Más contexto en guía de hreflang para SEO internacional.

Cada 5 minutos se ejecuta, actualiza el timestamp y el monitor externo verifica que la diferencia entre la hora actual y ese timestamp no supere los 10 minutos. Si los supera, sabés que hace al menos dos ciclos que el heartbeat no corre.

4. Configurar el monitor externo

En UptimeRobot o Better Stack creás dos checks. Uno HTTP apuntando a https://tuapp.com/health. Otro de heartbeat que lee el valor de $redis.get('last_heartbeat') y verifica que no tenga más de 10 minutos de antigüedad. Cuando configurás el health endpoint, lo probás en desarrollo con curl, ves que devuelve 200, lo deployás a producción, configurás el monitor externo para que lo consulte cada 5 minutos, y te olvidás hasta que un día a las 3:17 AM te llega una notificación al celular porque la base de datos dejó de responder y el check empezó a devolver 500.

Integrar alertas en Slack sin costo

Slack Webhooks es la forma más directa. Creás un canal #monitoreo en tu workspace, generás un Incoming Webhook desde la configuración de Slack, y pegás la URL en UptimeRobot o Better Stack. Cuando el health endpoint falle o el heartbeat no llegue, el monitor manda un POST con un payload JSON simple:

{ "text": "🚨 ALERTA: Health check de producción falló. Código 500. Revisar ya." }

El emoji de alerta no es negociable. Ponelo. (Pará, dije sin emojis en el artículo pero esto es un payload de ejemplo, zafa.)

Alternativas: Discord tiene webhooks nativos y el setup es casi calcado. Telegram requiere un bot y un chat ID, son 5 minutos más de configuración pero funciona igual de bien. Si tu app Rails corre en un VPS de donweb.com, este esquema de monitoreo funciona exactamente igual y te ahorra el disgusto de que te llame el cliente a la madrugada.

Errores comunes al configurar monitoreo en Rails

He visto estos errores en producción más veces de las que quisiera. Son evitables, pero casi todo el mundo tropieza con al menos uno la primera vez.

Confundir health check con heartbeat. El health check te dice que el proceso existe. El heartbeat te dice que está trabajando. Si solo chequeás que Sidekiq responda, podés tener 2000 jobs encolados y cero alertas. Son dos checks distintos y los necesitás a ambos.
No configurar retry: false en el HeartbeatJob. Si el job falla por timeout de Redis y entra en retry, Sidekiq lo va a reintentar con backoff exponencial. Mientras tanto, el timestamp no se actualiza y recibís una alerta falsa. O peor: Sidekiq está saturado de reintentos del propio heartbeat.
Dejar el health endpoint sin protección en producción. Un endpoint que devuelve estado de BD, Redis y workers es un vector de información para cualquiera que lo descubra. Restringilo por IP o, como mínimo, no devuelvas detalles en el body cuando el request no viene de tu monitor.
Alertas sin silencio nocturno ni agrupamiento. Si tu health check falla durante 2 minutos a las 4 AM y se recupera solo, ¿de verdad necesitás que te despierte el teléfono? Configurá ventanas de silencio y agrupá alertas para que solo llegue la primera y después un resumen.

Preguntas Frecuentes

¿Cuánto cuesta monitorear una app Rails en producción?

Cero pesos si usás los planes gratuitos de UptimeRobot, cron-job.org o Better Stack. Los tres cubren el health check HTTP y el heartbeat de Sidekiq sin cobrar. Si tu app crece y necesitás más checks o heartbeats, existen planes pagos disponibles, pero para una app Rails estándar el plan gratuito suele alcanzar. Cubrimos ese tema en detalle en ejecutar agentes locales sin API.

¿Cómo sé si Sidekiq dejó de procesar sin mirar los logs?

Con un heartbeat job que actualiza un timestamp en Redis cada 5 minutos. Si el monitor externo ve que ese timestamp tiene más de 10 minutos, Sidekiq está vivo pero no está procesando. Es el fallo silencioso más común y los logs no muestran nada porque no hay excepción.

¿Qué diferencia hay entre un health check y un heartbeat?

El health check verifica que los componentes responden ahora mismo: base de datos, Redis, proceso de Sidekiq. El heartbeat confirma que un job se ejecutó hace pocos minutos, es decir, que el sistema está procesando trabajo real. Podés tener health check en verde y Sidekiq completamente trancado.

Si querés profundizar en esto, tenemos un artículo sobre worker health checks.

¿Puedo recibir alertas en WhatsApp o Telegram en vez de Slack?

Sí. UptimeRobot y Better Stack soportan Telegram, Discord y Slack de forma nativa con webhooks. WhatsApp requiere un paso extra con Twilio o una API intermedia, pero no es recomendable: el costo y la latencia son mayores. Telegram es la alternativa más simple si no usás Slack.

¿Conviene usar la gema health_check o armar un controlador custom?

La gema health_check es más rápida y ya viene con checks para BD, Redis, Sidekiq, migraciones y caché. Un controlador custom te da control total sobre qué exponer y cómo. Para la mayoría de los casos, la gema alcanza. Si necesitás lógica de negocio en el health check (verificar que un endpoint externo responda, por ejemplo), armalo custom.

Conclusión

Hoy en día, monitorear una app Rails no requiere contratar servicios caros ni montar infraestructura compleja. Con un health endpoint, un heartbeat de Sidekiq y 30 minutos de configuración, pasás de enterarte de las caídas por un mail del cliente a recibir una alerta en Slack antes de que el error afecte a alguien.

Lo que cambió respecto a años anteriores es que herramientas como Better Stack, UptimeRobot y cron-job.org maduraron sus planes gratuitos al punto de cubrir el 100% de las necesidades de monitoreo de una app Rails chica o mediana. Ya no hay excusa para no tener visibilidad sobre lo que pasa en producción.

Si tu app maneja pagos, emite facturas o tiene usuarios que dependen de notificaciones, poné el heartbeat de Sidekiq hoy. Esas 10 líneas de código valen más que cualquier dashboard que mires una vez por semana.