Por qué Render tarda en responder tras un tiempo sin visitas y cómo medirlo
Publicado el 2026-11-14 por frfrand
Qué son los arranques en frío de Render, cómo medir la primera petición y cuándo usar un servicio de ejecución permanente.
Tu API responde rápido durante las pruebas, pero la primera visita después de varias horas tarda demasiado. Puede tratarse de un arranque en frío: la plataforma tuvo que volver a iniciar el proceso antes de servir la solicitud. No toda lentitud en Render es un cold start: DNS, consultas SQL y servicios externos también pueden generar retrasos.
1. Qué ocurre en una instancia gratuita
Según la documentación de Render, sus web services gratuitos se detienen tras 15 minutos sin tráfico entrante HTTP o mensajes WebSocket y el primer acceso vuelve a activarlos. La reactivación puede tardar alrededor de un minuto. Los planes de cómputo de pago no se suspenden por inactividad de esa manera. Esto puede cambiar, por lo que conviene consultar la documentación actual antes de elegir plan.
2. Mide primera petición y peticiones siguientes
Haz una prueba controlada: espera un intervalo de inactividad superior al umbral de suspensión, realiza una petición y repite inmediatamente varias veces.
curl -sS -o /dev/null -w \
'DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n' \
https://tu-api.example/healthRegistra al menos fecha, tiempo total y TTFB. Para comparar, ejecuta la misma prueba en un periodo con tráfico estable. No confundas una petición a /health con una prueba funcional completa: el endpoint podría responder aunque la base de datos esté caída.
3. Otras causas que debes descartar
- Inicialización de la aplicación: importaciones pesadas, migraciones al arrancar y carga de modelos. - Base de datos: conexiones iniciales, DNS y primeras consultas. - Servicios externos: OAuth, almacenamiento remoto y APIs lentas. - Infraestructura: CPU o memoria insuficiente, despliegues o reinicios.
Para distinguirlas, incluye trazas en el arranque y mide consultas, conexiones y llamadas externas. Una llamada rápida tras reiniciar no demuestra por sí sola que el problema sea el plan.
4. ¿Cuándo pagar por ejecución permanente?
Para demos, pruebas técnicas y aplicaciones con visitas esporádicas, un tiempo inicial más alto puede ser tolerable. Para webhooks, cobros, chat en tiempo real, autenticación y APIs con acuerdos de disponibilidad, evalúa un servicio permanentemente activo.
No es recomendable depender de pings periódicos diseñados solo para impedir el reposo: pueden resultar frágiles y no resuelven el problema de capacidad.
5. Decisión práctica
Si la demora aparece únicamente tras inactividad y coincide con el comportamiento documentado, compara un plan de pago de Render con un servidor siempre activo. Si también aparece bajo carga continua, optimiza el código y la base antes de cambiar de proveedor.
Consulta la comparativa ArduMaker frente a Render, la guía de FastAPI en Render y cómo medir la latencia de tu API.
Preguntas frecuentes
### ¿Todas las aplicaciones de Render se duermen? No. El comportamiento documentado aplica a web services gratuitos.
¿Es lo mismo que una consulta SQL lenta?
No. Pueden producir síntomas parecidos; mide ambas rutas.
¿Una web estática también sufre cold starts de backend?
Un sitio estático servido desde CDN no tiene ese proceso de backend propio, aunque las APIs que consume sí pueden experimentar latencia.
Fuente: Render, despliegues gratuitos.