Skip to main content
There’s no such thing as a stupid question. On this page, you’ll find the answers to the ones we’re asked most frequently. If you need further support, please check out our support page

Contents

Getting Started

I Need Help Getting Started. Where Do I Begin?

If you’re new to AppSignal or want to know more about configuring AppSignal features, please read our guides

AppSignal Libraries

What Programming Languages Does AppSignal Support?

AppSignal supports the Node.js, Ruby and Elixir programming languages. We also have JavaScript packages for catching client-side errors in supported browsers.

Filtering Data

How Do I Ignore Actions in My Application?

You can Ignore Actions to stop recording data for specific actions, requests, background jobs, etc.

How Do I Ignore Errors in My Application?

You can Ignore Errors (based on their name) to prevent AppSignal from reporting and alerting you to them.

How do I Filter Data That’s Sent to AppSignal?

To learn how to filter the data that is sent to AppSignal, read one of the following guides:

What Regex Syntax Does ignore_logs Support?

ignore_logs supports a limited subset of regular expression syntax: ^ (start of string), $ (end of string), and .* (wildcard). Full regex constructs such as character classes ([.]) are not valid and are silently ignored. To match an exact log line, anchor it with both ^ and $. To match a prefix, use ^ followed by the literal text. To match anywhere in the message, use .* around it. See the ignore logs guide for the full syntax reference.

Why Do Uptime Monitor Requests Count Toward My Budget, and How Do I Exclude Them?

Uptime monitors poll your endpoint on a regular schedule, and if AppSignal is installed, those requests count as transactions toward your monthly request budget. To stop them from counting, add the health-check action to ignore_actions in your AppSignal configuration — AppSignal then stops recording those transactions entirely. For Ruby:
For Node.js:
For Python (Django or other frameworks), set ignore_actions in appsignal.py:
To find the exact action name, open Performance → Traces and copy it from the Action name column. See the ignore actions guide for the full configuration reference.

How Do I Ignore a Specific Error Message in the JavaScript Front End?

To ignore errors that match a specific message pattern in the AppSignal JavaScript integration, pass an ignoreErrors array when you initialize Appsignal. Each item in the array is a regular expression matched against the error message.
Errors whose messages match any pattern in ignoreErrors are not sent to AppSignal. Other errors of the same class continue to be reported. See the front-end configuration options for the full list of initialization options.

How Do I Suppress Logs Sent by appsignal-wrap?

appsignal-wrap forwards stdout and stderr to AppSignal by default. The ignore_logs configuration option does not apply to appsignal-wrap. To suppress output, pass --no-stdout and/or --no-stderr to the appsignal-wrap command:
These are CLI-only flags and cannot be set via environment variables. See the appsignal-wrap docs for the full list of options.

How Do I Route AppSignal Agent Traffic Through an HTTP Proxy?

Set the http_proxy configuration option (or APPSIGNAL_HTTP_PROXY environment variable) to the full address of your proxy. The AppSignal agent routes all outbound traffic — transactions, errors, metrics, and logs — through that proxy. For Ruby:
Or as an environment variable:
For Node.js, set httpProxy in your configuration:
The option is available for Ruby, Elixir, Node.js, and Python integrations. Your proxy must be able to make outbound connections to AppSignal endpoints for data to be forwarded. See the Ruby configuration options and Elixir configuration options for the full reference.

How do I Add Additional Instrumentation to My Application?

Additional instrumentation can be added to your application to give you more insights into how your application is performing by measuring the duration of separate events. Lean how in the documentation for our Ruby Gem and Elixir Package.

What Is the Difference Between setRootName and setName?

setName and setRootName both rename spans, but at different levels. setName sets the name of an individual span as it appears in the performance trace timeline, while setRootName sets the name of the root transaction — what you see in the performance overview and transaction list. A good pattern is to call setRootName once on your outermost handler (for example, `${request.method} ${pattern}` to produce a title like GET /users/:id), and use setName together with setCategory on inner spans such as middleware, loaders, and actions, so they appear as clearly labeled events in the timeline breakdown. For more on naming and adding spans, see the Node.js instrumentation guide.

How Do I Run Multiple Applications on One Host?

By default AppSignal is configured to assume one application runs on one host. If you run more than one application on a host, some unexpected behavior may occur, such as data being reported for a different application. To configure AppSignal for multiple applications on one host the AppSignal Working Directory needs to be configured. Read more about how to configure the working directory in our Guide to Running Multiple Application on One Host

What Operating Systems Does AppSignal Support?

Please read our Operating Systems page for the full list of supported Operating Systems and any required packages.

How Do I Debug an Issue with the AppSignal Integration?

Please read our Debugging Guide for a complete guide to AppSignal Integration debugging issues. You can also check our Known Issues page for issues that may be present in your version of the AppSignal Integration.

Does AppSignal Support Windows?

AppSignal does not support Windows, and there are no plans to add Windows support. However, we do try to make the AppSignal libraries installable on Microsoft Windows without any errors or build issues.

Why Does Installing the AppSignal Ruby Gem Fail With a JSON::Fragment Error?

This error occurs when installing appsignal 4.x with Ruby 3.0 and earlier. The json gem bundled as a dependency in AppSignal 4.x introduced JSON::Fragment, a constant only available on Ruby 3.1 and later. On older Ruby versions the native extension build fails with:
The recommended fix is to upgrade Ruby to 3.1 or later, which lets you use the current AppSignal 4.x release without restrictions. If you cannot upgrade Ruby right away, you can pin to AppSignal 3.x as a temporary workaround: add gem "appsignal", "~> 3.0" to your Gemfile and run bundle update appsignal. AppSignal 3.x works with Ruby 2.7 and Ruby 3.0, but does not receive new features from the 4.x line, so plan to upgrade Ruby when you can.

How Do I Configure AppSignal in a Hanami Application?

AppSignal does not auto-configure in Hanami the way it does in Rails. Use a Ruby configuration file (config/appsignal.rb) rather than the legacy YAML file (config/appsignal.yml) — the YAML format is deprecated and will be removed in the next major version of the gem. Create config/appsignal.rb with:
Then make sure config.ru loads the integration after Hanami:
If you have an existing config/appsignal.yml, remove it or add a development section with active: true — having both files causes conflicts. AppSignal does not start in the development environment by default; activate_if_environment opts it in explicitly. See the Hanami integration docs for the full setup.

Why Are Errors in Phoenix LiveComponent Not Captured by AppSignal?

AppSignal captures Phoenix errors by listening to Phoenix telemetry events. When a LiveComponent handles form events directly, Phoenix uses an internal path that does not emit those telemetry events, so the error is never reported. To report errors from LiveComponent, use Appsignal.send_error/2 to send them manually:
Alternatively, move logic that may raise out of the component’s template and into its handle_event/3 or update/2 callbacks, where Phoenix telemetry does fire. This gap was fixed upstream in phoenix_live_view. Updating to the latest release allows AppSignal to capture these errors automatically.

Where Is the Check-ins Feature?

Check-ins have been renamed to Process Monitoring. The feature works the same way — it provides visibility into background processes such as cron jobs. Find it in the left navigation sidebar under Process Monitoring. See the Process Monitoring docs for setup and configuration.

How Do I Differentiate Hosts by Role or Override Their Names in AppSignal?

Two environment variables control how AppSignal identifies hosts:
  • APPSIGNAL_HOSTNAME overrides the hostname AppSignal reports. Set it to a human-readable value such as sidekiq-1 or web-worker instead of an auto-generated container ID.
  • APPSIGNAL_HOST_ROLE tags the host by its role (for example, web or processor). AppSignal uses this tag to group hosts by role and to generate role-specific metrics such as the reporting_hosts counter.
See the Elixir configuration options and Ruby configuration options for the full reference.

Does AppSignal Support Probabilistic Request Sampling?

No. AppSignal does not support probabilistic (percentage-based) sampling of requests. The integration collects data from every request so that features such as anomaly detection remain accurate. To reduce the volume of data you send, you can exclude specific actions or namespaces that provide little monitoring value using ignore_actions or ignore_namespaces. See the limiting requests guide for the available options.

User Account

Can I Send Email Notifications to a Specific Team Member?

Email notifications cannot be sent to a specific team member. Each member controls their own notification preferences. To update them, go to Account Settings → Email Settings and toggle notifications on or off for each app. See notification settings for the available options.

How Do I Enable Two-Factor Authentication (2FA) For the AppSignal App?

Please refer to our Two-Factor Authentication page for more information on enabling 2FA.

Why Aren’t My Two-Factor Authentication (2FA) Codes Working?

If your authenticator app’s codes are rejected when you log in, the most common cause is clock drift on the device generating them. Two-factor authentication codes are time-based (TOTP), so that device’s clock must be accurate — this often breaks after changing time zones. Enable automatic (network) date and time on the device, then try the newly generated code. If you still can’t log in, use one of the five recovery codes you saved when you enabled 2FA to bypass two-factor authentication. See Two-Factor Authentication for more on recovery codes.

How Do I Re-Enroll My Two-Factor Authentication Device?

To set up 2FA on a new authenticator app or device, go to Account Settings → Security → Two-factor authentication, disable 2FA, then re-enable it. A new QR code appears for you to scan with your authenticator app. To reach the disable option, you first need to authenticate with a current code or a recovery code. See Two-Factor Authentication for full setup instructions.

Does the AppSignal JavaScript Front-End Integration Store IP Addresses or User Agents?

AppSignal uses the visitor’s IP address only to determine their country and then discards it — IP addresses are not stored. The user agent is always collected for front-end errors and cannot be disabled at the app level. No breadcrumbs are collected by default. To add them, use the addBreadcrumb method or the breadcrumb plugin. To scrub other user data from spans before they leave the browser, use the front-end hook overrides. Retention periods depend on your plan: 5 days (Free), 30 days (250 k–10 M requests), 45 days (25 M), and 60 days (50 M and above). AppSignal processes and stores all data exclusively within EU-based infrastructure (Worldstream in the Netherlands, AWS EMEA in Ireland, and Hetzner in Germany). No customer data is transferred to or processed in the United States. See the privacy documentation for the full data-handling reference.

What IP Addresses does AppSignal Use?

Currently the AppSignal Push API uses the following IP addresses:
Currently the AppSignal webhooks orginate from the following IP addresses:
We don’t recommend allowlisting specific IP addresses. They might change, and more may be added in the future, for instance, when we need to cycle our load balancers or quickly add servers. If you decide to allowlist our IP addresses, please send our support team an email, we’ll do our best to notify you if there are upcoming changes.

Errors & Performance

How Do I See Error Counts Per Namespace?

To see error counts per namespace, create a Number chart that uses the error_count metric (AppSignal’s count of errors recorded in an application), filtered by the namespace tag:
  1. Open the application you want to measure, go to Dashboards, and add a new chart.
  2. Select the Number tab.
  3. Set the metric to error_count.
  4. Add the namespace tag and enter the namespace name (for example, web or background).
  5. Set the aggregation type to Total value.
  6. Create the chart.
The chart shows the total error count for that namespace over the time frame you select when viewing it. AppSignal stores error data separately per application, so there is no single total across all applications — create one chart per namespace per application, and add the counts together yourself if you need an overall figure.

How Long Is Uptime Monitoring Data Retained?

Uptime monitoring stores minutely metrics for 30 days and hourly metrics for 5 years. To view daily uptime trends over a longer period — for example, a full year — use the date picker in the uptime monitoring view to select a custom date range.

How Do I Find the Cause of Slow API Requests?

Start in Performance → Slow API requests. Requests are sorted by impact — the combination of duration and frequency — so the top entries are the most likely culprits. Selecting a request shows its mean duration, response time graph, throughput, and the list of actions that contain it. For database queries, check Performance → Slow queries. Each query is sorted by impact, and selecting one shows which actions trigger it. To find N+1 queries, open Performance → Traces. Actions flagged with the N+1 tag contain repeated database calls. Open a trace and view the performance timeline — events marked x2, x5, and so on indicate the same query repeated within a single request. For a guided walkthrough, see Find slow database queries and Find slow HTTP requests.

How Do I Change the Front-End Error Grouping Strategy?

By default, AppSignal groups front-end errors by error name. When multiple uncaught errors share a generic name, they collapse into a single issue even if their messages and stack traces differ. To split over-grouped front-end errors by where they originate in your code, go to your application’s Settings page and set Front-end error grouping strategy to Relevant backtrace line strategy. This groups errors by the first line of your own code in the backtrace instead of by the error name. For this to work, upload source maps for your application — without them AppSignal cannot resolve the backtrace to your source files. See Front-end source maps for how to set them up. You need owner access on the organization to change this setting. If the option is not visible, ask an owner to make the change.

How Do I Search for Errors by Message?

To search for errors by their message text, use the message: tag in the AppSignal search bar. For example, entering message:"could not connect" returns all error traces where the error message contains that phrase. The search bar appears in the AppSignal dashboard header.

How Do I Receive Anomaly Notifications via Webhook?

Anomaly notifications via webhook are configured on the anomaly trigger, not on the webhook settings screen. Create or edit an anomaly trigger, scroll to Notify me through, and select the webhook you have set up in AppSignal. The webhook settings screen lists only Deploys, Errors, and Performance events — the anomaly connection lives on the trigger itself. See Anomaly detection triggers for how to set up and edit triggers.

Why Does My Elixir App Show a Sudden Spike in Request Usage?

A sudden spike in request usage after a deployment is often caused by a large number of errors generated by your application. Errors count as requests in AppSignal. If the error throughput shown in your dashboard appears much lower than the request count increase, you may be running an older version of the AppSignal Elixir integration. In older versions, only sampled errors appear in the error throughput metrics, but all error requests count toward your total request usage. This mismatch makes the spike look larger than the error count suggests. To resolve the discrepancy, upgrade the appsignal Elixir package to the latest version. After upgrading, error throughput metrics reflect the full count, matching what AppSignal records for billing. To find the errors causing the spike, go to Errors and filter by the deployment date. See the Elixir installation guide for upgrade instructions.

Why Are My Custom Metrics Being Dropped?

AppSignal enforces a hard limit on the number of unique metric tag combinations it stores per minute. When your application exceeds this limit, some metrics are dropped based on AppSignal’s prioritization logic. The most common cause is using high-cardinality values as metric tags — for example, user IDs, order IDs, or request IDs. Each unique tag value creates a distinct metric series, and a large number of users or orders can exhaust the per-minute limit very quickly. To avoid dropped metrics, keep tags low-cardinality: use values from a small, fixed set such as plan tier, region, or environment. High-cardinality per-entity data (for example, tracking a metric per user) is not suited to AppSignal’s metric tagging system. The UI also becomes unusable trying to render thousands of lines on a single chart. See the custom metrics guide for guidance on tagging and metric design.

Why Don’t Timed-Out Requests Appear in Performance Samples?

AppSignal stores performance samples selectively: for each action in a given minute, it keeps the slowest requests and any requests that contain an error. It does not store every request. When a request times out and raises a timeout exception (for example, Rack::Timeout::RequestTimeoutException), AppSignal records it as an error sample, not a performance sample. The request therefore appears in Errors, not in Performance, and is not included in the performance timeline or the slow request list. If you want timed-out requests to appear as performance samples instead of error samples, add the timeout exception class to your ignore_errors configuration. AppSignal then stops treating those requests as errors, and if they are the slowest request for that action in that minute, they are stored as performance samples. See the ignore errors guide for how to configure ignore_errors.

How Do I Delete Samples to Remove PII From AppSignal?

To delete all performance and error samples for an application — for example, to remove personal data that was inadvertently captured in request parameters — go to the application’s Settings page and scroll down to the Delete samples section. Selecting that option removes all stored samples for the application. After deleting samples, deploy a fix to stop the PII from being sent. See the parameter filtering guide and session data filtering guide for how to prevent sensitive data from reaching AppSignal.

How Do I Search for a Trace by a Custom Tag Value?

To find traces that carry a specific tag value, open Performance → Traces and use the tag.<key>=<value> filter syntax in the search field. For example, to find all traces with a reservation_id tag of abc123, enter tag.reservation_id=abc123. The global search bar at the top of the AppSignal dashboard also supports a tag: syntax — for example, tag:abc123 — but this matches the tag value only, not the key. Use tag.<key>=<value> in the Traces screen when you need to filter by a specific key–value pair. See the tagging guide for how to set tags on traces in your application.

How Do I Find Which Action Receives the Most Requests?

Open Performance → Actions, set the timeframe to 30 days, and sort by the Throughput column. The action with the highest throughput appears at the top. The total at the bottom of the list matches the request count shown on your billing usage page. See the actions guide for more on grouping and filtering by action name.

Do Anomaly Detection Alerts Close Automatically When the Threshold Is No Longer Met?

Yes. Alerts opened by an anomaly detection trigger close automatically when the threshold condition is no longer met. To avoid repeated open-and-close notifications for a short-lived spike, configure a cooldown period on the trigger. AppSignal waits for the cooldown to expire before closing the current alert or opening a new one for the same trigger. You can also configure a warm-up period: AppSignal only opens an alert once the threshold condition has stayed true for the full warm-up duration. Both settings are per-trigger. Go to Anomaly Detection, open the trigger, and adjust the warm-up and cooldown fields. See anomaly detection for the full configuration reference.

Logging

How Do I Add Log Attributes as Columns in the Log View?

AppSignal stores log metadata — for example, request_id or custom fields set by your logger — as log attributes. These appear when you expand a log line, but you can also surface them as persistent columns in the log table. To add an attribute as a column, select the three-dot menu (⋯) at the top right of the log table. Choose the attribute you want to display, then save the view. The column selection is saved per view, so it persists across sessions. See the log management guide for more on working with log attributes and filtering.