---
title: "Uptime monitoring by what you run | Logdash"
description: "How to monitor an API, a REST API, a website, a webhook receiver, a GraphQL server and a database, with the code and the setup for each."
url: https://logdash.io/monitoring
---

# Uptime monitoring by what you run

One page per thing you run, each with the code that makes it checkable and the monitor that watches it.

[API uptime monitoring](https://logdash.io/monitoring/api): API uptime monitoring sends a GET to one public route of your API on a fixed interval, records the status code and the response time, and alerts you the moment the answer falls outside 200-399 or does not arrive within 10 seconds.

[REST API monitoring](https://logdash.io/monitoring/rest-api): REST API monitoring means requesting one public GET route that touches the same database your endpoints use, on a fixed interval from outside your servers, and alerting on any status outside 200-399, which the free plans of Logdash, UptimeRobot and Better Stack all do.

[Website uptime monitoring](https://logdash.io/monitoring/website): Website uptime monitoring requests your site on a schedule, every 5 minutes on a free plan, and alerts you the moment it answers with an error or stops answering, so you hear about downtime before a visitor emails you.

[Webhook monitoring](https://logdash.io/monitoring/webhook): Monitor a webhook receiver with an uptime check on a GET route at the same path, because providers only ever POST to it, and monitor the jobs behind it with a push monitor they call like an inbound webhook, so a missing call becomes an alert.

[GraphQL API monitoring](https://logdash.io/monitoring/graphql): Monitor a GraphQL API through a GET readiness route next to /graphql that runs one database query and returns 503 when it fails, because uptime monitors read the status code and a GraphQL server answers 200 even when a resolver throws.

[Database availability monitoring](https://logdash.io/monitoring/database): Logdash cannot connect to a database itself, so you monitor database availability through something that can: an HTTP health route that runs select 1 and returns 503 when it fails, or a push monitor called by a script on a host next to the database.