Monitor Your Own APIs and Internal Services with Statusfield

You monitor AWS. You monitor Stripe. You've got Slack and GitHub on your radar.

But what's watching your /health endpoint?

That internal service your team deploys every Thursday. The payment processor callback URL that third-party vendor gave you. The webhook handler that feeds your data pipeline. These aren't in anyone's status catalog — and when they go down, you find out from a panicked Slack message at 2 AM, not from a monitoring alert.

That changes today.

The Gap in Your Monitoring Stack

Most status monitoring tools — including Statusfield, until now — focus on tracking the vendors you depend on. AWS goes down, you know. Stripe has an incident, you're notified.

But you're also running your own infrastructure. APIs, microservices, internal tooling, staging environments. And you probably have vendor endpoints that aren't in any status catalog: your payment processor's callback URL, your SMS provider's delivery endpoint, your accounting software's webhook receiver.

These are just as mission-critical. A single failed health check on /api/health at 3 AM could mean your entire application is serving errors — and nobody knows.

Introducing Custom URL Monitoring

Statusfield now lets you add any HTTPS URL as a monitor, right alongside the 2,000+ catalog services you're already tracking.

Here's what you get:

• HEAD/GET health checks every 5 minutes — fast, low-footprint checks that tell you if your endpoint is responding
• Configurable expected status codes — if your /health endpoint returns 204 No Content, tell us that. Anything else = alert
• Custom headers — need to pass an Authorization header or API key to reach your endpoint? Supported
• Response time tracking — spot latency degradation before it becomes an outage
• Uptime history — the same historical view you get for catalog services, now for your own APIs
• Instant alerts — email, Slack, Discord, or webhooks — the same notification stack you already use

How It Works (The Technical Bit)

When you add a custom URL monitor, Statusfield stores your endpoint configuration and schedules health checks every 5 minutes.

Each check:

1. Makes a HEAD request to your URL (falls back to GET if HEAD isn't supported)
2. Validates the response — by default, any 2xx or 3xx status = healthy; you can configure an exact expected status code
3. Records response time for trend analysis
4. Applies SSRF protection — we validate your URL on every check, not just creation, to prevent DNS rebinding attacks
5. Prevents false positives — a single flaky network response won't trigger an alert. We require 2 consecutive failures before marking a service as down

Custom headers you configure are sent with every request — useful for health endpoints that require authentication.

All checks run with a 10-second timeout in batch mode, so 50 monitors complete in well under 10 minutes.

Use Cases

Internal health endpoints

Your /health or /api/status endpoint is the canary in your coal mine. Add it to Statusfield and you'll know the moment your application stops responding — before your users do.

https://api.yourapp.com/health
https://api.yourapp.com/api/status
https://admin.yourapp.com/healthz

Staging and preview environments

Staging environments fail silently all the time. A broken deployment, an expired SSL cert, a misconfigured environment variable — add your staging URLs to get notified when they go dark.

Third-party webhooks and callbacks

Your payment processor's webhook URL, your SMS provider's delivery endpoint — these are URLs you own, but they're not in any catalog. Monitor them.

Vendor APIs not in our catalog

If we don't have a status provider for a service you depend on, you can now add their status URL or API health endpoint directly. Not a perfect substitute for a native integration, but far better than flying blind.

SLA validation

Add your key endpoints to Statusfield and you've got independent uptime data. Useful for validating vendor SLAs and for your own internal SLA commitments.

Security First

We take SSRF (Server-Side Request Forgery) seriously. Custom URL monitors are HTTPS only, and we validate every URL against private IP ranges (RFC-1918, loopback, link-local, AWS metadata) on every health check — not just at creation time. Redirect chains are followed manually with per-hop validation.

Custom URL monitors are completely private to your workspace — they never appear in the public catalog or search results.

Getting Started

1. Go to your Monitors dashboard
2. Click "Add Custom URL"
3. Enter your HTTPS endpoint URL
4. Optionally configure: expected status code, custom headers, HTTP method
5. You're monitoring

Your custom URL will appear in your monitors list alongside your catalog services, with the same status badges, history, and alert routing.

Frequently Asked Questions

Does it support HTTP (non-SSL) endpoints?

No — HTTPS only. This is a security requirement, not a technical limitation. Plain HTTP endpoints expose your auth headers and our health check traffic to interception.

What if my endpoint requires a custom port?

Supported — just include the port in your URL: https://api.yourapp.com:8443/health.

How do I monitor an endpoint that needs authentication?

Use custom headers. Add an Authorization: Bearer <token> header when configuring your monitor. Headers are encrypted at rest.

Will it follow redirects?

Yes, up to 3 redirects. Each hop is validated against SSRF rules.

What's the check frequency?

Every 5 minutes. This isn't configurable yet — it's on our roadmap.

Can I monitor internal/private IPs?

No. Private IPs, loopback addresses, and link-local ranges are blocked for security reasons. Monitors must reach a public HTTPS endpoint.

What counts as "down"?

By default: any non-2xx/3xx response, a timeout, or a network error. If you configure expectedStatusCode, anything other than that exact code is considered down. We require 2 consecutive failures before triggering an alert to avoid false positives from transient network issues.

Add your first custom URL →