cloudparts

Apitally

API monitoring and analytics added with a few lines of middleware: per-endpoint and per-consumer traffic, errors and latency, plus optional request logs and traces, for Python, Node.js, Go and .NET web frameworks.

What it is
Observability
Used for
Web APIs,Metrics,Alerting
Type
Commercial product
Made by
Apitally
License
Proprietary (the SDKs are MIT)
Facts checked
23 October 2026
Website Source code

What it is

Apitally watches one thing, the HTTP API your application serves, from inside the application. You install its open-source SDK for your framework and call it once at startup, for example apitally.init(app, ...) in FastAPI; it supports Flask, Django REST Framework, Django Ninja, Litestar, Starlette, Express, Fastify, NestJS, Hono, Koa, AdonisJS, Gin, Echo, Fiber, Chi and ASP.NET Core, among others. For each request it records the method, the matched route, the status code, response time and body sizes, aggregates them in memory by endpoint, status code and consumer, and sends the totals to Apitally in the background about once a minute. Telling it who the caller is (a user, an API key, a customer) with set_consumer turns the dashboards into per-customer usage.

On top of the metrics sit request logs (method, URL, status and response headers by default; request and response bodies only if you turn them on), application logs tied to each request, and, since February 2026, traces built on OpenTelemetry spans that show which database query or outbound call made a request slow. Sensitive query parameters, headers and body fields are masked in the SDK before anything leaves the app. Alerts on 14 traffic, error and latency metrics go to Slack, Microsoft Teams or incident.io, and heartbeat and health-check uptime monitors catch an app that stops responding. Aggregated metrics are kept for a year, logs and traces for 15 days, in ClickHouse hosted on DigitalOcean in the US.

Why teams pick it

  • Set up in minutes with one dependency and a call at startup, and dashboards organised around endpoints and API consumers rather than hosts
  • Privacy by default: metrics carry no payloads, bodies and headers are opt-in, and masking happens in your process
  • Metrics are aggregated before sending, so there is no request limit for them and little overhead
  • Open-source SDKs built on OpenTelemetry, which can run alongside an existing OpenTelemetry setup

Watch out for

  • Only sees HTTP APIs built on its supported frameworks; it is not general infrastructure or application monitoring
  • A hosted service with no self-hosted version, and data is stored only in the US
  • Request logs, logs and spans are capped per plan and kept 15 days by default
  • A small, single-founder company, which is a factor for long-term vendor risk

Alternatives

What all observability have in common →Compare side by side →
TreblleCommercialAn API platform that captures every request and response, payloads included, through SDKs or gateway plugins, and builds observability, analytics, documentation, governance and security checks on top of that traffic.

How it fits with other technologies

Add Apitally to a FastAPI app and name the consumer · python

# pip install "apitally[fastapi]"
from typing import Annotated

import apitally
from fastapi import Depends, FastAPI


def identify_consumer(current_user: Annotated[User, Depends(get_current_user)]) -> None:
    apitally.set_consumer(current_user.user_id, name=current_user.name)


app = FastAPI(dependencies=[Depends(identify_consumer)])
apitally.init(app, write_token="your-write-token", env="prod")

See it in a real stack

No architecture uses Apitally yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

WebsiteOpenAPI.ToolsPhil Sturgeon and APIs You Won’t Hate, with community contributorsAn open-source directory of more than 300 tools for working with OpenAPI descriptions, sorted into 23 categories such as mock servers (about 25, including Prism, Microcks, WireMock and Specmatic), SDK generators, linters, documentation, gateways, testing and monitoring, and filterable by language and by which OpenAPI versions each supports. Entries arrive by pull request on GitHub; sponsors get priority placement and a badge in their categories, so the order isn’t a ranking.
All resources →
Where it came from2023–2026

Simon Gurcke, a software engineer from Germany living in Australia, was responsible for several API products at a health-tech company and found Datadog and the ELK stack too complex for questions about an API: who calls which endpoint, how often, and with what errors. In 2023 he started Apitally to “scratch my own itch”, beginning with a Python SDK for FastAPI and Starlette.

He kept the design small and privacy-conscious, which mattered in healthcare: SDKs aggregate metrics on the client, “similar to Prometheus”, and by default capture no sensitive data. A Show HN post in February 2025 described it as a bootstrapped indie product with SDKs for Python and Node.js; Go and .NET followed that year.

Apitally then added request logs, application logs and, in February 2026, tracing based on OpenTelemetry. Version 1.0 of the Python SDK arrived in October 2026. Gurcke runs it solo and says he has no plans to raise venture capital.

Why it’s built this way

Aggregate in the client
Counting requests in memory and sending totals once a minute keeps overhead low and means no request data has to leave the app just to draw charts.
Consumers as a first-class dimension
For an API business the key questions are about callers, so the SDK lets you attach a consumer to each request and slices every chart by it.
Open-source SDKs, hosted backend
The part that runs inside your app can be read and audited; the dashboards and storage stay a paid service.

Timeline

  1. 2023

    Apitally started; first Python SDK release in July

  2. 2023

    JavaScript SDK repository created in November

  3. 2025

    Show HN in February; Go and .NET SDKs added

  4. 2026

    Tracing on OpenTelemetry in February; Python SDK 1.0 in October

Sources7 · facts checked 23 October 2026

Improve this page on GitHub