Un agente de código cambia tu app y el despliegue sale “correcto”, pero el formulario de pago deja de cargar. Cada minuto en producción importa. Pedirle al agente otro parche mientras los usuarios siguen encontrando el fallo puede alargar el incidente. Si la app está desplegada en Vercel, una opción es volver a una versión de producción anterior que ya funcionaba y después investigar el cambio. El detalle que no puedes olvidar: volver al código anterior no devuelve automáticamente tu base de datos ni todas las configuraciones.

La guía oficial de Vercel describe una secuencia de recuperación: confirmar el fallo, hacer rollback, verificar servicio, identificar el despliegue problemático y preparar la corrección. No es una función exclusiva de apps hechas con IA, pero se vuelve especialmente útil cuando el agente ha modificado varias áreas y aún no sabes cuál rompió el flujo.

Antes de tocar producción, identifica una versión sana

Revisa el despliegue actual, los errores y la hora en que comenzó el problema. En la CLI, la guía de Vercel propone consultar logs de producción y listar despliegues; en el panel puedes ver las versiones anteriores. Elige una versión que realmente sirvió tráfico en producción y que pasó una prueba básica del flujo crítico. No confundas una vista previa nunca publicada con un candidato elegible para Instant Rollback.

La disponibilidad depende del plan: según Vercel, en Hobby puedes volver al despliegue de producción inmediatamente anterior; Pro y Enterprise permiten seleccionar otros despliegues elegibles. Un despliegue elegible es uno que ya estuvo asociado a un dominio de producción. Si tu última versión sana no está disponible, necesitas otro plan de recuperación; no fuerces una versión que sabes incompatible.

La acción de recuperación y su comprobación

Si confirmaste que producción está rota y existe una versión anterior sana, abre el proyecto en Vercel, busca Instant Rollback en el despliegue de producción, selecciona el objetivo y revisa los dominios antes de confirmar. La guía también muestra la CLI:

vercel rollback
vercel rollback status

El primer comando cambia el despliegue servido por el dominio; el segundo permite comprobar el estado. No ejecuté estos comandos en tu proyecto: son instrucciones para un incidente real, no una prueba propia. Si tu app recibe tráfico, acuerda quién toma la decisión y anota el ID del despliegue anterior y del que falló. Después del rollback, abre el dominio público, prueba el formulario de pago o registro y revisa logs recientes. “Rollback completado” en el panel no equivale a “usuarios recuperados”.

Lo que puede seguir roto aunque vuelvas al build anterior

Vercel advierte que las variables de entorno no se actualizan automáticamente para coincidir con el build antiguo, que los cron jobs pueden volver al estado de esa versión y que servicios externos, CMS y bases de datos pueden haber cambiado. Un ejemplo concreto: el agente añadió una columna y migró la base de datos. El código antiguo quizá no entiende ese esquema; apuntar el dominio al build anterior puede dejar el error intacto o crear uno nuevo. Antes de hacer rollback, revisa si el despliegue defectuoso ejecutó migraciones, cambió contratos de API o modificó datos.

Si hubo una migración, la decisión requiere evaluar compatibilidad entre versiones y un plan de datos aparte. No deshagas una base de datos a ciegas ni asumas que Vercel la revierte. Mantén copias de seguridad y procedimientos propios del proveedor de datos. Si el fallo se debe a una credencial rotada, volver al build anterior tampoco restaurará la credencial vieja.

Después: arregla la causa y vuelve al flujo normal

Una vez que los usuarios puedan completar la tarea, compara los commits y logs del despliegue que falló. Dale al agente una tarea delimitada: “El despliegue X rompió el envío del formulario; reproduce el error en preview, identifica la causa, añade una prueba que falle antes del arreglo y enséñame el diff. No promociones nada hasta revisar el flujo.” Esa instrucción produce evidencia para la siguiente decisión, no otro parche a ciegas.

Vercel señala que tras un Instant Rollback se desactiva la asignación automática del dominio de producción a nuevos pushes. Cuando tengas un build corregido y verificado, usa el flujo de Undo Rollback o promoción apropiado para restaurar el comportamiento normal. Si olvidas este paso, podrías creer que tus futuros pushes están en vivo cuando no lo están.

La práctica recomendable esta semana es un simulacro en un proyecto de prueba: crea dos despliegues inocuos, confirma qué versión sirve el dominio, ensaya la reversión y documenta cómo comprobar el flujo crítico. No hagas el ejercicio en una app con clientes reales solo para “ver si funciona”. El resultado útil es saber qué despliegue elegir, qué datos quedan fuera del rollback y cómo confirmar que la recuperación fue real.

Fuentes: Vercel: Rolling back a production deployment; Vercel: Instant Rollback. Consultadas el 2 de noviembre de 2026.