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, or a single all-in-one container), a one-line SDK, or plain OpenTelemetry.
import reqly
reqly.instrument(app, service_name="checkout-api") # FastAPI, Flask, Django, Starlette, Litestar
Live 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 against a weekday × hour baseline, for errors, latency and sudden 401/403/422/429 waves, with the release that was running, root-cause leads ("92% of errors came from pod-7"), the clients that were hit and traces to open; to Slack, Discord, Teams, PagerDuty, Opsgenie, email or webhooks, acknowledged or muted from the dashboard; 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 and model (counted straight from your OpenAI or Anthropic client) with alerts when it spikes
- Any stack, small footprint — Python SDK, Node.js SDK (Express, Fastify, Hono, Koa, NestJS; Cloudflare Workers, Vercel and Next.js with
reqly-node/edge), OTLP from any language, or your reverse proxy's access logs (Caddy, Traefik, Nginx, Envoy); deploy markers from CI with thereqlyCLI or the GitHub Action; the SDKs add ~6–33 µs per request (benchmark) and never crash your app; projects, per-team API keys and sign-in for shared collectors; safe by default, with Prometheus metrics for the collector itself
| 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 | Any OpenAI-compatible API (Groq by default; OpenAI, OpenRouter, Ollama) · gpt-oss-120b (tool calling) · statistics-first anomaly detection |
| Infra | Docker Compose · Helm chart · all-in-one image · Render / Coolify / Railway templates · EC2 (TimescaleDB) · Render · GHCR images · PyPI / npm trusted publishing · CI with ruff, mypy, vitest and an end-to-end test |
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).
Why claim scheduled runs in the database? Every collector runs the scheduler. Each run first inserts its (job, slot) row, and only the one whose insert lands goes ahead, so a rolling deploy or a stray second replica can't send alerts twice or pay for the weekly AI report twice, whatever the timing.
What would you do differently in v2? Design rate limits and the Ask Reqly budget as shared state from the start: they're per process 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.
