> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Uptime monitoring
Met AppSignal uptime monitoring kunt u meldingen ontvangen wanneer uw applicatie niet beschikbaar is.
We controleren uw applicatie vanuit meerdere regio's over de hele wereld en we waarschuwen u wanneer uw applicatie niet bereikbaar is vanuit een van deze regio's. We maken ook grafieken van de prestaties van het endpoint dat u opgeeft vanuit verschillende regio's over de hele wereld.
## Installatie
Om een nieuwe uptime monitor-check in te stellen, klikt u op de knop "Add uptime monitor" op de [Uptime Monitoring](https://appsignal.com/redirect-to/app?to=uptime_monitors)-pagina.
Geef de volledige URL op (inclusief `http://` of `https://`) van de pagina die u wilt controleren. Onze servers doen elke minuut vanuit meerdere regio's een verzoek aan deze URL en melden of het verzoek mislukt of als de responsstatuscode niet in het `2xx`-bereik valt.
Om meldingen te ontvangen wanneer uw applicatie niet beschikbaar is, selecteert u een meldingsmethode. Om te voorkomen dat u meldingen ontvangt bij kleine netwerkhiccups, raden we aan een warm-up-periode voor meldingen van ten minste één minuut in te stellen.
U kunt headers instellen die worden meegezonden in de verzoeken die we uitvoeren tegen de door u opgegeven URL. Hiermee kunt u autorisatieheaders instellen om de verzoeken te laten doorgaan.
## Hoe het werkt
We pingen uw applicaties vanuit AWS Lambda-workers die vanuit de volgende regio's worden uitgevoerd:
We zullen de opgegeven URL aanvragen vanuit de volgende regio's:
* Azië-Pacific (Seoul)
* Europa (Frankfurt)
* Noord-Amerika (N. Virginia)
* Zuid-Amerika (São Paulo)
Er geldt een time-out van 30 seconden voor de verbinding. Als uw server niet binnen die tijd reageert, beschouwen we de applicatie als niet beschikbaar.
Houd er rekening mee dat als onze verzoeken aan uw applicatie mislukken vanuit één regio, dit niet noodzakelijk betekent dat uw applicatie niet beschikbaar is. Het kan in plaats daarvan duiden op een netwerkprobleem tussen AWS Lambda en uw endpoint.
### User Agent
Onze uptime monitoring-verzoeken aan uw applicatie stellen de `User-Agent`-header als volgt in, waarbij `` een versienummer is zoals `1.0`:
```sh Shell theme={null}
AppSignalBot/ (+https://appsignal.com)
```
Hiermee kunt u verzoeken van AppSignal detecteren.
### IP-allowlisting
We voeren onze uptime checks uit op een serverless framework en hebben geen controle over welk IP-adres wordt gebruikt om het verzoek aan uw applicatie te doen. Daarom kunnen we geen lijst met IP-adressen verstrekken om toe te voegen aan een allowlist. De te monitoren URL moet publiek bereikbaar zijn vanaf het open internet.
## Metrics
Voor elke uptime monitor-check maken we verschillende metrics aan die u kunt gebruiken om uw eigen [custom graphs](/metrics/custom#graphing-custom-metrics) te maken en uw eigen [triggers voor anomaliedetectie](/anomaly-detection#creating-and-configuring-triggers) in te stellen.
Deze metrics worden getagd op basis van de **region** waarvandaan het verzoek is gedaan en de **name** van de uptime monitor-check. De regiotags zijn `asia-pacific`, `europe`, `north-america` en `south-america`.
### Foutentelling
De `uptime_monitor_error_count`-metric is een teller die voor een bepaalde minuut wordt ingesteld op nul als het verzoek is gelukt of op één als het verzoek mislukt.
### Endpoint-prestaties
De `uptime_monitor_duration`-metric is een gauge die de duur van het verzoek voor elke regio bijhoudt. Hiermee kunt u zien of de latency naar uw servers toeneemt.
## Plannen en verzoeken
Als de applicatie die de URL serveert een AppSignal-integratie gebruikt, kan onze uptime monitor veel van de maandelijkse verzoeken van uw plan verbruiken. We raden aan om een speciaal health-check-endpoint in te stellen en AppSignal te configureren om verzoeken aan dat endpoint te negeren, zodat ze niet meetellen voor de limiet van uw plan.
### Voorbeeld
Hier is een voorbeeld van een health-check-endpoint in Ruby on Rails. We zorgen ervoor dat we al onze externe services raken, zoals de database en Redis, iets dat misschien niet op de homepage gebeurt, zodat alle services operationeel zijn.
```ruby Ruby theme={null}
# routes.rb
resource :health_check, :only => :show
```
```ruby Ruby theme={null}
# 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
```
Vervolgens configureren we AppSignal om verzoeken aan dat endpoint te negeren met [de configuratieoptie `ignore_actions`](/ruby/configuration/options#option-ignore_actions):
```ruby Ruby theme={null}
Appsignal.configure do |config|
config.ignore_actions << "HealthChecksController#show"
end
```
```yaml YAML theme={null}
default: &defaults
ignore_actions:
- HealthChecksController#show
```