---
title: "How to manage error reporting"
version: 5.2
locale: pt-br
source: https://docs.djangoproject.com/pt-br/5.2/howto/error-reporting/
canonical: https://djangodocs.dev/pt-br/5.2/howto/error-reporting/
---
# How to manage error reporting

Quando estiver rondando um site público você deve sempre desligar a definição [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) . Isso fará que seu servidor rode bem mais rápido, e também irá evitar que usuários maliciosos vejam detalhes da sua aplicação que podem ser revelados por erros em suas páginas.

However, running with [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) set to `False` means you’ll never see
errors generated by your site – everyone will instead see your public error
pages. You need to keep track of errors that occur in deployed sites, so Django
can be configured to create reports with details about those errors.

## Relatórios por email.

### Erros do servidor

Quando [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) é `False`, Django irá enviar um email aos usuários listados no [`ADMINS`](/pt-br/5.2/ref/settings/#std-setting-ADMINS) mesmo que seu código levante uma exceção e resulte em um erro interno ( falando estritamente, para qualquer response com um código de status de 500 ou maior). Isso dá ao administrador uma notificação imediata de quaisquer erros. Os [`ADMINS`](/pt-br/5.2/ref/settings/#std-setting-ADMINS) irão rceber uma descrição do erro, um Traceback completo do Python, e detalhes da requisição HTTP causada pelo erro.

> **Note**
>
> Para enviar o email, o Django requer algumas configurações dizendo a ele como se conectar ao seu servidor de email. No mínimo é necessário especificar [`EMAIL_HOST`](/pt-br/5.2/ref/settings/#std-setting-EMAIL_HOST) e possivelmente [`EMAIL_HOST_USER`](/pt-br/5.2/ref/settings/#std-setting-EMAIL_HOST_USER) e [`EMAIL_HOST_PASSWORD`](/pt-br/5.2/ref/settings/#std-setting-EMAIL_HOST_PASSWORD), embora outras configurações tambem sejam requeridas dependendo da configuração do seu servidor de email. Consulte o [Documentação de configurações do Django](/pt-br/5.2/ref/settings/) para uma lista completa de configurações relacionadas a email.

Por padrão, o Django envia email do [root@localhost](mailto:root@localhost). Contudo, alguns provedores de email rejeitam todos os email deste endereço. Para usar um endereço de remetente diferente, modifique a configuração [`SERVER_EMAIL`](/pt-br/5.2/ref/settings/#std-setting-SERVER_EMAIL)

Para ativar este comportamento, coloque o endereço de email dos destinatários na definição do [`ADMINS`](/pt-br/5.2/ref/settings/#std-setting-ADMINS)

> **See also**
>
> Emails de erros de servidores são enviados usando o framework de log, e você pode customizár seu comportamento por [customizando sua configuração de log](/pt-br/5.2/topics/logging/).

### Erros 404

O Django pode ser configurado para enviar emails com erros sobre links quebrados (erros 404 “página não encontrada”). O Django envia emails com erros 404 quando:

- [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) é `False`;
- Sua definição de [`MIDDLEWARE`](/pt-br/5.2/ref/settings/#std-setting-MIDDLEWARE) inclue [`django.middleware.common.BrokenLinkEmailsMiddleware`](/pt-br/5.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware).

If those conditions are met, Django will email the users listed in the
[`MANAGERS`](/pt-br/5.2/ref/settings/#std-setting-MANAGERS) setting whenever your code raises a 404 and the request has
a referer. It doesn’t bother to email for 404s that don’t have a referer –
those are usually people typing in broken URLs or broken web bots. It also
ignores 404s when the referer is equal to the requested URL, since this
behavior is from broken web bots too.

> **Note**
>
> [`BrokenLinkEmailsMiddleware`](/pt-br/5.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) must appear
> before other middleware that intercepts 404 errors, such as
> [`LocaleMiddleware`](/pt-br/5.2/ref/middleware/#django.middleware.locale.LocaleMiddleware) or
> [`FlatpageFallbackMiddleware`](/pt-br/5.2/ref/contrib/flatpages/#django.contrib.flatpages.middleware.FlatpageFallbackMiddleware).
> Put it toward the top of your [`MIDDLEWARE`](/pt-br/5.2/ref/settings/#std-setting-MIDDLEWARE) setting.

Você pode dizer ao Django para parar de reportar 404s ajustando a definição do [`IGNORABLE_404_URLS`](/pt-br/5.2/ref/settings/#std-setting-IGNORABLE_404_URLS). Isso deve ser uma lista de objetos compilados de expressões regulares. Por exeplo:

```
import re

IGNORABLE_404_URLS = [
    re.compile(r"\.(php|cgi)$"),
    re.compile(r"^/phpmyadmin/"),
]
```

Neste exemplo, um 404 para qualquer URL com ```.php``ou ``.cgi``` *não* será reportado. Nem nenhuma URL começando com `/phpadmin/`.

O exemplo seguinte mostra como excluir algumas URLs convencionais que “borwsers” e “crawlers” requisitam com frequência.

```
import re

IGNORABLE_404_URLS = [
    re.compile(r"^/apple-touch-icon.*\.png$"),
    re.compile(r"^/favicon\.ico$"),
    re.compile(r"^/robots\.txt$"),
]
```

(repare que essas são expressões regulares, então coloca-se uma barra invertida na frente dos pontos para que não sejam substituidos.)

Se quer personalizar o comportamentdo do [`django.middleware.common.BrokenLinkEmailsMiddleware`](/pt-br/5.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) mais adiante (por exemplo para ignorar requisições vindas de rastreadores web), você deve criar uma subclasse e sobrescreva seus métodos.

> **See also**
>
> Erros 404 são logados usando o framework logging. Por padrão, estes registros de log são ignorados, mas você pode usá-los para relatório de erros sobrescrevendo o “handlers” e o [configuring logging](/pt-br/5.2/topics/logging/) apropriadamente.

## Filtrando relatórios de erros

> **Warning**
>
> Filtering sensitive data is a hard problem, and it’s nearly impossible to
> guarantee that sensitive data won’t leak into an error report. Therefore,
> error reports should only be available to trusted team members and you
> should avoid transmitting error reports unencrypted over the internet
> (such as through email).

### Filtrando Informações sensíveis

Relatórios de erros são de grande ajuda para detectar falhas, sempre é util registrar o máximo de informação sobre falhas quanto possível. Por exemplo, por padrão o Django registra

Algumas vezes certos tipos de informação talvez sejam muito sensíveis e talvez não seja apropriado manter rastros, por exemplo uma senha de usuário ou número do cartão de crédito. Então para filtrar definições que aparentam ser sensíveis como descrito na documentação do [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG), o Django oferece um conjunto de decoradores de função para auxiliar no controle de qual informação deve ser filtrada para fora dos relatórios de erro em um ambiente de produção (isto é, onde [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) é definido como `False`): [`sensitive_variables()`](#django.views.decorators.debug.sensitive_variables) e [`sensitive_post_parameters()`](#django.views.decorators.debug.sensitive_post_parameters).

#### `sensitive_variables(*variables)`

Se uma função (uma view ou callback) no seu código usa variavéis locais que venham guardar informação sigilosa, voce deve reguasdar o valor dessas variavéis de serem expostas nos relatórios de erros usando o decorator ‘’sensitive\_variables’’

```
from django.views.decorators.debug import sensitive_variables

@sensitive_variables("user", "pw", "cc")
def process_info(user):
    pw = user.pass_word
    cc = user.credit_card_number
    name = user.name
    ...
```

In the above example, the values for the `user`, `pw` and `cc`
variables will be hidden and replaced with stars (`**********`)
in the error reports, whereas the value of the `name` variable will be
disclosed.

Para esconder sistematicamente todas as variáveis locais de uma fução dos logs de erros, não forneça argumento ao decorador `sensitive_variables`:

```
@sensitive_variables()
def my_function(): ...
```

> **Quando usar multiplos decorators**
>
> Se a variável que você quer esconder é também um argumento da função (ex.: `user` no exemplo a seguir), e si a função “decorada” tem múltimplos “decorators”,  então tenha certeza de posiionar o `@sensitive_variables`  no topo da lista de “decorators”. Desta maneira, serão escondidos também  o argumento da função enquanto passa pelos outros “decorators”:
>
> ```
> @sensitive_variables("user", "pw", "cc")
> @some_decorator
> @another_decorator
> def process_info(user): ...
> ```

#### `sensitive_post_parameters(*parameters)`

Se uma de suas “views” recebe um objeto [`HttpRequest`](/pt-br/5.2/ref/request-response/#django.http.HttpRequest) com [`parâmetros do POST`](/pt-br/5.2/ref/request-response/#django.http.HttpRequest.POST) suscetível a conter informação sensível, é possível  evitar que os valores destes parâmetros sejam incluídos no relatório de erros usando o “decorator” `sensitive_post_parameters`

```
from django.views.decorators.debug import sensitive_post_parameters

@sensitive_post_parameters("pass_word", "credit_card_number")
def record_user_profile(request):
    UserProfile.create(
        user=request.user,
        password=request.POST["pass_word"],
        credit_card=request.POST["credit_card_number"],
        name=request.POST["name"],
    )
    ...
```

In the above example, the values for the `pass_word` and
`credit_card_number` POST parameters will be hidden and replaced with
stars (`**********`) in the request’s representation inside the
error reports, whereas the value of the `name` parameter will be
disclosed.

Para esconder sistematicamente todos os parâmetros do POST de uma requisição em um relatório de erro relatório, não forneça nenhum arguento para o “decorator”  `sensitive_post_parameters`:

```
@sensitive_post_parameters()
def my_view(request): ...
```

Todos os parâmentros do POST são sistematicamente filtrados do relatório para certas “views”   [`django.contrib.auth.views`](/pt-br/5.2/topics/auth/default/#module-django.contrib.auth.views)  (`login`, `password_reset_confirm`, `password_change`, e `add_view` e `user_change_password` no `auth` admin) para prevenir o vazamento de informação sensível tal como as senhas de usuários.

### Relatórios de erros personalizados

All [`sensitive_variables()`](#django.views.decorators.debug.sensitive_variables) and [`sensitive_post_parameters()`](#django.views.decorators.debug.sensitive_post_parameters) do is,
respectively, annotate the decorated function with the names of sensitive
variables and annotate the `HttpRequest` object with the names of sensitive
POST parameters, so that this sensitive information can later be filtered out
of reports when an error occurs. The actual filtering is done by Django’s
default error reporter filter:
[`django.views.debug.SafeExceptionReporterFilter`](#django.views.debug.SafeExceptionReporterFilter). This filter uses the
decorators’ annotations to replace the corresponding values with stars
(`**********`) when the error reports are produced. If you wish to
override or customize this default behavior for your entire site, you need to
define your own filter class and tell Django to use it via the
[`DEFAULT_EXCEPTION_REPORTER_FILTER`](/pt-br/5.2/ref/settings/#std-setting-DEFAULT_EXCEPTION_REPORTER_FILTER) setting:

```
DEFAULT_EXCEPTION_REPORTER_FILTER = "path.to.your.CustomExceptionReporterFilter"
```

Você pode controlar de uma maneira mais granular qual filtro usar dentro de qualquer “view” configurando o atributo `exception_reporter_filter` do `HttpRequest`:

```
def my_view(request):
    if request.user.is_authenticated:
        request.exception_reporter_filter = CustomExceptionReporterFilter()
    ...
```

Your custom filter class needs to inherit from
[`django.views.debug.SafeExceptionReporterFilter`](#django.views.debug.SafeExceptionReporterFilter) and may override the
following attributes and methods:

#### `class SafeExceptionReporterFilter`

#### `cleansed_substitute`

The string value to replace sensitive value with. By default it
replaces the values of sensitive variables with stars
(`**********`).

#### `hidden_settings`

A compiled regular expression object used to match settings and
`request.META` values considered as sensitive. By default equivalent
to:

```
import re

re.compile(r"API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)
```

> **Changed in Django 5.2**
>
> The term `AUTH` was added.

#### `is_active(request)`

Returns `True` to activate the filtering in
[`get_post_parameters()`](#django.views.debug.SafeExceptionReporterFilter.get_post_parameters) and [`get_traceback_frame_variables()`](#django.views.debug.SafeExceptionReporterFilter.get_traceback_frame_variables).
By default the filter is active if [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) is `False`. Note
that sensitive `request.META` values are always filtered along with
sensitive setting values, as described in the [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG)
documentation.

#### `get_post_parameters(request)`

Returns the filtered dictionary of POST parameters. Sensitive values
are replaced with [`cleansed_substitute`](#django.views.debug.SafeExceptionReporterFilter.cleansed_substitute).

#### `get_traceback_frame_variables(request, tb_frame)`

Returns the filtered dictionary of local variables for the given
traceback frame. Sensitive values are replaced with
[`cleansed_substitute`](#django.views.debug.SafeExceptionReporterFilter.cleansed_substitute).

If you need to customize error reports beyond filtering you may specify a
custom error reporter class by defining the
[`DEFAULT_EXCEPTION_REPORTER`](/pt-br/5.2/ref/settings/#std-setting-DEFAULT_EXCEPTION_REPORTER) setting:

```
DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"
```

The exception reporter is responsible for compiling the exception report data,
and formatting it as text or HTML appropriately. (The exception reporter uses
[`DEFAULT_EXCEPTION_REPORTER_FILTER`](/pt-br/5.2/ref/settings/#std-setting-DEFAULT_EXCEPTION_REPORTER_FILTER) when preparing the exception
report data.)

Your custom reporter class needs to inherit from
[`django.views.debug.ExceptionReporter`](#django.views.debug.ExceptionReporter).

#### `class ExceptionReporter`

#### `html_template_path`

Property that returns a [`pathlib.Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path) representing the absolute
filesystem path to a template for rendering the HTML representation of
the exception. Defaults to the Django provided template.

#### `text_template_path`

Property that returns a [`pathlib.Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path) representing the absolute
filesystem path to a template for rendering the plain-text
representation of the exception. Defaults to the Django provided
template.

#### `get_traceback_data()`

Return a dictionary containing traceback information.

This is the main extension point for customizing exception reports, for
example:

```
from django.views.debug import ExceptionReporter

class CustomExceptionReporter(ExceptionReporter):
    def get_traceback_data(self):
        data = super().get_traceback_data()
        # ... remove/add something here ...
        return data
```

#### `get_traceback_html()`

Return HTML version of exception report.

Used for HTML version of debug 500 HTTP error page.

#### `get_traceback_text()`

Return plain text version of exception report.

Used for plain text version of debug 500 HTTP error page and email
reports.

As with the filter class, you may control which exception reporter class to use
within any given view by setting the `HttpRequest`’s
`exception_reporter_class` attribute:

```
def my_view(request):
    if request.user.is_authenticated:
        request.exception_reporter_class = CustomExceptionReporter()
    ...
```

> **See also**
>
> Você pode também configurar um relatório de erro personalizado escrevendo um pedaço personalizado [middleware de exceção](/pt-br/5.2/topics/http/middleware/#exception-middleware). Se escrever um tratamento de erros personalizado, é uma boa idéia emular o tratamento de erro do Django e somente reportar/logar erros se [`DEBUG`](/pt-br/5.2/ref/settings/#std-setting-DEBUG) é `False`.