Un libro de recetas para agrupamiento de Sentry, bisección de versiones y estimación del impacto en usuarios cuando las sesiones sin fallos caen después de un rollout de tienda o una publicación OTA. Asume que la producción está configurada per Sentry for React Native e identidad de versión per Observability Basics.
Tarjeta de receta de referencia rápida - lista para copiar y pegar.
# 1. Confirma el pico (UI de Sentry o API)# Filtro: environment=production, última 1h vs baseline 24h# 2. Segmenta por versión nativa# Agrupa por: release (p. ej. 2.4.0+240012)# 3. Segmenta por dist OTA dentro de la versión principal# Agrupa por: dist (expo-updates updateId)# 4. Abre el clúster de incidencia principal - anota huella digital + first seen# 5. Correlaciona con la línea de tiempo de deployeas update:list --branch production --limit 5# App Store Connect: phased release % / Play: staged rollout %# 6. Contiene (en paralelo con triaje)# Pausa rollout / eas update:rollback / kill switch# 7. Estima impacto# delta de sesiones sin fallos × estimación de DAU = usuarios afectados
Cuándo usar esto:
Alerta de Sentry: las sesiones sin fallos cayeron >2% absoluto vs baseline 7-día
El volumen de tickets de soporte para "la app se cierra" se correlaciona con la ventana de alerta
Release Health muestra nueva huella digital de incidencia con rampa de first seen pronunciada
Cuándo escalar en lugar de bisecar:
Pico en todas las versiones e IDs de OTA simultáneamente - incidente de backend o CDN
SIGABRT solo nativo sin OTA nuevo - ruta de rollback de compilación de tienda, no reversión de canal
Solo stacks no simbolizadas - primero corrige la carga de mapa de fuente - ver EAS Build Basics
Abre Issues ordenadas por volumen de eventos en la ventana de alerta.
Clúster principal: Huella digital: checkout-screen-null-ref Primera vista: 2026-07-09 14:02 UTC Eventos: 4,200 (82% del pico) Versiones: 2.4.0+240012 solamente Dist: abc123-update-group (ID de OTA único)
Línea de tiempo en una pizarra o documento de incidentes:
| Hora UTC | Evento ||----------|--------|| 13:45 | Deploy de backend v892 - sin cambio móvil || 14:02 | eas update --channel production (grupo abc123) || 14:05 | Alerta de Sentry disparada || 14:08 | iOS en fase al 25% - compilación 240012 |
Árbol de decisión de bisección:
¿Fallo solo en dist abc123? SÍ → Sospecha OTA. eas update:view abc123. Revierte per OTA Emergency Rollback. NO → ¿Fallo en todos los valores de dist para versión 2.4.0+240012? SÍ → Sospecha binario nativo. Pausa versión en fase. Compilación de hotfix. NO → ¿Fallo en múltiples versiones nativas? SÍ → Backend / dependencia compartida. Involucra a API on-call.
# Bisección de OTAeas update:list --branch production --limit 5eas update:view <suspect-group-id># Git bisect (después de identificar el SHA sospechoso)git log --oneline <last-good-sha>..<suspect-sha> -- app/ src/
La marca de tiempo eas update:list debe preceder al first seen de Sentry por minutos (propagación de OTA)
El % de rollout de tienda solo no explica el agrupamiento de dist solo OTA
// Estimación aproximada de impacto para IC / comms ejecutivotype ImpactEstimate = { crashFreeDelta: number; // p. ej. -0.026 (99.4% → 96.8%) sessionsLastHour: number; // de Release Health de Sentry dau: number; // de analytics};function estimateAffectedUsers(e: ImpactEstimate): number { const crashedSessions = e.sessionsLastHour * e.crashFreeDelta; // Escala a DAU si el pico es sostenido - conservador para comms ejecutivo return Math.round(Math.min(crashedSessions, e.dau * e.crashFreeDelta));}
Tamaño de cohorte de etiqueta otaUpdateId de Analytics
Línea de comms de ejemplo para IC:
~2.6% tasa de fallo de sesión en producción; el clúster principal afecta checkout en OTA abc123.iOS en fase al 25% (~40k usuarios). Contención: reversión de OTA en progreso.
Reportar menos es mejor que exagerar - da rangos ("decenas de miles") si analytics se retrasa
Los crashes de ruta de pago usan métricas de ingresos, no solo tasa sin fallos
Monitorea 60 minutos después de la contención - sin fallos debería recuperarse hacia la línea base. Si no, segundo clúster o capa incorrecta - re-bisecciona.
Issues - ordena por Eventos en ventana de tiempo - abre incidencia principal - comprueba First Seen, Releases y distribución de Dist. Usa consultas de Discover para agrupar por dist cuando la UI de Issues es ruidosa. Misma huella digital = mismo candidato de causa raíz.
La reversión de OTA no arregló los fallos - ¿y ahora?
Re-comprueba dist en eventos entrantes - si dist no cambió, los clientes aún no han recogido la reversión (espera o fuerza política de recarga). Si dist cambió pero los fallos persisten, sospecha capa nativa o segundo bug. Re-agrupa desde T+0.
¿Qué disparador de reversión debemos usar?
Umbrales móviles comunes: crash-free -2% absoluto, éxito de pago -1% absoluto, errores de auth +3% relativo. Define en SLOs for Mobile Apps y Rollback Runbook antes del lanzamiento.