> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Erros de front-end no AppSignal

> Como erros de front-end são agrupados em issues e o que a visualização Errors mostra.

<Note>
  Browser monitoring é uma funcionalidade em beta do [AppSignal Labs](/labs). O
  pacote `@appsignal/browser` é publicado sob a tag `beta` no npm, e sua
  configuração e API ainda podem mudar entre releases beta. Compartilhe seu
  feedback na nossa [comunidade no Discord](https://discord.gg/EjF6ykYx63).
</Note>

A visualização Errors lista os erros que seu front end relatou, agrupados em issues. É o mesmo modelo de issues que seus erros de back-end usam, então tudo o que você já faz com uma exceção de Ruby ou Node.js funciona aqui também.

<h2 id="how-errors-are-grouped">
  Como os erros são agrupados
</h2>

Ocorrências do mesmo tipo de erro na mesma rota se tornam uma issue. Um bug que dispara dez mil vezes é uma coisa para triar, em vez de dez mil notificações.

A rota é aquela que o SDK relatou por meio de [`setRouteTemplate()`](/browser/installation#report-the-current-route), ou o caminho da página quando nada foi declarado. É por isso que declarar templates importa: sem eles, `/orders/1` e `/orders/2` são rotas diferentes, e um bug se fragmenta em uma issue por pedido.

<h2 id="reading-the-issue-list">
  Lendo a lista de issues
</h2>

Cada issue na lista traz:

* A classe do erro e a mensagem, com a rota em que aconteceu.
* A versão em que foi **introduzido**, que muitas vezes é a forma mais rápida de identificar uma regressão: uma issue nova no seu release mais recente é um release que você provavelmente quer examinar.
* Uma **tendência** para o período selecionado, para que um pico se leia de forma diferente de um fluxo constante.
* O número **total** de ocorrências no período.
* Quando foi visto pela **última** vez.
* Para quem está **atribuído**.

Você pode ordenar pela ocorrência mais recente ou por volume, dependendo se está triando o que acabou de quebrar ou o que quebra mais.

<h2 id="filtering-by-time-and-version">
  Filtrando por tempo e versão
</h2>

* **Intervalo de tempo.** Predefinições de uma hora a 30 dias, ou um intervalo personalizado.
* **Versão.** Restrinja a lista aos erros relatados por um único release. Combinado com a coluna de introdução, é assim que você confirma se um deploy é o responsável.

<h2 id="investigating-an-issue">
  Investigando uma issue
</h2>

Abrir uma issue mostra um sample do erro: quando aconteceu, a página em que aconteceu e o deploy em que apareceu primeiro, junto com quatro coisas a partir das quais você depura.

* **A mensagem de erro**, completa. É aí que está o significado. `TypeError` quase nada diz por si só, enquanto `Failed to fetch dynamically imported module` informa que um chunk carregado sob demanda nunca chegou.
* **As tags** que você definiu com [`setTags()`](/browser/error-tracking#tags), exibidas ao lado do user agent e da revisão, se você definiu [`appVersion`](/browser/configuration#appversion). Alguns nomes de tag fazem mais do que filtrar. Marque com `country_code` ou `browser` e você obtém [distribuições de atributos](/guides/tagging/attribute-distributions), que mostram quais países ou navegadores veem mais erros. [Templates de link](/application/link-templates) transformam uma tag em link, de modo que uma tag `user_id` pode abrir aquele usuário no seu próprio painel administrativo.
* **O backtrace**, que você pode ler completo ou restrito à sua própria aplicação. Stacks de front-end são muitas vezes quase inteiramente frames de framework. Uma falha de `removeChild` vinda do React chega como uma parede de frames `react-dom` sem nada seu à vista, e a visualização da aplicação é o que corta esse ruído.
* **A [linha do tempo de breadcrumbs](/browser/breadcrumbs)** que levou ao erro, que geralmente é a parte que te salva.

Cada breadcrumb carrega seus próprios detalhes. Uma entrada de rede mostra o método, a URL, o status da resposta e quanto tempo a requisição levou. Uma entrada de seleção mostra qual elemento o usuário selecionou. Uma entrada de long task nomeia o script que bloqueou a thread principal, e por quanto tempo. Um rastro que vai de uma seleção, passando por uma requisição GraphQL que levou quase três segundos, até o próprio erro é muitas vezes a explicação inteira, sem reproduzir nada.

Backtraces de um bundle minificado são resolvidos por meio de [sourcemaps](/browser/error-tracking#sourcemaps), correspondidos pela versão da aplicação. Sem uma versão definida, os backtraces permanecem minificados.

Um sample pode ser exportado como JSON ou Markdown, que é a maneira mais rápida de anexá-lo a um ticket ou entregá-lo a um assistente. Cada issue também tem um registro, onde você e seu time deixam notas em Markdown sobre o que encontraram.

<h2 id="triage-and-notifications">
  Triagem e notificações
</h2>

Issues podem ser atribuídas, receber um estado, ser silenciadas e configuradas com suas próprias configurações de notificação, e o restante das ferramentas de incidentes do AppSignal também funciona com elas. Leia mais em [Errors](/errors). Como erros de front-end ficam no namespace `browser` (veja [namespaces](/guides/namespaces)), essas configurações são separadas das do seu back end. Se você está migrando do `@appsignal/javascript`, note que os erros dele eram relatados em `frontend`, então as configurações de notificação que você fez lá não são transferidas. Leia mais no [guia de migração](/browser/migration).

<h2 id="errors-you-will-not-find-here">
  Erros que você não vai encontrar aqui
</h2>

Alguns erros nunca chegam ao SDK, incluindo os lançados antes da inicialização dele, os de scripts cross-origin servidos sem cabeçalhos CORS e os dentro de iframes. Cada um tem uma solução alternativa, listada em [erros que não são relatados](/browser/error-tracking#errors-that-are-not-reported). Se um erro que você esperava está faltando, percorra a [solução de problemas](/browser/troubleshooting#an-error-is-missing).