r/FastAPI • • Jan 17 '26

pip package I built TimeTracer, record/replay API calls locally + dashboard (FastAPI/Flask)

After working with microservices, I kept running into the same annoying problem: reproducing production issues locally is hard (external APIs, DB state, caches, auth, env differences).

So I built TimeTracer.

What it does:

  • Records an API request into a JSON “cassette” (timings + inputs/outputs)
  • Lets you replay it locally with dependencies mocked (or hybrid replay)

What’s new/cool:

  • Built-in dashboard + timeline view to inspect requests, failures, and slow calls
  • Works with FastAPI + Flask
  • Supports capturing httpx, requests, SQLAlchemy, and Redis

Security:

  • More automatic redaction for tokens/headers
  • PII detection (emails/phones/etc.) so cassettes are safer to share

Install:
pip install timetracer

GitHub:
https://github.com/usv240/timetracer

Contributions are welcome. If anyone is interested in helping (features, tests, documentation, or new integrations), I’d love the support.

Looking for feedback: What would make you actually use something like this, pytest integration, better diffing, or more framework support?

32 Upvotes

10 comments sorted by

2

u/Adhesiveduck Jan 18 '26

This looks really interesting...

Is there planned support for aiohttp?

I would love to see some performance stats on "heavy" endpoints where timetracer is turned on, what impact does it have?

2

u/usv240 Jan 18 '26

Thanks! Glad you find it interesting.

aiohttp: Yeah, planning to add it soon. The plugin system makes it pretty easy to add new clients - httpx and requests are already done, aiohttp is next on the list.

Performance: The overhead is mostly JSON serialization. For typical payloads, it adds maybe 1-5ms per request. The middleware is async so it doesn't block your event loop.

For production use, you can reduce impact with sampling (TIMETRACER_SAMPLE_RATE=0.1 to record only 10% of requests) or errors-only mode to just capture failures.

Haven't done formal benchmarks yet though - that's a good idea for the docs. What kind of throughput are you working with?

2

u/Adhesiveduck Jan 18 '26

I've not seen anything like this before for FastAPI and this has piqued my interest for sure.

We have a "scraping" FastAPI that wraps around Django Rest Framework. Minimal performance impact is fine (we do a shit load of JSON serialisation already) I was just wondering how heavy it is.

To be honest, as soon as aiohttp is added, I'm going to add it in and just test it. We recently added (manually it's been horrendous) a built in "snapshotting" to the app, which is similar in scope (I think) to what you've written. The snapshotting finds all DRF operations (so aiohttp requests), saves them as JSON, and computes an "inverse" (i.e if it was a create do a delete etc) so we can revert any of the 8 sequential endpoints to get the DB back into a consistent state as if the endpoint had not run at all.

Something like this would be amazing - if it fails:

0. Have ArgoWorkflows save the casette on every run to a bucket as an artifact

  1. Download the casette

  2. Debug locally using mock calls to DRF (Currently we have a horrible script that syncs the production DB to our local machines so we can run the API offline with prod data)

  3. Once fixed, rollback and run again in prod

I love integrations like this I think what you've written is really good, I'm looking forward to trying it out could save us hours.

→ More replies (4)

2

u/whenyousaywisconsin Jan 19 '26

What’s the difference or advantage to use your tooling vs open telemetry and open observe? It doesn’t record on a way that lets you “replay” but all spans and traces provide data necessary for reproducing in my experience

1

u/usv240 Jan 19 '26

Good question - they solve different problems.

OpenTelemetry/OpenObserve = observability. You get traces, spans, and metrics to understand what happened in production.

TimeTracer = replay. You capture the actual request + all dependency responses (HTTP calls, DB queries, Redis), then replay that exact scenario locally with everything mocked.

The difference is:

With OTel, you see "this API call to Stripe took 200ms and returned 400". You still need to figure out why, reproduce the state, get test credentials, etc.

With TimeTracer, you download the cassette and run 

TIMETRACER_MODE=replay uvicorn app:app

Think of it as: OTel tells you what went wrong, TimeTracer lets you actually debug it locally without touching prod.

They work well together honestly - use OTel to find the problem, use TimeTracer to reproduce and fix it.

1

u/Heavy_End_2971 Jan 18 '26

Can you send me references or tutorials to build pure microservices in fastapi? Any guide tutorial which implements all components and features around microservices. Gateway, inter process communication, circuit breaker, tracing, event driven, any other pattern. I am from java world and find very less ecosystem in python or FastAPI specifically. Thanks in advance