Errors + uptime · in one place

Stop paying two vendors to tell you the same outage.

RadarHQ catches your exceptions and watches your endpoints. One workspace, one bill of cognitive load, one place your team actually looks when something breaks.

Access is by invitation. Reviewed by a person, usually within 48h.

radarhq.io · acme

Issues

3 open
NoMethodError
undefined method 'id' for nil:NilClass
× 8.4k
RoutingError
No route matches [GET] "/api/v2/users"
× 412
Net::ReadTimeout
execution expired (Stripe::API)
× 31

Uptime · api.acme.com

99.91%
30d ago today
Apr 14 · 1 incident
Returned 503 for 4m 12s

Two tools. One tab.

The status of your product is split across browser tabs, Slack channels, and on-call apps. RadarHQ puts both signals in the same list, sorted by what's actually on fire.

Before

Error tracker 12 unresolved
NoMethodError #48212h
TimeoutError #48203h
ArgumentError #48195h
Ping tool DOWN
api.acme.com — 4 min ago
Status: 503 Service Unavailable
#alerts 47 unread

3 tools. 3 logins. 3 sources of truth that disagree.

With RadarHQ

Inbox All
Down
api.acme.com — 503 for 4m 12s
started 4 min ago
Err
NoMethodError on nil:NilClass
× 8,431 in last 24h
Up
checkout.acme.com — recovered
2h ago · 1m 47s downtime

1 tool. 1 inbox. 1 source of truth.

Errors

Catch the exception. Skip the noise.

Error tracking that groups what should be grouped, ignores what should be ignored, and tells you exactly what changed.

Fingerprinted, not flooded.

One bug, one issue. RadarHQ groups exceptions by stacktrace fingerprint, so a NoMethodError thrown 10,000 times shows up once — with a count, a first-seen, a last-seen, and the environments it touched. You see issues, not log lines.

NoMethodError
× 8,431
undefined method 'name' for nil:NilClass
production staging production

A lifecycle, not a list.

Every issue moves through four states: open, in progress, on hold, resolved. Not a binary "did you click the checkbox." Assign it, snooze it, push it back to open when it shows up again — RadarHQ tracks the transitions and timestamps so you can answer "what did we ship that fixed it" later.

Open In progress On hold Resolved
resolved by alex@ · 2d ago · commit 8f3a2b1

One POST and you're in.

No SDK gymnastics. Send a JSON payload to your workspace's ingest endpoint with a stacktrace and any context you want indexed. Libraries help, but if you can hit an HTTP endpoint, you can report errors. Works the same from Rails, Node, Python, a cron job, a shell script.

curl
$ curl -X POST \
  https://radarhq.io/api/v1/ingest \
  -H "X-API-Key: $RADAR_KEY" \
  -d '{
    "type": "NoMethodError",
    "message": "undefined method id",
    "level": "error",
    "stacktrace": "..."
  }'

201 Created
issue_id: iss_8f3a2b1

Uptime

Watch the endpoint. Mean it.

HTTP and HTTPS health checks every five minutes, response-time tracking, incident history. The boring kind of monitor — the kind that works.

api.acme.com 99.87%
30d agotoday
Apr 14 · 1 incident
4m 12s downtime

Five-minute checks, not five-minute promises.

Every monitor pings your URL on a five-minute interval from our checker. Response status, response time, and full response headers are recorded. We don't market sub-second checks we don't actually run. Five minutes is honest, and it's what catches real outages without flooding you over a flaky 502.

Incident
api.acme.com returned 503 for 4m 12s
Started · Apr 14, 14:22:08 UTC
Recovered · Apr 14, 14:26:20 UTC

Down. Up. Logged.

When your endpoint stops responding, you get an email. When it recovers, you get another. Both are tied to an incident record with start time, end time, duration, and the HTTP status that triggered it. No paging fatigue, no "we detected a possible degradation" ambiguity. Down or up.

99.98%
24h
99.91%
7d
99.87%
30d

Numbers you can point at.

Uptime over 24 hours, 7 days, and 30 days, computed from real check results, not interpolated. Average response time on the same windows. Drop them in a status page, paste them in a board update, send them to your PM when they ask "is the API actually fine."

Quiet by default

Your phone shouldn't ring every time a healthcheck blinks.

We send one email when something breaks, one email when it recovers, and one webhook per state change. That's it. No daily digests, no "we noticed you have 3 unresolved issues," no engagement nudges. The product is a tool, not a relationship.

1 webhook · 1 event · no batching, no aggregation

POST /your-webhook
{
  "event": "issue.resolved",
  "issue_id": "iss_8f3a2b1",
  "title": "NoMethodError: undefined method 'name' for nil",
  "resolved_by": "[email protected]",
  "occurrences": 8431,
  "duration_open_seconds": 142800
}

Access

How invitations work.

We onboard new workspaces by hand. It keeps the platform fast, the support queue answerable, and the user list interesting.

01

You ask.

Tell us what you're building and what you're monitoring today.

02

We reply.

Usually within 48 hours. If we're a fit, you get a one-time invitation code.

03

You bring your team.

Once you're in, you can invite teammates yourself. Workspaces have admin and member roles, no per-seat nonsense.

We read every one. We reply to every one.

Why we built this.

We were paying $400 a month for an error tracker that buried us in notifications and another $80 for an uptime tool that looked like it was last updated in 2014. Neither knew the other existed. When the API went down, our on-call had to flip between four tabs to figure out what was actually broken.

So we built the thing we wanted: errors and uptime in one inbox, one webhook format, one workspace. Quiet alerts. A team plan that doesn't punish you for adding the new junior engineer.

We're keeping it small on purpose.

— The RadarHQ team

Built on Rails 8, Hotwire, Postgres, and Tailwind. Hosted on bare-metal in Europe. No analytics scripts on this page.

Rails 8 · Hotwire · Postgres · Tailwind · DaisyUI · Solid Queue

Questions.

How long until I get an invitation? +

Usually within 48 hours, sometimes same-day. If a week passes, assume the email got lost and ping us again.

Why no public signup? +

Two reasons. We can keep the platform fast because the user count grows on a schedule we control. And we can answer support questions in hours instead of weeks because there's a real person behind every workspace. We'll open up signups when we're confident neither of those things will degrade.

Is there an SLA? +

For invited workspaces, yes — we publish uptime numbers for the platform itself on a status page (yes, we monitor RadarHQ with RadarHQ). The specific SLA terms are part of the invitation conversation.

What about pricing? +

We discuss pricing during the invitation conversation, once we know what you're monitoring and how big your team is. We don't publish a pricing page because we haven't found one that's honest about what teams actually pay. We're working on it.

Can I migrate from Sentry? +

Most teams move incrementally — point new errors at RadarHQ first, leave the old tracker running for a couple weeks, then cut over. Our ingest format is close enough that wrapping existing SDK calls is usually a one-file change. We'll help.

Do you offer self-hosting? +

Not today. It's the most-requested thing we don't do, and we won't pretend it's coming until it is.

What languages do you support? +

Anything that can make an HTTP POST. We have first-party libraries for Ruby and JavaScript today; Python and Go are next. The raw ingest endpoint works from everything.

Where is data stored? +

EU, Frankfurt. Postgres, encrypted at rest, daily backups, no copies sent to third-party analytics services.

Start monitoring in minutes.

The waitlist is short. The product is ready.

Reviewed by a person, usually within 48 hours.