Monitor API uptime

Step 1 — choose what to monitor

The best URL to monitor depends on what you want to verify. A few common options:

A dedicated health endpoint is the most reliable choice. It can check database connectivity, cache availability, and other dependencies in a single request — giving WatchCat a truthful signal about whether the API is actually functional.

Adding a health endpoint

If your API doesn't already have one, here's a minimal health endpoint for common stacks. It should return HTTP 200 when healthy and a non-200 status when something is wrong.

# config/routes.rb
get "/up" => "rails/health#show"

# Or a custom check:
get "/health", to: proc { |env|
  ActiveRecord::Base.connection.execute("SELECT 1")
  [200, {}, ["ok"]]
}

app.get('/health', async (req, res) => {
  await db.raw('SELECT 1');
  res.json({ status: 'ok' });
});

Route::get('/health', function () {
    DB::select('SELECT 1');
    return response()->json(['status' => 'ok']);
});

Step 2 — create the monitor

In WatchCat, go to Monitors → New monitor and enter your endpoint URL. Choose an interval and a failure threshold that matches how sensitive this service is.

Expected status codes

By default, any 2xx response is treated as a success. For APIs that return other codes intentionally, you can configure exactly which status codes count as healthy. Supported formats:

POST checks and GraphQL

Some endpoints answer nothing useful to a GET. A GraphQL API is the clearest case: it speaks POST only, so a GET against /graphql tells you nothing about whether your resolvers are alive. Pick POST (or PUT or PATCH) as the HTTP method under Advanced → Request settings and a body field appears:

{ "query": "{ __typename }" }

That query is the cheapest honest GraphQL health probe — it exercises the endpoint, the parser and the schema without touching your data. The body is sent as JSON unless you set a Content-Type header yourself, and the same status and content checks apply to the response. JSON-RPC and SOAP endpoints work the same way.

Custom request headers

Some APIs require authentication headers or custom routing headers on every request. Open Advanced → Request settings in the monitor form and add them as name and value pairs — "Add header" gives you another row, and the name field suggests common header names as you type. Each one is sent with every check:

Cookies work the same way in the Cookies rows just below, which is what you want for an endpoint gated behind a cookie rather than a header. They are combined into a single Cookie header on every check.

Response content checks

A 200 status code doesn't always mean the API is working correctly. Some services return 200 with an error message in the body. Use content checks to verify the response actually contains what you expect:

SSL certificate monitoring

WatchCat checks the TLS certificate on every HTTPS request. An expired or invalid certificate triggers an incident immediately, without waiting for the normal failure confirmation window. This means you'll know about certificate problems before clients start seeing errors.