Uptime monitoring
With AppSignal uptime monitoring you can receive alerts when your application is down. We check the given URL of your application from multiple regions across the world and will open an alert when any of these regions can't reach the given URL. We also graph the performance of this endpoint from different regions around the world.
Setup
To setup a new uptime monitor check, click the "Add uptime monitor" button on the Uptime Monitoring page.
Fill out the name and provide a full url (including http/https) to the page you'd like to check. Note that we consider any response in the 200 range a succesfull request and any other response code will yield a failure.
Use the description field to help out anyone who receives the alert, by providing information on who to contact or how to solve the issue.
Select a notifier to recieve notifications when the endpoint does not return a 200 state. Sometimes there can be small network hickups, we recommend to use a warmup of at least 1 minute to prevent alerts being sent when there's not actually an issue.
Headers
If your endpoint requires authorization, you can use these fields. For example, suppose you are using a Basic
authentication mechanism. In that case, you can send Authorization
for header name and Basic xxx
for header value where xxx
should be username:password
64 base encoded.
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)
How the request works
We ping your applications from AWS Lambda workers that are executed from the regions listed above. There's a 30-second timeout to the connection. If your server does not respond within 30 seconds, we consider the application down from that location.
However, if a single region has issues, that doesn't necessarily mean the application is down. It could mean that the connection between AWS Lambda in that region and your endpoint can not be set up in the allotted 30-second timeout. This could point to a networking issue between AWS Lambda and your endpoint.
User-Agent
To detect AppSignal uptime monitor requests, your check will send a specific User-Agent
header with the request in the following format;
1
AppSignalBot/<version> (+https://appsignal.com)
For example:
1
AppSignalBot/1.0 (+https://appsignal.com)
IP whitelisting
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 the given URL. Therefore at this moment we're unable to provide a list of IP addresses to whitelist. Right now this feature requires the given URL to be publicly reachable.
Metrics
For every uptime monitor check we create serveral custom metrics you can use to set your own (custom) triggers on. These metrics are:
Error count
This metric is a Counter that is either 0 if there's no issue, or 1 when there is an issue.
The metric name is uptime_monitor_error_count
and the tags are:
region
the region we made the request from, region tags are:asia-pacific
europe
north-america
south-america
name
the name of the uptime monitor check.
Endpoint performance
This metric is a Gauge that is tracks the duration per region.
The metric name is uptime_monitor_duration
and the tags are:
region
the region we made the request from, region tags are:asia-pacific
europe
north-america
south-america
name
the name of the uptime monitor check.
Plans and Requests
The requests made by us to check your service are not deducted from the plan requests by default. This means just the health check alone can consume a big chunk of your (developer) plan. We recommend not pinging the homepage of your project, but to setup a dedicated health-check endpoint that can be ignored in the AppSignal config. This way the requests from the uptime monitor checks won't count towards your plan's total requests.
Example in Ruby/Rails
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
1
resource :health_check, :only => :show
health_checks_controller.rb
1
2
3
4
5
6
7
8
9
10
11
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
appsignal.yml
1
2
3
4
5
6
7
8
default: &defaults
push_api_key: "<%= ENV['APPSIGNAL_PUSH_API_KEY'] %>"
# Your app's name
name: "AppSignal"
ignore_actions:
- HealthChecksController#show