Self-hosted API monitoring that tells you what broke, when, and which deploy did it — for Python, Node.js and any OpenTelemetry stack.
Reqly watches every request your APIs serve and explains problems instead of just charting them: when a route starts failing it says which release was running, which host or client the errors came from, and whether you are burning your error budget — and you can ask it why in plain English. It is a lightweight, self-hosted alternative to Datadog-style APMs for teams that want their data on their own Postgres: one docker compose up (or helm install), a one-line SDK, or plain OpenTelemetry.
import reqly
reqly.instrument(app, service_name="checkout-api") # FastAPI, Flask, Django, Starlette, LitestarLive demo → reqly-eventflow-dashboard.onrender.com — metrics from the EventFlow demo app (log in there as
admin@eventhub.com/Admin@123to make some traffic).
- Metrics that are right — p50/p95/p99 per route and per service from mergeable percentile sketches, error rates, status codes, deploy markers and per-release health
- It explains what broke — hourly alerts to Slack/Discord/webhooks against a weekday × hour baseline, with the release that was running, root-cause leads ("92% of errors came from pod-7") and the clients that were hit; a weekly AI report narrates the findings
- Ask Reqly — "why did /orders start failing?" answered from the collector's own data through read-only query tools, with every query shown and any number not found in the results flagged
- API-level depth — SLOs with burn-rate alerts, OpenAPI drift (undocumented, unused and deprecated-but-used endpoints), API consumers, and LLM token cost per route with alerts when it spikes
- Any stack, small footprint — Python SDK, Node.js SDK (Express, Fastify, Hono, Koa, NestJS) or OTLP from any language; the SDKs add ~5–33 µs per request (benchmark) and never crash your app; projects, per-team API keys and sign-in for shared collectors
| Layer | Tech |
|---|---|
| SDKs | Python 3.9+ (pure ASGI/WSGI middleware, httpx) · Node.js 20+ (TypeScript, zero dependencies) · OTLP/HTTP |
| Collector | FastAPI · asyncpg · APScheduler · Pydantic v2 · argon2 |
| Database | TimescaleDB (pg16, Toolkit) · hypertables · continuous aggregates · UddSketch |
| Dashboard | React 19 · Vite · TypeScript · Tailwind CSS 4 · Recharts · TanStack Query |
| AI | Groq API · gpt-oss-120b (tool calling) · statistics-first anomaly detection |
| Infra | Docker Compose · Helm chart · EC2 (TimescaleDB) · Render · GHCR images · PyPI / npm trusted publishing |
Why statistics before the LLM? Anomalies come from a Poisson / z-score test against each route's weekday-hour baseline; the LLM only narrates confirmed findings. Detection stays deterministic and auditable, and nothing is sent to a model when nothing is wrong.
Why mergeable percentile sketches instead of storing p95s? Percentiles can't be averaged. A UddSketch per route-minute merges exactly across routes and time, so a service's 7-day p95 is a real p95 (within ~0.2%), not the max of per-minute p95s that overstated latency.
Why fixed query tools for Ask Reqly, not text-to-SQL? The read key ships in the dashboard, so generated SQL would make it a SQL console. Nine validated, read-only tools return rounded aggregates, and every number in the answer is checked against what they returned.
Why measure SDK overhead? "Zero overhead" was a claim; the benchmark made it a number — and found a Node bug that sent one collector request per app request under steady traffic, plus Python work that could move off the request path (overhead halved).
What would you do differently in v2? Build the alert and SLO evaluation for several collector instances from the start: the scheduler and rate limits assume one instance today, which is fine for self-hosting but caps horizontal scaling.
Using Reqly? Start with the documentation site: quickstart, SDK guides, features, self-hosting and the HTTP API. The documents below are about how Reqly is built.
| Document | Description |
|---|---|
| PRD | Product requirements — goals, user stories, non-goals |
| Architecture | System design, data flow, component breakdown |
| Decisions | Every major technical decision and why |
| Setup | Run the repository locally, env vars |
| Deploy | Production deployment, releases, rollback |
| Benchmarks | SDK overhead per framework and how it's measured |
| Contributing | How to propose changes |
| Changelog | What changed in each release |
| Security | How to report a vulnerability |
| Part | License |
|---|---|
| Collector, dashboard, Helm chart and everything else in this repository | AGPL-3.0 |
Python SDK (sdk/, pip install reqly) |
MIT |
Node.js SDK (sdk-node/, npm install reqly-node) |
MIT |
The SDKs run inside your app, so they're MIT: use them in any project, open or closed. The server is AGPL-3.0: run, modify and self-host it freely; if you offer a modified version as a service, share its source.
