I built an open-source API monitor that catches silent failures — HTTP 200 doesn't mean your API is healthy

#opensource #webdev #devops #showdev

The problem with standard API monitoring

Most monitoring tools work like this:

Send a request to your endpoint
Check the HTTP status code
If 200 → ✅ healthy. If 5xx → ❌ alert.

This misses an entire category of failures.

What is a silent failure?

Your API returns 200 OK — but something is actually wrong:

// HTTP 200, but...
{
  "error": "database_connection_failed",
  "data": null
}

Or worse — an empty response body. Or a completely different payload than expected.

Standard monitors report this as healthy. Your users experience a broken product.

How CheckAPI handles this

Three levels of response body validation:

1. Keyword validation
Specify a keyword that must be present or absent in the response body.

Present: "status":"ok" must exist → fails if missing
Absent: "error" must not exist → fails if found

2. Regex support
Match patterns for structured validation:
/"user_id":\d+/

3. JSON Path (coming soon)
Target nested fields directly without parsing the full response.

The rest of the feature set

HTTP methods: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS
Custom headers + request body
5 alert channels: Email, Slack, Telegram, Discord, Custom Webhook
SSL certificate expiry alerts (14 days before)
Public status pages
Response time tracking + uptime % (24h / 7d / 30d)
Check intervals: 5min (free) → 1min → 30sec → 10sec

Tech stack

Backend: FastAPI + Celery + Redis + PostgreSQL → Railway

Frontend: Next.js 14 + TypeScript + Tailwind CSS → Vercel

Payments: LemonSqueezy

Email: Resend

Pricing

Plan	Price	Monitors	Interval
Free	$0	10	5 min
Starter	$5/mo	20	1 min
Pro	$15/mo	100	30 sec
Business	$49/mo	Unlimited	10 sec

Free plan has no commercial restrictions — unlike UptimeRobot which restricted
commercial use on free plans in December 2024.

DEV Community