Open-source application monitoring

Know where your API breaks.

InflowAPM turns request telemetry into clear answers about errors, latency, P95, throughput, and route performance. Find what changed before your users have to explain it.

Start monitoring ArchitectureView architecture GitHub

Async ingestion
Project-scoped telemetry
PostgreSQL analytics

checkout-api

Demo workspace · illustrative

Last 15 minLive

Requests

2,481 / min

Error rate

1.7 %

P95 latency

842 ms

Throughput

41.3 req/s

Request volume

Requests accepted per minute

15 min window

MethodRouteStatusP95

POSTPOST/checkout5001.24s

GETGET/api/products200128ms

Updated 18:42:17 UTCProject-scoped telemetry

The production problem

Production tells you something broke. It rarely tells you where.

A healthy route can become slow, then fail, in minutes. Without the telemetry between those moments, the first useful signal often arrives from an affected user.

Incident progression

checkout-api · production

Degraded

14:31:08POST /checkoutP95312 ms
14:32:41POST /checkoutP95847 ms
14:33:09POST /checkoutHTTP500
14:33:14POST /checkoutHTTP500

From signal to visibility

Follow telemetry from your application to the route that needs attention.

InflowAPM accepts small event batches quickly, processes them outside the request path, and turns stored telemetry into route, latency, and error visibility.

Source

Your application

Requests, errors, and latency

HTTP telemetry

Ingest

InflowAPM

Authenticated event batches

202 Accepted

Process

BullMQ worker

Asynchronous processing

Retry + backoff

Analyze

PostgreSQL

Project-scoped telemetry

Windowed queries

Understand

Route visibility

Latency, errors, throughput

Find the failing route

Authentication: Project API key
Batch limit: 1 to 100 events
Queue: BullMQ
Analytics: PostgreSQL

From visibility to investigation

Move from a degraded signal to the route and error behind it.

Start with application health, narrow the time window, compare route performance, then inspect the latest server failure. Every step uses telemetry the backend already records.

checkout-api · incident review

Demo workspace · illustrative

Last 15 minIncident detected

P95 latency

842 ms

↑ 174%

Error rate

4.7 %

↑ 3.0 pts

Started

14:32:41 UTC

Within selected range

When did it start?

P95 latency · five-minute view

14:3014:32 onset14:35

Recent server error

Most recent in selected range

POST /checkout500

Payment provider timeout

14:33:14 UTC1.24s

Error context is read from the event metadata attached by the producing application.

Which route is affected?

Route performance · last 15 min

Route	Requests	Errors	P95
POST/checkout	486	40	1.24s
GET/api/products	1,242	0	128ms
GET/api/cart	753	2	214ms

Inspect next

Checkout handler → payment-provider call path

Evidence, not guesswork

Node.js SDK

Instrument once. Observe every stage.

Add bounded, fail-open telemetry to Express without putting network delivery on the application request path.

Node.jsPython · Coming soon

01Install
02Configure
03Instrument
04Run
05Observe

Install

Available on npm

npm install @inflowapm/node

Install the public package from npm, then configure a project key and your InflowAPM endpoint.

.env

INFLOWAPM_API_KEY=iapm_project_key
INFLOWAPM_ENDPOINT=http://127.0.0.1:5002
INFLOWAPM_SERVICE=checkout-api
INFLOWAPM_ENVIRONMENT=development
INFLOWAPM_SERVICE_VERSION=1.4.0

server.js

import express from "express";
import { InflowAPM } from "@inflowapm/node";

const app = express();
const inflow = new InflowAPM({
  apiKey: process.env.INFLOWAPM_API_KEY,
  endpoint: process.env.INFLOWAPM_ENDPOINT,
  service: process.env.INFLOWAPM_SERVICE,
  environment: process.env.INFLOWAPM_ENVIRONMENT,
  serviceVersion: process.env.INFLOWAPM_SERVICE_VERSION ?? "1.4.0",
});

app.use(inflow.express());
app.get("/health", (_request, response) => response.send("ok"));

One integration, explicit environments

Development

development

Staging

staging

Production

production

@inflowapm/node

checkout-api → InflowAPM

Request path

Browser or Postman → Express middleware → route handler → response

POST /checkout · 500 · 1,240 ms

Postman sends the request. InflowAPM explains what happened after your application received it.

Telemetry path

Middleware → bounded memory buffer → background batch → InflowAPM API

Delivery retries transient failures with backoff. Instrumentation failures stay fail-open so they do not replace your application response.

Project key required

Read the full setup, configuration, privacy, reliability, and self-hosting reference before deploying the SDK.

Read Node.js SDK docs

Integrate on open foundations

Send real telemetry. Inspect every layer behind it.

Use the supported HTTP ingestion API today. The source, processing pipeline, storage model, and analytics queries remain open for you to inspect and run locally.

Direct HTTP ingestion

Supported today · no SDK required

POST · 202

curl -X POST http://localhost:5002/api/v1/telemetry/ingest \
  -H "Authorization: Bearer $INFLOWAPM_PROJECT_KEY" \
  -H "Content-Type: application/json" \
  -d '[{
    "type": "http",
    "route": "/checkout",
    "method": "POST",
    "status": 500,
    "duration_ms": 1240,
    "metadata": {
      "error_message": "Payment provider timeout"
    },
    "occurred_at": "2026-09-10T14:33:14.000Z"
  }]'

Built as a full system

Compact technology view

Interface: Next.js · React · TypeScript; Public experience and planned dashboard
API: Node.js · Express; Authentication, projects, ingestion, analytics
Data: PostgreSQL · Redis · BullMQ; Telemetry storage, caching, and async work
Runtime: Docker Compose; Reproducible local API infrastructure

Open source by design

Read the implementation, run it locally, or help shape what comes next.

InflowAPM exposes the same architecture described here: an Express API, asynchronous telemetry processing, PostgreSQL analytics, and a Next.js product experience.

View source on GitHub

Ready when you are

Investigate the route before your users have to report it.

Start monitoring GitHub Read architecture