Skip to main content
With AppSignal uptime monitoring you can receive alerts when your application is down. We check your application from multiple regions across the world, and we will alert you when your application can’t be reached from any of these regions. We also graph the performance of the endpoint you provide from different regions around the world. Screenshot of uptime monitoring dashboard

​
Setup

To setup a new uptime monitor check, click the “Add uptime monitor” button on the Uptime Monitoring page. Provide the full URL (including http:// or https://) of the page you’d like to check. Our servers will make a request to this URL every minute from multiple regions and report if the request fails or if the response status code is not in the 2xx range. In order to receive notifications when your application is down, select a notification method. To prevent receiving alerts on small network hiccups, we recommend setting an alert warm-up period of at least one minute. You can set headers to be sent in the requests we perform against the URL you provide. This allows you to set authorization headers to enable the requests to go through.

​
How it works

We ping your applications from AWS Lambda workers that are executed from the following regions: We will request the given URL from the following regions:
  • Asia-Pacific (Seoul)
  • Europe (Frankfurt)
  • North America (N. Virginia)
  • South America (São Paulo)
There’s a 30 second timeout to the connection. If your server does not respond within that time frame, we consider the application to be down. Note that if our requests to your application are failing from a single region, that doesn’t necessarily mean your application is down. It could instead point to a networking issue between AWS Lambda and your endpoint.

​
User Agent

Our uptime monitoring requests to your application will set the User-Agent header as follows, where <version> is a version number like 1.0:
Shell
AppSignalBot/<version> (+https://appsignal.com)
This allows you to detect requests coming from AppSignal.

​
IP Allowlisting

We run our uptime checks on a serverless framework and have no control over what IP address will be used to make the request to your application. Therefore, we’re unable to provide a list of IP addresses to allowlist. The URL to monitor must be publicly reachable from the open internet.

​
Metrics

For every uptime monitor check we create several metrics that you can use to create your own custom graphs and set your own anomaly detection triggers. These metrics will be tagged by the region from which the request was made, and the name of the uptime monitor check. The region tags are asia-pacific, europe, north-america and south-america.

​
Error count

The uptime_monitor_error_count metric is a counter that, for a given minute, will be set to zero if the request succeeded or to one if the request fails. Screenshot of uptime monitoring error count custom metrics form

​
Endpoint performance

The uptime_monitor_duration metric is a gauge that tracks the duration of the request for each region. This allows you to see if the latency to your servers is increasing. Screenshot of uptime monitoring performance custom metrics form

​
Plans and Requests

If the application serving the URL uses an AppSignal integration, our uptime monitor can use up a lot of your plan’s monthly requests. We recommend setting up a dedicated health-check endpoint and configuring AppSignal to ignore requests to that endpoint so that they don’t count toward your plan’s limit.

​
Example

Here’s an example of a health-check endpoint in Ruby on Rails. We make sure to hit all our external services, such as the database and Redis, something that might not happen on the homepage, ensuring all services are operational. 
# routes.rb
resource :health_check, :only => :show

# health_checks_controller.rb
class HealthChecksController < ApplicationController
  def show
    # Check MongoDB
    Account.mongo_client.command(:getLastError => 1)
    # Check Redis
    Redis.new.ping
    head 200
  rescue Mongo::Error, Redis::CannotConnectError
    head 503
  end
end
Then, we configure AppSignal to ignore requests to that endpoint using the ignore_actions configuration option: 
Appsignal.configure do |config|
  config.ignore_actions << "HealthChecksController#show"
end