API & webhooks

Health endpoint

GET /api/health — uptime monitor target.

What it is

GET https://app.remixcrm.com/api/health

A public, unauthenticated endpoint that returns 200 only when RemixCRM can reach its database. Designed to be the target of an uptime monitor like UptimeRobot, BetterStack, or Healthchecks.io.

Response

Healthy

HTTP/1.1 200 OK
content-type: application/json
cache-control: no-store

{
  "ok": true,
  "db": "ok",
  "db_error": null,
  "uptime_seconds": 1234,
  "latency_ms": 18,
  "timestamp": "2026-05-25T20:30:00.000Z"
}

Unhealthy

HTTP/1.1 503 Service Unavailable
content-type: application/json

{
  "ok": false,
  "db": "error",
  "db_error": "connection timeout",
  "uptime_seconds": 1234,
  "latency_ms": 5024,
  "timestamp": "2026-05-25T20:30:00.000Z"
}

What's checked

A single cheap query against the organizations table. If it succeeds, the app process is alive AND the database is reachable AND service-role credentials are valid. Three signals in one check.

What is not checked:

  • External integrations (Stripe, Twilio, etc.) — they have their own status pages
  • Disk space, memory, CPU — handled by Railway's own monitoring

Setting up an uptime monitor

UptimeRobot (free, easy)

  1. Sign up at uptimerobot.com
  2. + Add New Monitor
  3. Monitor Type: HTTP(s)
  4. URL: https://app.remixcrm.com/api/health
  5. Monitoring Interval: 5 minutes (free) or 1 minute (paid)
  6. (Optional) Advanced Settings → Keyword: require body contains "ok":true
  7. Add alert contacts (email, Slack, SMS)

You'll get pinged within minutes of an outage.

BetterStack (nicer UI, free tier)

Similar — paste the URL, expect 200, expect body match "ok":true. Their free tier is 3-minute intervals.

Use as a deploy smoke test

After deploying, run this in CI to confirm the new container is alive:

for i in 1 2 3 4 5; do
  if curl -fsS https://app.remixcrm.com/api/health > /dev/null; then
    echo "Deploy healthy"
    exit 0
  fi
  sleep 5
done
echo "Deploy unhealthy after 25s"
exit 1

Privacy / abuse

The endpoint reveals only that the app is running and the DB is reachable. It doesn't expose any tenant data, user info, or version numbers. There's no rate limit currently — if abuse becomes an issue, expect a rate cap (say, 60 req/min/IP).