Monitor API uptime

Set up HTTP monitors for your API endpoints and get notified the moment they go down.

APIs fail in ways that your main application won't always surface. A single endpoint can start returning 500 errors while the rest of the app looks fine. WatchCat checks your endpoints continuously so you find out before your users do.

Step 1 — choose what to monitor

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

Health check endpoint /health or /up — purpose-built for monitoring, returns 200 when the app is ready. The most reliable option.

Public API root e.g. https://api.example.com/v1 — confirms routing and TLS are working. Simpler to set up if you don't have a dedicated health endpoint.

Critical endpoint e.g. /v1/products — monitors a specific route that customers depend on. More targeted but may return non-200 for legitimate reasons.

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.

Rails

# 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"]]
}

Express (Node.js)

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

Laravel

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.

Interval 1 min for customer-facing APIs; 5 min for internal tools

Alert after 2 failures — filters transient blips without delaying real alerts

Expected status 200 for a clean health endpoint

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:

200 Exact match

2xx Any code in the 200–299 range

200-204 Numeric range

2xx,404 Comma-separated list — any 2xx or a 404 is fine

Custom request headers

Some APIs require authentication headers or custom routing headers on every request. You can add headers in the monitor form as a JSON object — they are sent with every check. For example, to pass an API key:

{ "Authorization": "Bearer YOUR_API_KEY" }

Note: Headers are stored in WatchCat and sent with each check. Avoid putting credentials here that would be harmful if exposed. For monitoring purposes, a read-only health endpoint that doesn't require authentication is the safest choice.

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:

Response must contain

A string that must appear in the response body. If it's missing, the check is treated as a failure. Useful for verifying a health endpoint returns ok or your API returns a known key.

Response must not contain

A string that must not appear. If it does, the check fails. Useful for detecting known error messages even when the HTTP status is 200.

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.

Start monitoring in minutes

Free plan available. No credit card required.

Start free See pricing View subprocessors