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.

​
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: 
appsignal-wrap --no-stdout --no-stderr your-api-key -- your-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 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 sample 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: 
uninitialized constant JSON::Fragment (NameError)
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: 
Appsignal.configure do |config|
  config.activate_if_environment(:development, :staging, :production)
  config.name = "Your App Name"
  config.push_api_key = "your-key-here"
end
Then make sure config.ru loads the integration after Hanami: 
require "appsignal"
require "hanami/boot"

Appsignal.load(:hanami)
Appsignal.start

run Hanami.app
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: 
rescue e ->
  Appsignal.send_error(e, __STACKTRACE__)
  reraise e, __STACKTRACE__
end
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.

​
User Account

​
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.

​
What IP Addresses does AppSignal Use?

Currently the AppSignal Push API uses the following IP addresses: 
185.191.3.93
185.191.3.94
185.191.3.125
185.191.3.126
Currently the AppSignal webhooks orginate from the following IP addresses: 
185.191.3.107
185.191.3.72
185.191.3.116
185.191.3.84
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

​
Why Is My Performance Issue Always Marked as Closed?

An issue’s Open or Closed status is determined by its notification settings, not by whether the underlying problem is still happening. AppSignal marks an issue as Open when it sends a notification for it. Performance issues use the “Never Notify” setting by default, so no notification is sent — which is why they stay Closed. To have a performance issue open on new occurrences, change its notification setting, either per issue or by updating your organization-level default. See Notification settings for how to configure this.

​
How Do I See Error Counts Per Namespace?

To see error counts per namespace, create a Number chart that uses the transaction_exception_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 transaction_exception_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 → Issue list. Actions flagged with the N+1 tag contain repeated database calls. Open a sample 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.