Skip to main content
By default AppSignal gathers relevant data for errors and performance measurements to help you find the cause of the issue. Sometimes you need more information, app specific data or a custom request header your app uses. You can configure AppSignal to gather more, or less, information than it does by default by tagging your transactions and configuring the request headers, parameter filtering, etc. Ideally we receive as little metadata for samples as possible, and only data that is needed to debug an exception or performance issue.
📖 Read our filtering app data guide about limiting what (sensitive) data is collected by AppSignal. It will guide you through configuring which parameters, session data and request headers to collect.

​
Ignore actions

By configuring the ignore_actions option it’s possible to not record any data for the configured actions, requests, background jobs, etc.
📖 Read our guide about ignoring actions.

​
Ignore errors

By configuring the ignore_errors option it’s possible to ignore errors matching the exact name of an error for the entire app.
📖 Read our guide about ignoring errors.

​
Namespaces

Namespaces allow grouping of actions. By default AppSignal uses the “web”, “background” and “frontend” namespaces to group transactions. It’s possible to create a custom namespace such as “admin”, “api” to group controllers in the same namespace. The grouped actions in the namespace can be configured with their own notification defaults, allowing a critical namespace to always notify about errors, while the “web” namespace does not. It’s also possible to configure the AppSignal integration to ignore a namespace to ignore all transactional data from all actions in it.
Read more about namespaces in the namespaces section.

​
Tagging

Our tagging system allows you to attach more metadata to samples, besides what we already collect. Things such as the ID of the user making the request or other data that can help you identify who made the request or specific conditions for the request.

​
Queries

By default we parse SQL queries and try and remove any parameters in the query string. We’ve created an open-source (Rust) package that is used by our integrations. You can find the sql_lexer project on GitHub. If you see any query params in our UI, please open an issue in that repository. MongoDB queries in the Ruby integration are sanitized by default.