Por qué no funcionan los bots en Telegram?

1) Comprueba el token en BotFather y los comandos /setcommands y /setprivacy. 2) Deja un solo canal de actualizaciones: webhook o polling (409 = ambos activos). 3) Consulta getWebhookInfo — last_error_message debe estar vacío, el hook debe devolver 200 OK en menos de 10 s, sin 301/302. 4) Comprueba los permisos en el chat y la forma de invocar /cmd@YourBot en el grupo. 5) Activa los logs update_id, chat_id, type, handler, duration_ms, reply_status y repite el test en PM y en el grupo de pruebas. 6) Si hay «silencio» — activa temporalmente el polling y busca problemas de red/TLS/handler.

Cuando todas las comprobaciones estén superadas y el bot responda con estabilidad, ejecuta el embudo con usuarios reales en pequeñas oleadas de tráfico. Impulso de suscriptores en Telegram ayudará a generar un flujo inicial para medir el p95 de respuesta, el error rate, el CTR de los comandos y la conversión a la acción objetivo. Distribúyelo de forma uniforme durante 30-60 minutos, compara las métricas antes y después y registra el ritmo seguro.

Qué comprobar antes de empezar el diagnóstico

Token y BotFather: validez del token, si no está revocado, si /setcommands y /setprivacy están configurados

Abre BotFather y asegúrate de que el token está vigente y de que no has ejecutado /revoke recientemente. Compara /setcommands y el scope necesario (por defecto/para grupos/para mensajes privados) con lo que está realmente en el código. Comprueba /setprivacy: Enabled si el bot solo trabaja con comandos, Disabled si lee mensajes ordinarios. En mi experiencia, este bloque resolvía el «silencio» del bot en 3 de cada 10 casos.

Canal de actualizaciones: si está activo el webhook o el long polling, si ambos están ejecutándose al mismo tiempo

El bot debe tener una sola forma de recibir eventos: o bien webhook, o bien long polling. Ejecutar ambos a la vez genera 409 Conflict y duplicados, por lo que debes desactivar el canal sobrante antes de la prueba. Para el polling, llama primero a deleteWebhook?drop_pending_updates=true; para el webhook, detén el poller. «Mi prueba rápida»: eliminar un canal y comprobar si desaparecen los duplicados.

Estado del webhook: getWebhookInfo, si hay last_error_message, si el hook responde 200 OK en menos de 10 s

Ejecuta getWebhookInfo y comprueba url, last_error_message e ip_address. Los errores de TLS/timeout/wrong response se corrigen en el lado de la red/certificado/handler; la respuesta del servidor debe ser 200 OK rápida (idealmente menos de 2 segundos, máximo 10). Sin redirecciones ni páginas HTML en lugar de JSON. Yo siempre elimino el webhook con drop_pending_updates y lo vuelvo a registrar después de aplicar el fix.

Ejemplo de solicitud y respuesta típica (last_error_message relleno):

curl -s https://api.telegram.org/bot$TOKEN/getWebhookInfo | jq .

{
  "ok": true,
  "result": {
    "url": "https://your.domain/bot-hook",
    "has_custom_certificate": false,
    "ip_address": "149.154.xx.yy",
    "pending_update_count": 12,
    "last_error_date": 1731085200,
    "last_error_message": "SSL routines: certificate verify failed",
    "max_connections": 40
  }
}

Resultado esperado «tras el fix»: last_error_message ausente/vacío, pending_update_count → 0, el hook responde 200 OK de forma estable en menos de 2 s.

Permisos y contexto: el bot no está bloqueado, tiene permisos para escribir, en el grupo el comando se invoca como /cmd@YourBot

En el chat privado el usuario debe iniciar el diálogo primero; de lo contrario se produce un 403 Forbidden. En el grupo con Privacy Mode activado, el comando se invoca como /cmd@YourBot; si no, el bot no lo verá. Comprueba los permisos «escribir/medios/fijar/eliminar» y el rol de administrador donde sea necesario. Una sola verificación de permisos suele ahorrar una hora de depuración.

Si tras estas comprobaciones básicas el bot sigue «en silencio», tiene sentido recorrer el checklist ampliado y analizar con calma por qué el bot no funciona en Telegram: desde los permisos en los chats y los bloqueos por parte de los usuarios hasta los errores en los handlers, el webhook y la infraestructura de red.

Prueba rápida: escribir al bot en privado y en el grupo de pruebas, revisar los logs de actualizaciones

Envía /start en el chat privado y el mismo comando en un «sandbox» limpio sin restricciones. Activa el log ampliado: update_id, chat_id, type, handler, duration_ms, reply_status. Si no llegan actualizaciones, busca el problema en la entrega (webhook/polling/TLS); si llegan, revisa la lógica y los permisos. Esta «prueba cruzada» muestra de forma consistente dónde está el problema.

Panorama de síntomas: el bot no reacciona, está en silencio, no arranca

No responde en mensajes privados

El usuario no ha escrito primero, el bot está bloqueado o hay un 403 en sendMessage. Pide al usuario que pulse /start y gestiona el 403 sin reintentos (no hagas spam repetido). Comprueba si hay un límite de frecuencia 429: activa el backoff y las colas. En mis casos, esto resolvía 8 de cada 10 «silencios» en PM.

No reacciona en el grupo o el canal

Privacy Mode activado y el comando sin mención no es visible, o el bot no tiene permisos para escribir. En el canal solo se puede publicar con permisos de administrador; es una norma de la plataforma. Comprueba las restricciones del supergrupo: slow mode, antispam, prohibiciones de enlaces/medios. La prueba en el sandbox separa inmediatamente la política del grupo de los problemas del código.

Los botones no funcionan: no llega el callback

Comprueba si el handler está suscrito a callback_query y si no se supera la longitud de callback_data. Escapa Markdown/HTML en los botones y asegúrate de que el Content-Type es correcto. Revisa los logs: ¿llega update.callback_query y qué devuelve la respuesta a edit/answerCallbackQuery? Con frecuencia el problema no está en los «botones» sino en la validación del payload.

Los mensajes se envían con retraso o se duplican

Mira el 429 Too Many Requests, la cola de mensajes y el número de workers paralelos. Los duplicados se corrigen con idempotencia (sin reprocesamiento) y almacenando last_update_id. Los retrasos se deben a límites, operaciones largas en el handler o un upstream lento. Mueve lo pesado al fondo y limita el paralelismo.

Token y configuración en BotFather

Token incorrecto o revocado: /revoke y emisión de uno nuevo con /token

Tras /revoke la clave antigua muere de inmediato: actualiza los secretos en env/CI/CD y reinicia los procesos. Comprueba si hay contenedores «atascados» con el token antiguo. Verifica que estás usando el token correcto en staging/prod (la confusión es frecuente). En mi práctica, la desincronización de tokens rompía el bot durante horas sin un solo error en los logs.

Privacy Mode y trabajo en grupos: cuándo desactivarlo, cómo invocar comandos con @username

Si necesitas leer mensajes ordinarios en el grupo, desactiva /setprivacy (Disabled) y añade filtros por chats/roles. De lo contrario, usa solo comandos e inline, e invoca siempre /cmd@YourBot en el grupo. Esto es transparente para los usuarios y predecible para ti. Yo siempre documento la forma de invocar el comando en el README.

Comandos y menú: /setcommands correctos, locales, descripciones y permisos del bot

Mantén los comandos separados para el chat privado y los grupos mediante el scope en BotFather. Vigila los locales de las descripciones; de lo contrario los clientes no sugieren los comandos. Comprueba que los nombres coinciden con el código y que el bot tiene permisos para los comandos que implican publicar/eliminar. Son detalles pequeños, pero suelen «tirar» la funcionalidad.

Canal de actualizaciones: webhook vs long polling

Elegir un solo canal: por qué no pueden coexistir

Dos canales simultáneos generan 409 Conflict y duplicados. Mantén un único punto de recepción de actualizaciones y elimina las condiciones de carrera entre instancias. Fija en .env la variable UPDATES_MODE=webhook|polling y valídala en el proceso de release. Esto ahorrará tiempo y quebraderos de cabeza.

Configurar setWebhook y verificar getWebhookInfo

Registra el webhook en un dominio HTTPS público y comprueba getWebhookInfo tras activarlo. El campo last_error_message debe estar vacío; la respuesta del servidor debe ser 200 OK sin redirecciones. En las migraciones, elimina la cola con drop_pending_updates=true para no recibir una avalancha de actualizaciones antiguas. «Mi orden»: health → setWebhook → control de getWebhookInfo.

Pasar a getUpdates: offset, timeout, drop_pending_updates

Para depurar, elimina el webhook y activa el polling con timeout de 25-30 segundos. Almacena last_update_id y desplaza el offset en +1 para no recibir duplicados. Tras aplicar el fix, restaura el webhook y detén el poller en todas las instancias. Esto elimina el conflicto y hace predecible el flujo de eventos.

El webhook no funciona: TLS, DNS, redirecciones, proxy

Certificados: CA público, cadena completa, SNI, fecha de expiración

El certificado debe ser de una CA pública, con cadena completa (intermediate), SNI correcto (nombre del servidor en TLS) y CN/SAN (nombre de dominio en el certificado). Un certificado caducado, autofirmado o incompleto «silencia» el webhook sin errores evidentes en el bot. Comprobación rápida con un solo comando:

echo | openssl s_client -servername your.domain -connect your.domain:443 -showcerts 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Comprueba issuer/subject/dates y que CN/SAN coinciden con el dominio.

Nginx/Apache: proxy_pass, client_max_body_size, timeout, HTTPS sin 301

Comprueba que el reverse proxy no genera 301/302 ni reescribe Host/SNI. Configura timeouts razonables, client_max_body_size y pasa las cabeceras de IP real. Devuelve 200 OK rápidamente y no envíes páginas HTML en lugar de una respuesta «vacía». Los logs a nivel de proxy aceleran mucho la búsqueda de causas.

Healthcheck del hook: 200 OK, tiempo de respuesta, log del cuerpo de la actualización

Crea un endpoint /bot-hook/health que devuelva 200 OK, la versión del build y el uptime. Registra el tiempo de respuesta (duration) y las marcas de correlación para detectar picos. Escribe el cuerpo de la actualización entrante en el log de debug para reproducir eventos infrecuentes. Esto convierte el «misterio» en un diagnóstico gestionable.

El checklist detallado para interpretar estas métricas y encontrar las causas reales del «silencio» del bot está en el análisis «Por qué el bot de Telegram no reacciona a los comandos»: es útil tenerlo a mano cuando el health-check está en verde pero los usuarios siguen sin recibir respuestas.

Checklist de infraestructura (nginx/proxy/TLS/DNS/MTU)

• nginx timeouts: proxy_read_timeout 10s; proxy_connect_timeout 3s; — mantén la respuesta por debajo de 10 s.
• no 301/302: el webhook no debe redirigir — Telegram espera un 200 OK directo.
• full chain: el servidor debe entregar toda la cadena (incluido intermediate); de lo contrario certificate verify failed.
• SNI/CN: SNI activado, CN/SAN deben coincidir exactamente con el dominio del webhook.
• MTU/fragmentación: ante timeouts extraños, comprueba el MTU con traceroute; reduce el MTU en la interfaz/túnel.
• Headers: preserva Host y añade X-Request-Id para la trazabilidad.

Crea un endpoint /bot-hook/health que devuelva 200 OK, la versión del build y el uptime. Registra el tiempo de respuesta (duration) y las marcas de correlación para detectar picos. Escribe el cuerpo de la actualización entrante en el log de debug para reproducir eventos infrecuentes. Esto convierte el «misterio» en un diagnóstico gestionable.

El long polling no recibe actualizaciones

Parámetros de getUpdates: offset, limit, timeout

Configura timeout=25-30 y almacena last_update_id desplazando el offset en +1. Vigila el limit para no lanzar peticiones vacías ni chocar con los límites. Este modo es robusto y ahorra tráfico. En producción el polling es una medida temporal, pero para depurar es ideal.

Concurrencia de workers e idempotencia de los handlers

No permitas dos pollers con el mismo token: genera duplicados y condiciones de carrera. Marca los update_id procesados (tabla/Redis) y mantén los handlers idempotentes (el reintento es seguro). Cualquier efecto secundario (pago, abono) solo debe ocurrir después de marcar como «procesado». Esto es lo que protege tu dinero.

Timeouts de red, proxy, NAT, bloqueos del proveedor

Comprueba los timeouts del cliente HTTP y el proxy; activa el backoff y los reintentos para fallos transitorios. Permite las conexiones salientes a api.telegram.org:443 y comprueba el MTU si la red «se rompe». Si el proveedor corta el tráfico, pasa al webhook y monitoriza el tiempo de respuesta. Este bloque se subestima con frecuencia.

Permisos y accesos en los chats

El bot no es administrador: sin permisos de lectura/escritura, restricciones del supergrupo

Sin permisos de «escribir/medios/fijar» el bot «callará» en el grupo aunque el código sea correcto. Los supergrupos añaden slow mode y antispam, que visualmente «silencian» la actividad. Otorga al bot los permisos necesarios y pruébalo en el sandbox. En mis proyectos, esta fue siempre la victoria más rápida.

El bot está bloqueado por el usuario o el chat es privado

Un 403 en sendMessage significa «bloqueado» o chat privado. No reintentes en ese diálogo: consume límites y resulta molesto. Crea un FAQ de «cómo escribir al bot en privado» y pide al usuario que inicie el chat primero. Esto reduce las quejas y aumenta la confianza.

Canales y debates: publicación a través del bot, permisos de publicación

El bot solo publica en un canal como administrador; no es un bug, es una norma de la plataforma. Activa los debates si necesitas diálogo bajo la publicación y asegúrate de que el bot tiene permiso para escribir en el grupo vinculado. Comprueba las restricciones de enlaces/medios para que las publicaciones no reboten. Estos pasos se omiten con frecuencia en los requisitos y luego sorprende el «silencio».

Límites y formatos de Telegram Bot API

Referencia de rate-limit (orientativo)

Telegram no publica cifras exactas para todos los métodos. A continuación se muestran los límites prácticos y las recomendaciones; contrasta con la documentación oficial.

Backoff con jitter: base 0,5-1,5 s, multiplicar ×2 hasta 30 s, añadir jitter aleatorio. Ante un 429, reduce la frecuencia y pon cola.

400 Bad Request: parámetros incorrectos, codificaciones, Markdown/HTML

Comprueba Content-Type: application/json, las longitudes de los campos y el escape de Markdown/HTML. Valida emojis, texto RTL y pies de foto largos. Prueba los casos extremos de antemano: los 400 «silenciosos» no son evidentes. Esto ahorra horas de soporte nocturno.

401/403 Unauthorized/Forbidden: token, prohibición de PM, permisos

401: token incorrecto/revocado (obtén uno nuevo y actualiza env). 403: sin permisos/usuario bloqueó (no reintentes; pide que escriba primero). Acompaña estos códigos con respuestas claras al usuario y logs para el equipo. Una gestión honesta de errores genera confianza.

409 Conflict, 413 Payload Too Large, 429 Too Many Requests, 5xx

409: polling y webhook activos simultáneamente (desactiva un canal). 413: archivo demasiado grande (comprime/divide; envía como documento). 429: límite superado (colas, backoff, reducción de frecuencia y batching). 5xx: fallos del upstream (gateway/servidor externo); se resuelve con reintentos y monitorización del tiempo de respuesta.

Lógica y código del bot

Excepciones no capturadas, crasheos del worker, ausencia de reintentos

Añade una captura global de errores y reinicio mediante watchdog. Registra los crasheos y el tiempo de procesamiento (duration_ms) para ver los «cuellos de botella». En las llamadas externas, aplica timeouts y reintentos con jitter; el usuario debe ver una respuesta amigable, no silencio. Esta es la higiene básica del bot.

En esencia, esta es la respuesta práctica a la pregunta de por qué el bot no responde en Telegram: sin captura global de errores, reinicios por watchdog, timeouts y reintentos, cualquier fallo en las llamadas externas se convierte en silencio para el usuario, aunque el problema esté en uno o dos «cuellos de botella» de duration_ms.

Handlers incompletos: olvidados callback_query, inline, edited_message, channel_post

Revisa la lista de tipos de actualización: message/command, callback_query, inline_query, edited_message, channel_post. Añade stubs y logs para eventos inesperados: el bot no debe «caer en silencio». Por experiencia, un callback_query olvidado es la causa de uno de cada tres «fallos» de botones. Actualiza el esquema según la documentación tras cada release de Telegram.

Operaciones bloqueantes, llamadas externas largas, ausencia de colas

No mantengas operaciones largas en el webhook o el poller: muévelas a cola/workers. Limita el paralelismo y mantén la idempotencia de los efectos secundarios (pago/bonificación). Mide el p95/p99 del tiempo de respuesta y desplaza lo pesado «al fondo». Así el bot sigue siendo responsivo.

Integraciones y APIs externas

Claves y cuotas, tokens caducados, 4xx/5xx de servicios externos

Comprueba la validez de las claves, las cuotas y el SLA de los socios. Ante 4xx/5xx, aplica «degradación suave» y textos claros al usuario, no silencio. Ten a mano los enlaces a las páginas de estado de los proveedores. Esto ahorra dinero y nervios.

Timeouts, backoff exponencial, circuit breaker

Configura timeouts en los clientes HTTP y reintentos exponenciales con jitter (base 0,5-1,5 s, multiplicar ×2 hasta 30 s). Activa el circuit breaker en las rutas inestables. Actualiza los textos durante la degradación para mantener la confianza. Yo siempre mantengo este middleware unificado para todas las llamadas externas.

Sanitización de datos entrantes y protección contra inyecciones

Valida JSON/formularios con esquema y escapa los caracteres especiales (sanitize/escape). Escapa Markdown/HTML y emojis en los pies de foto/botones y comprueba las longitudes de los campos. Nunca confíes en «como en el ejemplo de internet»: verifica siempre. Esto elimina los 400 «silenciosos» y los riesgos de XSS.

Seguridad y cumplimiento

• Secretos: almacena tokens/claves en un gestor de secretos (Vault/Secrets Manager); no los registres en logs ni los subas al repositorio.
• Perímetro: restringe los puertos entrantes con firewall/SG; permite las conexiones salientes a api.telegram.org:443 y a las páginas de estado de los proveedores.
• Logs: enmascara los datos personales y los tokens; activa una alerta de «token en los logs».
• Configuración: fija UPDATES_MODE=webhook|polling en .env, valídalo en CI/CD para garantizar que el segundo canal está desactivado.

Red e infraestructura

Firewalls, puertos, listas blancas de IP, Cloudflare/Reverse proxy

Abre las conexiones salientes a api.telegram.org:443 y las entrantes al puerto del webhook. Comprueba las cabeceras Host/SNI en el proxy/Cloudflare y la ausencia de redirecciones. Las listas blancas de IP de Telegram a veces son necesarias en el hosting: consúltalo. La traza de red y la verificación de MTU me han ahorrado semanas buscando timeouts «fantasma».

DNS e incompatibilidades IPv4/IPv6, cambio de IP/dominio

Comprueba los registros A/AAAA y el TTL, especialmente tras las migraciones. La incompatibilidad de IPv6 causa timeouts en algunos clientes: o activas la compatibilidad o eliminas el registro AAAA. Espera a que el DNS se propague antes de activar el webhook. Es un paso sencillo que se suele olvidar.

Serverless y contenedores: cold start, límites de CPU/RAM, colas

El cold start de las funciones destruye el 200 OK: mantén el calentamiento, aumenta memory/CPU y mueve lo pesado al fondo. Vigila la profundidad de las colas y el tiempo de procesamiento: son el indicador más temprano de problemas. Configura las pruebas de health y readiness para que el orquestador no elimine workers sanos. En producción no es un lujo, es una necesidad.

Tabla: síntoma → causa → qué comprobar

Tabla: códigos y límites de Bot API → descripción y soluciones

Fixes típicos (resumido): TLS — publicar el intermediate y verificar SNI/CN; 409 — eliminar un canal (deleteWebhook?drop_pending_updates=true) y dejar un único receptor; 429 — activar backoff+colas y reducir la frecuencia.

Árbol de decisión: del síntoma a la solución

Sin actualizaciones en absoluto: rama webhook vs polling

Primero determina qué canal está activo. Para el webhook: getWebhookInfo → ¿hay last_error_message?, 200 OK sin redirecciones → verificación de TLS/DNS. Para el polling: un solo poller, offset/timeout correctos → logs de actualizaciones. Si ambos pasos están limpios, revisa permisos y código.

Funciona en privado, no funciona en el grupo: rama de Privacy Mode/permisos

Comprueba /setprivacy y la forma de invocar el comando: /cmd@YourBot o reply. Asegúrate de que el bot tiene permisos de «escribir/medios/fijar/eliminar». Revisa la política del supergrupo: slow mode/antispam/prohibición de bots. ¿El problema se reproduce en el sandbox? Si no, son los ajustes del grupo.

Errores 4xx/5xx: rama de token, límites, APIs externas, reintentos

401: reemitir el token y actualizar env. 403: permisos/bloqueo en PM; responder de forma amigable y no reintentar. 429: reducir la frecuencia, activar colas y backoff exponencial con jitter. 5xx: reintentos, monitorización de latencias, degradación de la función sin silencio.

Checklist antes del release y durante el incidente

Antes del release: token, /setcommands, privacy, permisos, webhook 200 OK, timeouts

Token actualizado, /setcommands y /setprivacy acordes al escenario (privado/grupo). El webhook devuelve 200 OK rápidamente, la cadena TLS está completa y SNI/CN son correctos. Se ha elegido un solo canal de actualizaciones y está fijado en .env/orquestador; el segundo está desactivado. Timeouts/límites/colas/monitorización activados.

Durante el incidente: registrar el canal de actualizaciones, activar logs detallados, pasar temporalmente a polling

Registra el modo activo (webhook o polling) y desactiva el otro. Activa el log ampliado de actualizaciones y errores; reinicia los workers/contenedor. Pasa temporalmente a polling para no perder eventos y, en paralelo, corrige el webhook/TLS/código. Tras el fix, restaura el webhook y verifica que last_error_message está vacío y que el p95 está dentro del rango normal.

Tras la recuperación: monitorización de latency/error rate, alertas sobre last_error_message, retrospectiva y actualización de la documentación

Configura una alerta sobre getWebhookInfo.last_error_message != "" (Slack/Email), monitoriza el p95 del tiempo de respuesta y la proporción de 5xx. Actualiza el README: matriz de permisos, orden de activación/conmutación de canales, comandos de BotFather. Realiza la retrospectiva, registra los cambios en el change log y revisa los checklists del equipo.

Enlaces oficiales de Telegram

• Bot API (documentación): https://core.telegram.org/bots/api
• setWebhook / getWebhookInfo: https://core.telegram.org/bots/api#setwebhook • https://core.telegram.org/bots/api#getwebhookinfo
• Privacy Mode (BotFather): https://core.telegram.org/bots/features#privacy-mode

FAQ: formulaciones frecuentes de los usuarios y respuestas

Por qué el bot no reacciona a los comandos en el grupo pero sí responde en privado

Lo más probable es que en el grupo esté activado el Privacy Mode o que el bot no tenga permisos para escribir/leer. Usa la forma /cmd@YourBot o desactiva la privacidad si necesitas acceso a los mensajes ordinarios. Otorga al bot los permisos necesarios y repite la prueba. Si en el grupo de pruebas todo va bien, la causa está en la configuración del grupo objetivo.

Por qué el webhook devuelve 409 y cómo resolver el conflicto

409 significa que webhook y polling están activos simultáneamente. Desactiva un canal: deleteWebhook?drop_pending_updates=true o detén el poller, dejando un único punto de recepción. Comprueba el .env y los procesos en las instancias para asegurarte de que no hay pollers «olvidados». Tras el fix, comprueba getWebhookInfo: no debe haber errores.

Por qué los botones no funcionan y no llega callback_query

Comprueba la suscripción a callback_query, la longitud de callback_data y el escape de Markdown/HTML. Registra en logs los update.callback_query entrantes y la respuesta a answerCallbackQuery/editMessage. Si el evento no llega, comprueba los permisos, el antispam del grupo y los límites de frecuencia. Estas son las causas más frecuentes del «silencio» de los botones.

Cómo saber si el problema está en el certificado y no en el código o los permisos

Si last_error_message apunta a TLS/timeout/wrong response, corrige la red/TLS/servidor web. Comprueba la cadena y el SNI con un solo comando openssl s_client (ejemplo arriba) y repite getWebhookInfo. Si el polling recibe actualizaciones pero el webhook no, en la mayoría de los casos el código no tiene nada que ver. Tras el fix, el error desaparece en minutos.

Por qué el bot empezó a responder con retraso por la noche y cómo solucionar el rate limit

Mira el 429 y la frecuencia de llamadas a los métodos: puede que hayas alcanzado el límite. Comprueba la profundidad de las colas y el tiempo de procesamiento: son los primeros indicadores de cuellos de botella. Activa el backoff con jitter (base 0,5-1,5 s, ×2 hasta 30 s) y limita el paralelismo. Si es necesario, escala los workers y optimiza los fragmentos de código bloqueantes.