Authentication is almost always the first thing to break. Your login flow touches your web server, your database, your session store or token issuer, and often one or more third-party identity providers. A failure in any one of those components means your users cannot log in, even if every other page on your site loads perfectly.
The challenge is that a single HTTP monitor cannot test an authentication flow. Logging in is inherently multi-step: you send credentials, receive a token, and then use that token to access a protected resource. If you only check the login endpoint with a GET request, you are testing whether the page exists, not whether authentication actually works.
Why Single-Request Checks Fall Short
Consider a typical API login flow. A client sends a POST request to /api/auth/login with credentials. The server validates them, generates a JWT or session token, and returns it. The client then sends that token in the Authorization header on subsequent requests to access protected endpoints.
A standard HTTP monitor can check that /api/auth/login returns 200 OK. But that tells you nothing about whether the returned token is valid, whether the token can actually authorize access to protected resources, or whether the token issuer is generating tokens with the correct claims and expiration.
Real authentication failures are subtle. The login endpoint responds, but the token it returns is malformed. Or the session store is full and new sessions silently fail. Or a key rotation broke JWT verification on downstream services. These are the failures your users hit, and they are invisible to single-request monitoring.
Setting Up a Multi-Step API Monitor
Velprove's Multi-Step API monitors let you chain multiple HTTP requests together, passing data from one step to the next. This is exactly what you need to test an authentication flow end-to-end.
Multi-Step API monitors are available on all plans. The free plan includes up to 3 steps, Starter gives you 5, and Pro gives you 10. This is enough to test most authentication flows right away.
Here is how to set up a multi-step authentication monitor:
Step 1: Send login credentials
Create the first step as a POST request to your login endpoint. Set the request body to include your test account credentials in JSON format. Add an assertion that the response status is 200 and that the response body contains a token field.
Step 2: Extract the token
Configure Velprove to extract the token value from the JSON response of Step 1. For a typical JWT flow, you extract the value from a field like access_token or token in the response body. This extracted value is available as a variable in subsequent steps.
Step 3: Access a protected endpoint
Create a second HTTP request, a GET to a protected endpoint like /api/me or /api/dashboard. Set the Authorization header to Bearer {{token}}, using the variable extracted in Step 2. Assert that the response returns 200 OK and contains expected user data.
If any step in the chain fails (the login endpoint returns an error, the token extraction fails, or the protected endpoint rejects the token), the entire monitor fails and you receive an alert.
Adapting for Different Auth Patterns
OAuth 2.0 client credentials
For machine-to-machine authentication, your first step sends a POST to the OAuth token endpoint with your client_id and client_secret. Extract the access_token from the response, then use it to call your API in the next step. This validates that your OAuth provider and your API are both functioning correctly.
JWT with refresh tokens
You can extend your multi-step monitor to also test token refresh. After the initial login, add a step that calls your refresh endpoint with the refresh token. Then use the new access token to hit a protected endpoint. This catches failures in your token refresh logic before users get unexpectedly logged out.
Session-based authentication
For traditional session-based APIs that return cookies instead of tokens, Velprove carries cookies forward between steps automatically. Your first step logs in, the server sets a session cookie, and subsequent steps use that cookie to access protected routes, just like a real browser session. For full browser-based login monitoring of applications like WordPress or WHMCS, see our guides on monitoring WordPress login and monitoring WHMCS portals .
Alerting Strategy for Auth Failures
Authentication failures deserve a different alerting strategy than general uptime issues. When your homepage is slow, it is annoying. When your login flow is broken, no one can use your product. Treat auth monitor failures as critical-severity incidents.
Set shorter monitor intervals. On the Pro plan, you can run monitors every 30 seconds. For your primary authentication flow, this means you find out about failures within a minute instead of waiting five minutes. Route alerts to the right channel. Paid plans support Slack, Discord, Teams, and webhooks alongside email. PagerDuty is available on the Pro plan. Connect your auth monitors to PagerDuty so login failures trigger on-call rotations automatically. Use separate test credentials. Create a dedicated test account for monitoring. Do not use a real user account. You do not want monitoring activity to trigger rate limits or security lockouts that affect a real user. Monitor across auth providers. If your application supports multiple login methods (email and password, Google OAuth, SAML), set up a separate multi-step monitor for each one. A failure in one provider does not always mean the others are down.
Get Started
If you are already monitoring your API health endpoints with simple HTTP monitors, multi-step API monitors are the natural next layer. They validate that your endpoints do not just respond. They work together as a complete authentication flow.
Create your Velprove account and start with the free plan. Multi-step API monitors are included on all plans (up to 3 steps on Free, 5 on Starter, 10 on Pro). Upgrade when you need more steps, faster intervals, or advanced alert integrations.
Top comments (0)