01
The route returns the wrong status
A deploy flips a 200 to a 500 or a silent 401. The page loads, the API does not, and orders quietly stop.
API monitoring
PulseStack watches every endpoint for status code, response time and availability, and pages you the moment a route starts failing. Attach custom headers to reach authenticated routes, not just the public ones.
14-day trial. No card on the free plan. All eight monitor types from £15 a month.
Live HTTP request from our network - the same check PulseStack runs as often as every 30 seconds.
signals per check: status code, response time, availability
fastest check interval on Enterprise
native alert channels, on failure and recovery
request headers to monitor authenticated routes
A 200 on the homepage tells you nothing about the API your product actually runs on. These are the failures that slip past a basic uptime check.
A deploy flips a 200 to a 500 or a silent 401. The page loads, the API does not, and orders quietly stop.
The endpoint still answers but takes six seconds. Timeouts cascade through every service that depends on it.
A rotated key or lapsed token locks out an integration. Without a header-aware check, you never see it fail.
A third-party API your route calls falls over. Your endpoint returns errors it did not cause and you get blamed.
The endpoint is fine from your desk but broken from another location. Single-location checks miss it entirely.
Support tickets become your monitoring. By the time someone reports it, the damage to trust is already done.
No agent to install, no SDK to import. Give PulseStack a URL and a header, and the first check runs immediately.
Setup takes minutes, not a sprint. Here is the whole flow.
Paste the URL of the route you want watched. GET, health check or a real business endpoint.
Add a bearer token or API key so the check hits authenticated routes exactly as your app does.
Choose the healthy status range, the check interval and how many failures in a row trigger an alert.
Pick channels: Slack, PagerDuty, SMS and more. Alerts fire on failure and again on recovery.
Each cycle, PulseStack sends the request with your headers, reads the response and records the result. Here is what a healthy check looks like next to a failing one.
No add-on tiers for the basics. These come with the monitor.
Run your API checks alongside everything else that keeps your product online, from one account.
Page and endpoint availability by status code and response time.
Confirm a word or phrase is present, or flag when it appears.
Reachability check at the network layer for any host.
Watch a specific port and the service listening on it.
Status code, response time and availability with custom headers.
Cron and background jobs that must check in on schedule.
Resolve records and catch unexpected changes.
Days-to-expiry tracking so a domain never lapses.
Set a threshold, route it to Slack, and let PulseStack watch the endpoints you cannot afford to lose.
Where a PulseStack API monitor sits against a rough homemade check or a status page you refresh by hand.
| Capability | A cron + curl script | Manual checking | PulseStack API monitor |
|---|---|---|---|
| Status code and response time tracked | If you build it | No | Built in |
| Custom headers for auth routes | Manual | No | Yes |
| Consecutive-failure threshold | Rarely | No | Configurable |
| Failure and recovery alerts | You wire it | No | Eight channels |
| Multi-location checks | No | No | Yes |
| Public status page and incident history | No | No | Included |
| Setup time | Hours | Ongoing effort | Minutes |
Watch health checks and business-critical routes with the same auth headers your services use, and catch a bad deploy before it spreads.
Third-party APIs fail on their schedule, not yours. Monitor the routes you depend on and know instantly when an upstream goes dark.
Thresholds cut the noise, PagerDuty and Slack routing gets the right person, and recovery alerts close the loop without a manual all-clear.
Every API monitor can fire through any of these, on failure and again on recovery, only after your threshold is met.
API endpoint monitoring sends real HTTP requests to your API endpoints at regular intervals and validates the responses. Unlike website monitoring that checks if a page loads, API monitoring verifies status codes, response times, response body content, JSON structure, and header values. It catches issues like a 200 response that returns empty data, a response missing critical fields, or latency that has crept above acceptable thresholds.
After each request, PulseStack™ runs your configured assertions against the response. You can check that the status code matches (e.g. 200), that the response body contains specific text or JSON keys, that numeric values fall within expected ranges, and that headers include required values like cache-control or content-type. If any assertion fails, the check is marked as failed and alerts trigger. This catches silent data corruption that status codes alone would miss.
Yes. PulseStack™ supports Bearer tokens, API keys in headers or query parameters, Basic authentication, and custom header schemes. You can set any combination of request headers, including Authorization, X-API-Key, or custom authentication headers your API requires. Credentials are encrypted at rest and never exposed in logs or the dashboard.
Synthetic monitoring typically refers to scripted multi-step browser transactions that simulate user journeys. API monitoring focuses on individual endpoint health: sending a request and validating the response. PulseStack™ API monitoring is closer to synthetic API testing. You define the request (method, headers, body) and the expected response. For browser-based synthetic monitoring, use our website monitoring with keyword checks.
When creating an API monitor, select POST as the HTTP method and enter your request body as raw JSON. Set the Content-Type header to application/json. PulseStack™ sends exactly the request you configure, including the body, and validates the response against your assertions. This works for any method: POST, PUT, PATCH, and DELETE.
Yes. GraphQL APIs use POST requests with a JSON body containing the query. Create an API monitor with the POST method, set your endpoint URL, add the Content-Type: application/json header, and put your GraphQL query in the request body. Add response assertions to validate that the data field contains expected values and that the errors field is absent or empty.
PulseStack™ checks your API from 7 global locations simultaneously. If only one location reports a failure while others succeed, it is flagged as a regional network issue rather than an API outage. This eliminates false alerts caused by transient routing problems, regional CDN issues, or monitoring-location-specific network blips. You can configure how many locations must fail before an alert triggers.
We track P50 (median), P95, and P99 response times for every endpoint. Average response time hides outliers. The P95 value tells you that 95% of requests complete within that time. The P99 reveals your worst-case scenarios. Set alert thresholds on any percentile to catch degradation before it affects enough users to generate complaints.
Yes. Monitoring third-party APIs like Stripe, Twilio, SendGrid, or OpenAI is one of the most common use cases. You cannot control their uptime, but you need to know immediately when they degrade. Create monitors for each external dependency and set response time thresholds appropriate to their SLAs. When a provider has an incident, you will know before their status page updates.
The free plan includes 50 monitors total, and each API endpoint counts as one monitor. Checks run every 3 minutes on the free plan and as frequently as every 30 seconds on paid plans. All plans include response validation, multi-region checks, and access to all 16+ alert channels.
Status code, response time and availability on every route, with the headers to reach the ones that matter. Start free, upgrade for API monitoring from £15 a month.