Error 503 de Nano Banana Pro: qué hacer si aparece Deadline expired

Si Nano Banana Pro devuelve un 503, identifica qué servicio lo ha enviado y aplica una espera antes de repetir la petición con un límite de intentos y de tiempo. Conserva el modelo, la API y las especificaciones de imagen durante esa comprobación. Si recibes una imagen utilizable con esos mismos requisitos, has recuperado el trabajo; si agotas el límite, detén los envíos y decide cuándo retomarlo.

El texto Deadline expired before operation could complete también puede acompañar a un 503 UNAVAILABLE. No basta con leer la palabra Deadline para concluir que se trata de un 504 ni para aumentar el tiempo de espera del cliente. Primero mira el estado HTTP, los campos de error propios de la API y su origen.

Esta guía distingue tres situaciones que requieren acciones diferentes: una respuesta 503, una respuesta 504 y una conexión que termina sin respuesta. El objetivo es recuperar la generación sin añadir reintentos indefinidos ni dar por hecha una imagen que todavía no tienes.

Comprueba quién devuelve el 503 y qué formato utiliza

Un 503 significa que el servicio que responde no puede atender temporalmente la solicitud. La sobrecarga y el mantenimiento son causas posibles, según la definición HTTP del 503. El número por sí solo no identifica el recurso que falta, la duración del problema ni una caída general de Google.

Empieza por el destino de la petición: ¿llamas directamente a Google, a Vertex AI, a una pasarela de terceros o a tu propio servidor? Un backend puede devolver su propio 503 aunque la llamada al modelo no haya llegado a salir. Revisa sus registros y, cuando esté disponible, la respuesta original del proveedor. Si el origen sigue siendo desconocido, resuélvelo antes de automatizar nuevos envíos.

Tampoco todas las API representan el error igual:

La documentación de errores de Interactions utiliza códigos textuales. No debes imponer ese formato a generateContent ni tratar el mensaje completo de una excepción como si fuera un campo de estado. La implementación pública de APIError de Python consultada el 6 de octubre de 2026 define code como entero; eso no certifica todos los comportamientos de la versión instalada en tu aplicación.

Si el estado HTTP y el cuerpo se contradicen, conserva ambos y revisa la transformación que hace tu backend o pasarela. Una respuesta dudosa merece inspección, no una regla que reintente cualquier texto que contenga «overloaded».

Por qué un 503 puede mostrar Deadline expired

Hay un caso documentado en el foro de desarrolladores de Google en el que una petición al antiguo modelo de imagen en vista previa devolvió esta combinación:

{
  "error": {
    "code": 503,
    "message": "Deadline expired before operation could complete.",
    "status": "UNAVAILABLE"
  }
}

El caso pertenece a diciembre de 2025 y enero de 2026. Sirve para demostrar que ese mensaje y el 503 pueden coexistir; no prueba una incidencia actual ni que cambiar una opción concreta resuelva todos los fallos. En el hilo se comunicaron generaciones posteriores correctas, sin establecer un plazo de recuperación garantizado.

Cuando recibas esa combinación, conserva la clasificación 503 y sigue el procedimiento de recuperación limitado. Un tiempo de espera mayor en el cliente no elimina un plazo que el servidor ya ha dado por vencido.

Si estás revisando una integración antigua, comprueba además su modelo. El identificador oficial actual de Pro es gemini-3-pro-image; la página de retiradas de Google recoge la retirada de gemini-3-pro-image-preview el 25 de junio de 2026. Corregir un identificador retirado es una tarea de compatibilidad. Un alias que conserve una pasarela no demuestra que Google siga ofreciendo esa versión.

Cómo recuperar una petición 503 sin crear una ráfaga de reintentos

Para un 503 confirmado, la guía de solución de problemas de Gemini recomienda tratar los fallos transitorios con espera exponencial, variación aleatoria y límites. En una aplicación de imágenes conviene concretar esa recomendación así:

1. Guarda el estado del trabajo y conserva su petición. Anota proveedor, endpoint, modelo, resolución y relación de aspecto. Evita cambiar varias variables mientras compruebas la recuperación.
2. Decide si es seguro repetirlo. Una generación es una operación POST y HTTP no la convierte automáticamente en idempotente. Si el resultado anterior es incierto, comprueba primero si tu proveedor permite consultar ese trabajo o si tu aplicación ya recibió una salida. Un identificador local ayuda a organizarlo, pero no evita por sí solo una segunda generación o un segundo cargo.
3. Respeta Retry-After si viene en la respuesta. Puede indicar segundos o una fecha HTTP. Calcula la espera correspondiente; si supera el tiempo disponible para el usuario, deja el trabajo pendiente en vez de recortar la espera y enviar antes de lo indicado.
4. Si no hay Retry-After, aumenta la espera entre intentos y añade variación aleatoria. Así evitas que todos los trabajadores vuelvan a llamar a la vez. Limita también los envíos simultáneos; una cola debe aliviar la presión, no descargar una nueva ráfaga al reabrirse.
5. Detén la secuencia al alcanzar el número de intentos o el tiempo total. Una respuesta distinta de 503 abre otra investigación. Una respuesta correcta exige comprobar la imagen antes de marcar el trabajo como terminado.

El estándar HTTP explica tanto Retry-After como las condiciones para repetir operaciones no idempotentes. No hay un encabezado de idempotencia de Google que debas inventar para convertir cualquier repetición en segura.

Un ejemplo de política con tres intentos como máximo

La siguiente función solo decide el siguiente paso: no llama al modelo, no duerme ni implementa un trabajador completo. Puedes guardarla en politica_503.py y comprobarla sin conexión. Recibe el HTTP ya contrastado con el formato y el origen de la respuesta. retry_after_s, si existe, debe ser la espera en segundos calculada a partir de un encabezado válido. En el trabajador, pasa un valor aleatorio nuevo entre 0 y 1 como azar en cada intento; el valor fijo 0.5 permite reproducir el ejemplo, pero no introduce variación entre trabajadores.

def decidir(http, intento, transcurrido, *, origen_conocido,
            repeticion_segura, retry_after_s=None, azar=0.5):
    # intento incluye la petición original; transcurrido está en segundos.
    if intento < 1 or transcurrido < 0 or not 0 <= azar <= 1:
        raise ValueError("Valores de control inválidos")
    if retry_after_s is not None and retry_after_s < 0:
        raise ValueError("Retry-After debe convertirse en una espera no negativa")
    if not origen_conocido:
        return ("inspeccionar_origen", 0)
    if http is None:
        return ("comprobar_resultado_incierto", 0)
    if http == 200:
        return ("comprobar_imagen", 0)
    if http != 503:
        return ("investigar_otro_error", 0)
    if not repeticion_segura:
        return ("comprobar_antes_de_repetir", 0)
    if intento >= 3 or transcurrido >= 60:
        return ("dejar_pendiente", 0)
    espera = (retry_after_s if retry_after_s is not None
              else azar * min(12, 2 ** intento))
    # Reserva 15 s para el próximo intento dentro del presupuesto total.
    if transcurrido + espera + 15 > 60:
        return ("dejar_pendiente", 0)
    return ("esperar_y_reintentar", espera)

Tres intentos totales, 60 segundos globales y una reserva de 15 segundos por intento son elecciones de este ejemplo, no límites de Google ni tiempos normales de generación de Pro. Para aplicarlo, tu trabajador debe hacer cumplir el plazo global con un reloj monótono y no dejar que una llamada siga ejecutándose sin control. La reserva de 15 segundos exige un límite de llamada compatible; si tu trabajo necesita más tiempo, ajusta ambos presupuestos o sácalo de la espera interactiva. Si una llamada acaba sin respuesta, entra en la comprobación de resultado incierto antes de volver a enviarla.

Con un primer 503 tras 6 segundos, azar=0.5 propone esperar 1 segundo. Un segundo 503 con 18 segundos acumulados propone esperar 2. Tras el tercer 503, la decisión es dejarlo pendiente. Si el primer 503 llega a los 10 segundos con Retry-After: 50, también se deja pendiente: la espera y la reserva sumarían 75 segundos. El cálculo no acorta el encabezado del servidor para encajar artificialmente en 60.

Estas decisiones se han comprobado con estados y tiempos sintéticos. No son una medición de latencia ni una llamada real a Pro. Para conectar la política a una petición y guardar su resultado, tienes la guía de la API de Nano Banana Pro y guardado de imágenes.

Evita que SDK, aplicación y pasarela multipliquen los intentos

Elige una sola capa responsable de los reintentos y comprueba las demás. Tres intentos en la aplicación, combinados con reintentos del SDK y de una pasarela, pueden acabar en muchas más peticiones al proveedor.

No presupongas el comportamiento por defecto del SDK instalado. La guía de Google describe cuatro reintentos automáticos; la implementación pública de Python guardada el 6 de octubre de 2026 y leída localmente el 7 usa un solo intento con retry_options=None, mientras que unas opciones explícitas sin número de intentos conducen a cinco intentos totales en esa copia. Revisa la versión, la API utilizada y su configuración antes de envolverla en otro bucle. La función anterior no depende de esos valores por defecto.

Cuándo parar, poner el trabajo en cola o escalar el problema

Si se agota tu presupuesto, conserva el trabajo como pendiente, con su último error y la próxima hora en que podría retomarse. No lo presentes como una generación completada ni vuelvas a enviarlo continuamente desde el navegador. Una cola necesita su propio límite de concurrencia, una antigüedad máxima del trabajo y una política de caducidad o cancelación.

Si los 503 se repiten en muchos trabajos de la misma ruta, pausa temporalmente los nuevos envíos y conserva el estado de los existentes. Antes de reabrir el flujo, realiza una comprobación controlada en esa ruta y revisa el estado oficial y los registros disponibles. Un panel sin incidencias publicadas no invalida una respuesta 503 concreta.

Cuando necesites contactar con soporte, aporta hora y zona horaria, proveedor, endpoint, modelo, estado HTTP, campos de error, duración e identificador de solicitud si existe. Oculta claves, contenido privado e imágenes sensibles. Ese conjunto permite localizar el fallo sin convertir todo el prompt en material de diagnóstico compartido.

Tener una cuenta de pago no excluye el error. En un caso de producción de enero de 2026, el autor comunicó 503 y retrasos pese a tener un proyecto de pago. Sus tiempos observados no son un plazo universal, y el hilo no demuestra que subir de nivel resuelva la sobrecarga. No cambies facturación para intentar corregir un 503 sin un diagnóstico que lo justifique.

Si llega un 504 o no llega ninguna respuesta, cambia la comprobación

Un 504 HTTP indica que una pasarela o proxy no recibió a tiempo la respuesta que esperaba del servicio superior. En Interactions, Google documenta deadline_exceeded como 504. Eso no demuestra que tu cliente fuera el primero en dejar de esperar.

Si recibes un 504, compara los plazos del cliente, tu backend, cualquier proxy y el proveedor. Aumentar solo el tiempo de espera del cliente puede servir si era el límite más corto, pero no modifica un 504 que el servidor ya ha enviado. Revisa la complejidad de la petición y, si haces una prueba más ligera, cambia una sola variable y registra lo que has cambiado.

Si el cliente termina por timeout o desconexión sin respuesta HTTP, el resultado es incierto. No le asignes un 503 o 504 inventado. Consulta el estado o resultado del trabajo cuando tu API disponga de esa posibilidad; si no existe, decide expresamente si aceptas el riesgo de duplicación antes de repetir. Un timeout local no prueba que el servidor haya cancelado la generación.

Bajar de 4K a 2K puede ayudarte a comprobar una hipótesis sobre el tiempo necesario, pero entrega una especificación distinta. Una imagen ampliada después tampoco demuestra que se haya recuperado la generación 4K original. Pro ofrece varias resoluciones y relaciones de aspecto; la ficha del modelo es la referencia para comprobar tu requisito concreto.

La recuperación termina cuando tienes una imagen utilizable

Un HTTP 200 solo confirma una respuesta HTTP correcta. Para dar por recuperado un trabajo de imagen, comprueba el contenido que devuelve tu API:

• En generateContent, busca las imágenes en las partes de los candidatos, con sus datos inlineData y MIME.
• En Interactions, recorre los pasos model_output y los bloques de imagen de su content; las imágenes llevan data y mime_type.
• Decodifica los datos, comprueba que contienen una imagen que se puede abrir y guárdala con una extensión coherente con su MIME. Verifica dimensiones y los requisitos del trabajo antes de entregarla.

Son formatos distintos de la documentación de generación de imágenes. No mezcles el cuerpo de una API con el lector de respuestas de la otra. Si hay varias imágenes, revisa todas las que necesites; un acceso abreviado a la última no demuestra que hayas procesado el resultado completo.

Un 200 con texto, una tarea todavía en cola o una respuesta sin imagen no completa tu encargo. Examina el contenido y cualquier motivo de finalización o bloqueo. Un rechazo de contenido o no_image requiere su propia comprobación; no se arregla repitiendo indefinidamente la política 503 ni debilitando los controles de seguridad.

Para confirmar la recuperación del incidente original, compara proveedor, API, modelo, entrada y especificaciones de salida con los del trabajo fallido. Google recomienda Interactions para proyectos nuevos y sigue admitiendo generateContent, según su documentación de Interactions. Migrar entre ambas puede ser una decisión de integración, pero no es una prueba aislada de que haya desaparecido el 503 anterior.

Si cambia el error, cambia el siguiente paso

Para un 429, empieza por identificar qué límite de imágenes ha saltado. Los límites de Google pertenecen al proyecto, no a cada clave, según la documentación de cuotas. Crear más claves en el mismo proyecto no añade cuota ni resuelve un 503.

Si necesitas una ruta alternativa para cumplir una entrega urgente, evalúala como un cambio de servicio. Cambiar proveedor, modelo o resolución puede cambiar capacidades, parser, costes y tratamiento de datos. En particular, la documentación de imágenes de LaoZhang diferencia su interfaz nativa de la compatible con OpenAI; esta última no debe presentarse como equivalente a una petición nativa de Google en 4K. Que otra ruta genere una imagen no demuestra que la anterior se haya recuperado.

Aviso: laozhang.ai es un servicio propio. Sus precios son nuestra tarifa, no una comparación independiente.

Preguntas frecuentes

¿Cuánto tarda en desaparecer el error 503 de Nano Banana Pro?

No hay un plazo universal documentado. Respeta Retry-After cuando exista y aplica tu límite de intentos y de tiempo. Si se supera, deja el trabajo pendiente o comunica el fallo; los tiempos de un caso de foro no son una garantía para tu aplicación.

¿Tengo que aumentar el timeout si el mensaje dice Deadline expired?

No automáticamente. Si la respuesta es 503 UNAVAILABLE, empieza por el origen y la política limitada de recuperación. Si hay un 504 o tu cliente acaba sin respuesta, compara los plazos y comprueba el resultado incierto. Aumentar el tiempo de espera local no borra un plazo vencido en el servidor.

¿Pasar a un nivel de pago o cambiar la clave resuelve un 503?

No hay base para tratarlo como solución general. Un error de pago, permisos o cuota requiere su diagnóstico correspondiente. También se han comunicado 503 en proyectos de pago. No confundas una recuperación posterior con prueba de que el cambio de cuenta la causó.

¿Los intentos fallidos son siempre gratuitos?

No puedes deducirlo del número 503 ni de un timeout sin respuesta. Comprueba las reglas y el uso registrado del proveedor de esa petición. La documentación de LaoZhang, por ejemplo, indica que sus respuestas HTTP 200 se cobran incluso sin imagen. Un «fallo» para tu aplicación y un fallo facturable pueden tener definiciones diferentes.

¿Puedo bajar a 2K o cambiar de modelo para salir del paso?

Sí, si ese resultado cumple la entrega y aceptas el cambio. Trátalo como una alternativa: verifica la imagen y sus requisitos. Si el trabajo exigía Pro en 4K, un éxito con otro modelo o resolución no demuestra que se haya recuperado ese trabajo.