Triagem de Picos de Crash

Q: O rollback de OTA não corrigiu os crashes - e agora?

Verifique novamente o dist nos eventos recebidos - se o dist não mudou, os clientes ainda não pegaram o rollback (espere ou force a política de recarga). Se o dist mudou, mas os crashes persistem, suspeite da camada nativa ou de um segundo bug. Reagrupe a partir de T+0.

Um guia para agrupamento do Sentry, bissecção de releases e dimensionamento do impacto no usuário quando as sessões sem crash caem após um rollout da loja ou publicação OTA. Assume que a produção está configurada conforme Sentry para React Native e a identidade da release conforme Noções Básicas de Observabilidade.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# 1. Confirmar pico (UI ou API do Sentry)
#    Filtrar: environment=production, última 1h vs linha de base de 24h
 
# 2. Segmentar por release nativa
#    Agrupar por: release (ex: 2.4.0+240012)
 
# 3. Segmentar por dist OTA dentro da release principal
#    Agrupar por: dist (expo-updates updateId)
 
# 4. Abrir o cluster de problema principal - notar fingerprint + first seen
 
# 5. Correlacionar com a linha do tempo de deploy
eas update:list --branch production --limit 5
# App Store Connect: porcentagem de release faseada / Play: porcentagem de rollout escalonado
 
# 6. Conter (paralelo à triagem)
#    Pausar rollout / eas update:rollback / kill switch
 
# 7. Dimensionar impacto
#    delta de sessões sem crash × estimativa de DAU = usuários afetados

Quando usar isto:

Alerta do Sentry: sessões sem crash caíram >2% absoluto vs linha de base de 7 dias
Volume de tickets de suporte para "aplicativo fecha" correlaciona-se com a janela de alerta
Release Health mostra um novo fingerprint de problema com rampa acentuada de first seen

Quando escalar em vez de fazer bissecção:

Pico em todas as releases e IDs OTA simultaneamente → incidente de backend ou CDN
SIGABRT apenas nativo sem OTA novo → caminho de rollback do build da loja, não reversão do canal
Apenas pilhas não simbolizadas → corrija o upload do source map primeiro - veja Noções Básicas do EAS Build

Exemplo de Trabalho

Um exercício de triagem de 45 minutos para um pico de crash na produção após uma publicação OTA.

T+0 - Confirmar o pico é real (5 min)

Linha de base (7d):  99.4% sessões sem crash
Atual (1h):         96.8% sessões sem crash
Delta:              -2.6% absoluto  →  excede o gatilho de rollback

Filtros do Sentry Release Health:

Filtro	Valor
`environment`	`production`
`release`	`2.4.0+240012` (último build nativo ativo)
Intervalo de tempo	Última 1 hora vs 24 horas anteriores

Ignorar ambientes de desenvolvimento e pré-visualização nos numeradores de produção - veja SLOs para Aplicativos Móveis
Comparar sessões, não contagem bruta de eventos - um crash em loop gera centenas de eventos

T+5 - Agrupar problemas (10 min)

Abrir Issues ordenadas por volume de eventos na janela de alerta.

Cluster principal:
  Fingerprint: checkout-screen-null-ref
  First seen:  2026-07-09 14:02 UTC
  Events:      4.200 (82% do pico)
  Releases:    Apenas 2.4.0+240012
  Dist:        abc123-update-group (ID OTA único)

Padrões de consulta do Sentry:

is:unresolved release:2.4.0+240012 dist:abc123-update-group

Padrão do cluster	Interpretação
Um fingerprint, um `dist`	Pacote OTA ruim - reverter canal
Um fingerprint, todos os `dist` em uma `release`	Regressão nativa nesse binário
Muitos fingerprints, um `dist`	OTA ruim com múltiplos bugs - ainda assim reverter
Muitos fingerprints, todas as releases	Falha de backend, configuração ou SDK de terceiros

Breadcrumbs no evento principal: última rota de navegação, falhas de API, estado de flags
Se o fingerprint for NativeModule / SIGABRT, pule a bissecção OTA - abra a sala de guerra nativa

T+15 - Bissecção de releases (10 min)

Linha do tempo em um quadro branco ou documento de incidente:

| Hora UTC | Evento |
|----------|-------|
| 13:45 | Deploy de backend v892 - sem alteração móvel |
| 14:02 | eas update --channel production (grupo abc123) |
| 14:05 | Alerta Sentry disparado |
| 14:08 | iOS faseado em 25% - build 240012 |

Árvore de decisão de bissecção:

Crash apenas no dist abc123?
  SIM → Suspeita de OTA. eas update:view abc123. Rollback conforme OTA Emergency Rollback.
  NÃO  → Crash em todos os valores de dist para a release 2.4.0+240012?
          SIM → Suspeita de binário nativo. Pausar release faseada. Hotfix build.
          NÃO  → Crash em múltiplas releases nativas?
                  SIM → Backend / dependência compartilhada. Engajar plantão da API.

# Bissecção OTA
eas update:list --branch production --limit 5
eas update:view <suspect-group-id>
 
# Bissecção Git (após identificar SHA suspeito)
git log --oneline <last-good-sha>..<suspect-sha> -- app/ src/

O timestamp do eas update:list deve preceder o first seen do Sentry por minutos (propagação OTA)
A porcentagem de rollout da loja por si só não explica o agrupamento apenas OTA dist

T+25 - Dimensionar impacto no usuário (5 min)

// Estimativa de impacto aproximada para IC / comunicações executivas
type ImpactEstimate = {
  crashFreeDelta: number;      // ex: -0.026 (99.4% → 96.8%)
  sessionsLastHour: number;  // do Sentry Release Health
  dau: number;               // da análise
};
 
function estimateAffectedUsers(e: ImpactEstimate): number {
  const crashedSessions = e.sessionsLastHour * e.crashFreeDelta;
  // Escalar para DAU se o pico for sustentado - conservador para comunicações executivas
  return Math.round(Math.min(crashedSessions, e.dau * e.crashFreeDelta));
}

Entrada	Fonte
`crashFreeDelta`	Sentry Release Health
`sessionsLastHour`	Sentry Release Health
Porcentagem de rollout faseado	App Store Connect / Play Console - Phased Release & Rollback
Porcentagem de adoção OTA	Coorte de análise com tag `otaUpdateId`

Linha de comunicação de exemplo para IC:

Taxa de crash de ~2.6% na sessão em produção; cluster principal afeta checkout no OTA abc123.
iOS em 25% (~40k usuários). Contenção: rollback OTA em andamento.

Subestimar é melhor que exagerar - fornecer intervalos ("dezenas de milhares") se a análise estiver atrasada
Crashes na rota de pagamento usam métricas de receita, não apenas taxa de sessões sem crash

T+30 - Conter enquanto a triagem termina (paralelo)

Descoberta	Ação
`dist` OTA único ruim	OTA Emergency Rollback
Build nativo ruim	Pausar faseado / parar escalonado; desativar flag
Recurso isolado	Kill switch remoto primeiro
Correlação com backend	Chamar equipe de API; móvel segura rollouts

eas update:rollback
eas channel:view production

Monitorar 60 minutos pós-contenção - sessões sem crash devem se recuperar em direção à linha de base. Se não, segundo cluster ou camada errada - re-bissecção.

Configuração do Sentry para Triagem

Certifique-se de que estes estejam definidos na inicialização - caso contrário, a bissecção falhará silenciosamente:

// app/_layout.tsx
import * as Sentry from "@sentry/react-native";
import * as Application from "expo-application";
import * as Updates from "expo-updates";
 
Sentry.init({
  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,
  release: `${Application.nativeApplicationVersion}+${Application.nativeBuildVersion}`,
  dist: Updates.updateId ?? Application.nativeBuildVersion ?? "embedded",
  environment: process.env.EXPO_PUBLIC_APP_ENV,
  enableAutoSessionTracking: true,
});

Tag	Propósito na triagem
`release`	Bissecção do build nativo
`dist`	Bissecção do pacote OTA
`environment`	Excluir pré-visualização de alertas de produção
`transaction` / rota	Agrupamento em nível de tela

Carregue source maps em cada build de produção EAS - pilhas não simbolizadas bloqueiam a precisão do fingerprint
Marque coortes de Staged Rollouts durante publicações OTA percentuais

Erros Comuns de Triagem

Erro	Correção
Perseguir cada evento individualmente	Ordenar por fingerprint; os 3 principais clusters geralmente explicam >90%
Fazer rollback de OTA para SIGABRT nativo	Verificar a plataforma de problemas e a pilha - frames nativos pulam o rollback JS
Ignorar a porcentagem de rollout faseado	5% de rollout × alta taxa de crash ainda afeta a receita se for na finalização da compra
Sem tag `dist`	Configurar `Updates.updateId` antes do próximo incidente
Declarar vitória em 30 min	Monitorar Release Health por 60 min - adoção lenta de OTA mascara a recuperação

FAQs

Como agrupo no Sentry durante um incidente?

Issues → ordenar por Events na janela de tempo → abrir o problema principal → verificar a distribuição de First Seen, Releases e Dist. Use consultas do Discover para agrupar por dist quando a UI de Issues estiver barulhenta. Mesmo fingerprint = mesmo candidato a causa raiz.

O rollback de OTA não corrigiu os crashes - e agora?

Verifique novamente o dist nos eventos recebidos - se o dist não mudou, os clientes ainda não pegaram o rollback (espere ou force a política de recarga). Se o dist mudou, mas os crashes persistem, suspeite da camada nativa ou de um segundo bug. Reagrupe a partir de T+0.

Qual gatilho de rollback devemos usar?

Limiares móveis comuns: sessões sem crash -2% absoluto, sucesso de pagamento -1% absoluto, erros de autenticação +3% relativo. Defina em SLOs para Aplicativos Móveis e Rollback Runbook antes do lançamento.

Relacionados

Sentry para React Native - init, source maps, release health
Melhores Práticas de Observabilidade - marque cada sinal
OTA Emergency Rollback - reversão de canal sob pressão
Rollback Runbook - playbook completo de rollback OTA
Mobile Incident Basics - primeiros 15 minutos
Phased Release & Rollback - contenção de rollout da loja

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# 1. Confirmar pico (UI ou API do Sentry)
#    Filtrar: environment=production, última 1h vs linha de base de 24h
 
# 2. Segmentar por release nativa
#    Agrupar por: release (ex: 2.4.0+240012)
 
# 3. Segmentar por dist OTA dentro da release principal
#    Agrupar por: dist (expo-updates updateId)
 
# 4. Abrir o cluster de problema principal - notar fingerprint + first seen
 
# 5. Correlacionar com a linha do tempo de deploy
eas update:list --branch production --limit 5
# App Store Connect: porcentagem de release faseada / Play: porcentagem de rollout escalonado
 
# 6. Conter (paralelo à triagem)
#    Pausar rollout / eas update:rollback / kill switch
 
# 7. Dimensionar impacto
#    delta de sessões sem crash × estimativa de DAU = usuários afetados

Quando usar isto:

Alerta do Sentry: sessões sem crash caíram >2% absoluto vs linha de base de 7 dias
Volume de tickets de suporte para "aplicativo fecha" correlaciona-se com a janela de alerta
Release Health mostra um novo fingerprint de problema com rampa acentuada de first seen

Quando escalar em vez de fazer bissecção:

Pico em todas as releases e IDs OTA simultaneamente → incidente de backend ou CDN
SIGABRT apenas nativo sem OTA novo → caminho de rollback do build da loja, não reversão do canal
Apenas pilhas não simbolizadas → corrija o upload do source map primeiro - veja Noções Básicas do EAS Build

Exemplo de Trabalho

Um exercício de triagem de 45 minutos para um pico de crash na produção após uma publicação OTA.

T+0 - Confirmar o pico é real (5 min)

Linha de base (7d):  99.4% sessões sem crash
Atual (1h):         96.8% sessões sem crash
Delta:              -2.6% absoluto  →  excede o gatilho de rollback

Filtros do Sentry Release Health:

Filtro	Valor
`environment`	`production`
`release`	`2.4.0+240012` (último build nativo ativo)
Intervalo de tempo	Última 1 hora vs 24 horas anteriores

Ignorar ambientes de desenvolvimento e pré-visualização nos numeradores de produção - veja SLOs para Aplicativos Móveis
Comparar sessões, não contagem bruta de eventos - um crash em loop gera centenas de eventos

T+5 - Agrupar problemas (10 min)

Abrir Issues ordenadas por volume de eventos na janela de alerta.

Cluster principal:
  Fingerprint: checkout-screen-null-ref
  First seen:  2026-07-09 14:02 UTC
  Events:      4.200 (82% do pico)
  Releases:    Apenas 2.4.0+240012
  Dist:        abc123-update-group (ID OTA único)

Padrões de consulta do Sentry:

is:unresolved release:2.4.0+240012 dist:abc123-update-group

Padrão do cluster	Interpretação
Um fingerprint, um `dist`	Pacote OTA ruim - reverter canal
Um fingerprint, todos os `dist` em uma `release`	Regressão nativa nesse binário
Muitos fingerprints, um `dist`	OTA ruim com múltiplos bugs - ainda assim reverter
Muitos fingerprints, todas as releases	Falha de backend, configuração ou SDK de terceiros

Breadcrumbs no evento principal: última rota de navegação, falhas de API, estado de flags
Se o fingerprint for NativeModule / SIGABRT, pule a bissecção OTA - abra a sala de guerra nativa

T+15 - Bissecção de releases (10 min)

Linha do tempo em um quadro branco ou documento de incidente:

| Hora UTC | Evento |
|----------|-------|
| 13:45 | Deploy de backend v892 - sem alteração móvel |
| 14:02 | eas update --channel production (grupo abc123) |
| 14:05 | Alerta Sentry disparado |
| 14:08 | iOS faseado em 25% - build 240012 |

Árvore de decisão de bissecção:

Crash apenas no dist abc123?
  SIM → Suspeita de OTA. eas update:view abc123. Rollback conforme OTA Emergency Rollback.
  NÃO  → Crash em todos os valores de dist para a release 2.4.0+240012?
          SIM → Suspeita de binário nativo. Pausar release faseada. Hotfix build.
          NÃO  → Crash em múltiplas releases nativas?
                  SIM → Backend / dependência compartilhada. Engajar plantão da API.

# Bissecção OTA
eas update:list --branch production --limit 5
eas update:view <suspect-group-id>
 
# Bissecção Git (após identificar SHA suspeito)
git log --oneline <last-good-sha>..<suspect-sha> -- app/ src/

O timestamp do eas update:list deve preceder o first seen do Sentry por minutos (propagação OTA)
A porcentagem de rollout da loja por si só não explica o agrupamento apenas OTA dist

T+25 - Dimensionar impacto no usuário (5 min)

// Estimativa de impacto aproximada para IC / comunicações executivas
type ImpactEstimate = {
  crashFreeDelta: number;      // ex: -0.026 (99.4% → 96.8%)
  sessionsLastHour: number;  // do Sentry Release Health
  dau: number;               // da análise
};
 
function estimateAffectedUsers(e: ImpactEstimate): number {
  const crashedSessions = e.sessionsLastHour * e.crashFreeDelta;
  // Escalar para DAU se o pico for sustentado - conservador para comunicações executivas
  return Math.round(Math.min(crashedSessions, e.dau * e.crashFreeDelta));
}

Entrada	Fonte
`crashFreeDelta`	Sentry Release Health
`sessionsLastHour`	Sentry Release Health
Porcentagem de rollout faseado	App Store Connect / Play Console - Phased Release & Rollback
Porcentagem de adoção OTA	Coorte de análise com tag `otaUpdateId`

Linha de comunicação de exemplo para IC:

Taxa de crash de ~2.6% na sessão em produção; cluster principal afeta checkout no OTA abc123.
iOS em 25% (~40k usuários). Contenção: rollback OTA em andamento.

Subestimar é melhor que exagerar - fornecer intervalos ("dezenas de milhares") se a análise estiver atrasada
Crashes na rota de pagamento usam métricas de receita, não apenas taxa de sessões sem crash

T+30 - Conter enquanto a triagem termina (paralelo)

Descoberta	Ação
`dist` OTA único ruim	OTA Emergency Rollback
Build nativo ruim	Pausar faseado / parar escalonado; desativar flag
Recurso isolado	Kill switch remoto primeiro
Correlação com backend	Chamar equipe de API; móvel segura rollouts

eas update:rollback
eas channel:view production

Monitorar 60 minutos pós-contenção - sessões sem crash devem se recuperar em direção à linha de base. Se não, segundo cluster ou camada errada - re-bissecção.

Configuração do Sentry para Triagem

Certifique-se de que estes estejam definidos na inicialização - caso contrário, a bissecção falhará silenciosamente:

// app/_layout.tsx
import * as Sentry from "@sentry/react-native";
import * as Application from "expo-application";
import * as Updates from "expo-updates";
 
Sentry.init({
  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,
  release: `${Application.nativeApplicationVersion}+${Application.nativeBuildVersion}`,
  dist: Updates.updateId ?? Application.nativeBuildVersion ?? "embedded",
  environment: process.env.EXPO_PUBLIC_APP_ENV,
  enableAutoSessionTracking: true,
});

Tag	Propósito na triagem
`release`	Bissecção do build nativo
`dist`	Bissecção do pacote OTA
`environment`	Excluir pré-visualização de alertas de produção
`transaction` / rota	Agrupamento em nível de tela

Carregue source maps em cada build de produção EAS - pilhas não simbolizadas bloqueiam a precisão do fingerprint
Marque coortes de Staged Rollouts durante publicações OTA percentuais

Erros Comuns de Triagem

Erro	Correção
Perseguir cada evento individualmente	Ordenar por fingerprint; os 3 principais clusters geralmente explicam >90%
Fazer rollback de OTA para SIGABRT nativo	Verificar a plataforma de problemas e a pilha - frames nativos pulam o rollback JS
Ignorar a porcentagem de rollout faseado	5% de rollout × alta taxa de crash ainda afeta a receita se for na finalização da compra
Sem tag `dist`	Configurar `Updates.updateId` antes do próximo incidente
Declarar vitória em 30 min	Monitorar Release Health por 60 min - adoção lenta de OTA mascara a recuperação

FAQs

Como agrupo no Sentry durante um incidente?

O rollback de OTA não corrigiu os crashes - e agora?

Qual gatilho de rollback devemos usar?

Relacionados

Sentry para React Native - init, source maps, release health
Melhores Práticas de Observabilidade - marque cada sinal
OTA Emergency Rollback - reversão de canal sob pressão
Rollback Runbook - playbook completo de rollback OTA
Mobile Incident Basics - primeiros 15 minutos
Phased Release & Rollback - contenção de rollout da loja

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Triagem de Picos de Crash

Buscar na documentação

Triagem de Picos de Crash