How to monitor an API endpoint: checks, causes and the logs behind the 502

The short version

An API endpoint fails in more ways than a server goes down. The process is up, the disk is fine, and the checkout route answers 502 because the worker behind it died. A monitor that reports a red dot answers the wrong question at 3am: which part, since when, and why. This is the setup that answers those: a URL check on the endpoint, the cause in the incident title, the response phases on the check, the log lines around the failure, and one npx command that hands the wiring to the coding agent you already use.

What a check on an API endpoint does, from the product sheet as of 2026-10:

What down means for an endpoint

A check opens an incident after three failures in a row, and the incident is titled with the cause, not with a timestamp. Three in a row is the noise floor: one dropped packet or one slow handshake does not page anyone.

Every check also watches SSL and domain expiry, on every plan. An API that answers fine with a certificate that runs out on Friday is an incident you want on Tuesday, and it costs no second monitor.

Each check stores the response phases: dns, tcp, tls and wait. When the endpoint answers in four seconds, the phases say whether the time went to DNS, the TLS handshake or the server itself. That split is usually the difference between "the network" and "our code", and it sits on the check rather than in a second tool.

Endpoints that refuse anonymous probes

A public API answers anyone, so a check can see it. Plenty of endpoints answer 401 or 403 to anything that is not a logged-in user, and bot protection fronts many more. A probe blocked this way is recorded as couldn't measure: it is never reported as an outage and never counted against uptime. For those endpoints the honest setup is a different pair. A heartbeat on the worker behind the endpoint, which pings when it finishes and whose silence opens an incident, free and never counted toward the check limit. And the application logs, where alerts fire on new errors on every plan.

Setting it up

1. Run npx upcontrol in the repo. It hands the setup to the coding agent you already use (Claude Code, Cursor, Codex, Gemini CLI, Copilot, Windsurf, Amp, Aider, Cline, opencode) and you ask in plain words: "watch the checkout API and page me when it fails". No hand-written wiring; the agent adds the check and the SDK in one pass. Adding the check by hand in the app works too: the endpoint is a URL like any other.
2. Point the check at the route whose failure would page you. The health route the load balancer already trusts tells you less than the checkout route your customers pay through.
3. Split the status page into components: site, API, checkout. When the API degrades, the public page says "API degraded" while the site still answers, which is the truth of the situation.
4. Pick where alerts go: Telegram, Slack, Discord or email. Slack, Discord and email recipients are unlimited on every plan; Telegram recipients are a plan axis, from 3 on Free. Paid plans add a 15-minute follow-up that says whether the endpoint recovered or is still down.
5. Test the failure, not the success. Make the route return 502 for a few minutes, with a flag or a typo in the upstream, and watch the incident open with the cause in the title. If your endpoint answers 401 to the probe, you learn it now, as couldn't measure on the check, instead of on launch day.

The why, not just down

The incident page for a failed endpoint carries the application log lines around the failure and the deploy that went out ahead of it. A 502 that started one minute after a deploy is a different incident from a 502 that crept in overnight, and both read from the same page. Raw log lines are kept 31 days, alerts fire on new errors in your logs on every plan, and the same npx command wires the logging.

Product events land in the same timeline. Ask the agent "track my users from first visit to purchase" and the funnel appears on the dashboard, next to the check that failed when checkout did.

The honest limits

• Free is 3 website checks, every 5 minutes, counted workspace-wide. Heartbeats are free and never count toward that number. Paid plans move to every minute with 10, 30 or 100 checks.
• No synthetic probes advertised from many cities. The fleet checks from its regions and stores the response phases per check; a worldwide latency map is not what this product is.
• No on-call scheduling, rotations or phone and SMS escalation. Alerts go to Telegram, Slack, Discord and email, and that is the whole list.
• A URL check proves the endpoint answers and how long each phase took. It does not exercise your business logic; the worker's heartbeat and the log alerts carry that half.
• Younger product: fewer integrations than the decade-old incumbents.

One npx command wires the check, the logs and the events: [start with npx upcontrol](https://upcontrol.io/?utm_source=blog&utm_medium=vs&utm_campaign=engine).