How to Monitor APIs with Authentication Headers Using Vigilmon

Most uptime monitoring tutorials show you how to monitor public URLs. But in practice, many of your most critical endpoints require authentication — an API key, a Bearer token, or a session cookie. Monitoring unauthenticated endpoints only tells you that the server is running; it doesn't tell you that authenticated requests are actually working.

Here's how to set up monitoring for authenticated API endpoints with Vigilmon.

Why Monitoring Behind Auth Matters

Consider a typical SaaS API flow:

1. User sends request with Authorization: Bearer <token>
2. API validates token against your auth service
3. API fetches data from your database
4. API returns response

A single-endpoint "is port 443 open?" check misses failures in steps 2, 3, and 4. Your server could be running and healthy at the TCP level while every authenticated request is silently failing — because your auth service is down, your database is rejecting connections, or your token validation code has a bug.

Monitoring with auth headers catches this.

Option 1: Use a Dedicated Health Endpoint (Recommended)

The cleanest approach: create a health check endpoint that requires authentication, checks all your downstream dependencies, and returns a structured response.

Example (Express.js):

app.get('/api/health', authenticateApiKey, async (req, res) => {
  const checks = {}

  try {
    await db.query('SELECT 1')
    checks.database = 'ok'
  } catch (e) {
    checks.database = 'error'
  }

  try {
    await redisClient.ping()
    checks.cache = 'ok'
  } catch (e) {
    checks.cache = 'error'
  }

  const allOk = Object.values(checks).every(v => v === 'ok')
  res.status(allOk ? 200 : 503).json({ status: allOk ? 'ok' : 'degraded', checks })
})

Then monitor /api/health with your service API key. Vigilmon checks this endpoint, sends the API key in the header, verifies the response body contains "status":"ok".

Why this is better than monitoring a real API endpoint:

• You control what it checks
• It won't create test data or have side effects
• You can add/remove dependency checks without changing your monitor

Option 2: Monitor a Real Read Endpoint

If you don't control the API or can't add a health endpoint, monitor a real read-only endpoint that requires authentication.

Common candidates:

• GET /api/users/me — returns the current authenticated user
• GET /api/status — returns account status
• GET /api/ping — a lightweight ping endpoint with auth

In Vigilmon, add custom headers:

When creating a monitor in Vigilmon, you can add custom request headers:

Authorization: Bearer your-monitoring-service-token
X-API-Key: your-api-key

The monitor sends these headers with every check, just like a real client would.

What to use as the monitoring token:

• Create a dedicated service account or API key specifically for monitoring
• Give it read-only permissions
• Don't use a production user's credentials
• Rotate it on the same schedule as your other service tokens

Setting Up in Vigilmon

1. Go to vigilmon.online and create a new monitor
2. Set URL to your authenticated endpoint (e.g., https://api.yourapp.com/api/health)
3. Set Method to GET (or POST if your endpoint requires it)
4. Under Request Headers, add:
   • Authorization: Bearer your-monitoring-token
   • Or X-API-Key: your-key depending on your auth scheme
5. Set Expected Status to 200
6. Optionally add a Keyword Check: "status":"ok" to verify the response body, not just the status code

Option 3: API Key in Query String

Some APIs authenticate via query string parameters. While this is less secure than header-based auth, you can configure Vigilmon monitors with query strings in the URL:

https://api.yourapp.com/health?api_key=your-monitoring-key

Note: query string parameters are visible in URLs and logs. Prefer header-based auth when possible.

Handling Token Rotation

Monitoring tokens need to be rotated like any other credential. When you rotate:

1. Generate new monitoring token in your app
2. Update the Vigilmon monitor header value
3. Revoke the old token

If you forget to update Vigilmon after token rotation, your monitor will start returning 401 — which is good! It means your monitoring is actually exercising the auth layer. Just update the token promptly.

What Status Codes to Expect

When setting up authenticated monitoring, think through what status codes are "healthy":

In Vigilmon, set your expected status to 200. Any deviation will trigger an alert.

Multi-Step Authentication (OAuth Flows)

If your API uses OAuth 2.0 with short-lived access tokens, you have two options:

Option A: Use a long-lived API key instead
Create a service account with an API key (not an OAuth token) specifically for monitoring. Most APIs that use OAuth for users also support API key auth for service accounts.

Option B: Use a dedicated monitoring endpoint
Create a health check endpoint that you can call with a long-lived service key, bypassing the OAuth flow entirely.

Monitoring with short-lived OAuth tokens is not recommended — the token will expire and your monitor will start failing even though your service is healthy.

What This Doesn't Replace

Authenticated monitoring confirms that:

• Your API server is running
• Authentication middleware is working
• Downstream dependencies (DB, cache) are reachable
• Your health endpoint logic is correct

It doesn't replace:

• Load testing (your endpoint might return 200 at 1 req/s but fail at 100 req/s)
• Functional testing (your business logic might be returning wrong data)
• Log monitoring (Sentry, Datadog, or similar for error rates and exceptions)

Use uptime monitoring as the first line of alert detection. Layer error tracking and log monitoring for deeper visibility.

Set up authenticated API monitoring at vigilmon.online — free tier, no credit card required.