Forem: Ujwal Vanjare

Scaling Astrolord: Our Journey with Serverless on AWS

Ujwal Vanjare — Wed, 04 Feb 2026 03:23:53 +0000

When we started building Astrolord, we knew we had a tricky engineering problem on our hands. We were building an AI-powered astrology platform that needed to perform heavy astronomical calculations one second and stream personalized AI responses the next. We needed infrastructure that could handle a sudden spike in traffic, like during a major planetary transit, without burning a hole in our pocket during quiet hours.

We decided early on to go all-in on AWS Serverless. It wasn't just about avoiding server management; it was about building an architecture that could scale to zero when no one was using it, and scale up infinitely when they were. Here is a look at how we pieced it all together.

The Compute Layer: AWS Serverless

The heart of our backend is Python. The challenge was deploying our application in a way that didn't require maintaining a fleet of servers or paying for idle time.

We chose AWS Lambda for its efficiency. By adapting our web application to run in a serverless environment, we can write modern, clean code while letting AWS handle the underlying infrastructure.

There were trade-offs, of course. We had to be careful with "cold starts", the initial delay when a function wakes up. We spent time optimizing our application startup to keep latency minimal. But the benefit of paying literally zero dollars when no traffic is hitting the API made it an easy choice.

The Front Door: API Gateway

Sitting in front of those Lambda functions is Amazon API Gateway. Connective tissue is often overlooked, but for us, this piece is critical. It acts as our secure entry point, routing requests to the correct backend services.

Beyond just routing, we rely on it for stability. We configured usage plans and throttling rules directly at the gateway level. This means if a bad actor tries to hammer our API, AWS blocks them before they even wake up our compute layer, saving us money and processing power.

Delivering the UI: S3 and CloudFront

For the frontend, we built a static React application. We didn't want to run a web server or manage containers just to serve HTML and JavaScript files.

Instead, we use what I consider the "gold standard" for static hosting: Amazon S3 paired with CloudFront. We upload our build artifacts into an S3 bucket, which offers incredible durability. Then, CloudFront sits in front of that bucket, caching our application at edge locations all over the world.

The result is that a user in Mumbai loads the app just as fast as a user in New York. We also configured strict security controls, ensuring that no one can bypass the CDN to hit our bucket directly.

Observability

One thing they don't tell you about distributed systems is that debugging can be a nightmare if you aren't prepared. Since we don't have a single server to SSH into, we rely heavily on centralized logging and monitoring.

We capture all standard output from our functions into CloudWatch Logs. We also set up specific metric filters to track errors and throttling events. If our error rate crosses a certain threshold, an alarm triggers and we get notified immediately. It gives us the confidence to deploy on a Friday (well, almost).

The Economics of Serverless

One of the biggest wins for us wasn't just technical, it was financial.

With a traditional EC2 or container-based architecture, you are paying for capacity 24/7. Even if no one visits your site at 3 AM, that server is still running, and you are still receiving a bill.

With this serverless setup, our infrastructure cost aligns perfectly with our business growth.

Zero Idle Costs: When our app is quiet, our compute bill is literally $0.
Generous Free Tier: AWS offers a substantial free tier for Lambda and API Gateway, meaning we effectively run our development and testing environments for free.
No Over-Provisioning: We never have to guess how many servers we need. The system just scales to meet demand, whether that's 5 users or 5,000.

Why This Architecture Works for Us

Usage patterns in our app are unpredictable. Some days are quiet; other days, everyone wants to know what the full moon means for them.

This serverless architecture on AWS absorbs that volatility perfectly. We don't have to provision for peak capacity and pay for idle time. We just pay for the milliseconds of compute we actually use. It has allowed us to focus less on "keeping the lights on" and more on improving the actual product.

Time-Travel Debugging for Python: A Complete Tutorial

Ujwal Vanjare — Fri, 23 Jan 2026 05:10:45 +0000

Time-Travel Debugging for Python: A Complete Tutorial

Building web applications means dealing with external APIs, databases, and the inevitable production bugs. I'm going to show you how to capture production issues and debug them locally without ever hitting those external services again.

This is a complete walkthrough using Timetracer with a Starlette application. By the end, you'll have a working example and understand how to apply this to your own projects.

Note: If you're new to Timetracer, you might want to check out my initial post about why I built this tool, or the v1.4 release post covering Django and pytest integration.

This tutorial focuses specifically on Starlette integration and shows the complete debugging workflow with the new v1.6.0 dashboard features.

The Problem

You know that moment when a bug happens in production? You spend hours trying to reproduce it locally. You're making API calls to third-party services, dealing with rate limits, stale data, and that nagging feeling you're not testing the exact scenario that failed.

Traditional debugging flow:

Bug reported in production
Try to reproduce locally (often fails)
Add logging and redeploy (slow)
Hope you captured enough context (usually didn't)
Repeat until fixed (hours or days)

There's a better way. With Timetracer, you capture the entire request context in production and replay it locally. Think of it as a flight recorder for your web application.

Setting Up the Project

Let's build a simple API that proxies GitHub user data. First, install the dependencies:

pip install starlette uvicorn httpx timetracer

Create a file called app.py:

from starlette.applications import Starlette
from starlette.routing import Route
from starlette.responses import JSONResponse
import httpx

async def homepage(request):
    return JSONResponse({
        "message": "Welcome to the Starlette + Timetracer example",
        "endpoints": ["/", "/user/{username}", "/repos/{username}"]
    })

async def get_user(request):
    username = request.path_params["username"]
    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.github.com/users/{username}")
        return JSONResponse(response.json())

async def get_repos(request):
    username = request.path_params["username"]
    async with httpx.AsyncClient() as client:
        user_resp = await client.get(f"https://api.github.com/users/{username}")
        user_data = user_resp.json()

        repos_resp = await client.get(f"https://api.github.com/users/{username}/repos")
        repos = repos_resp.json()

    return JSONResponse({
        "username": username,
        "total_repos": user_data["public_repos"],
        "top_repos": [{"name": r["name"], "stars": r["stargazers_count"]} 
                      for r in sorted(repos, key=lambda x: x["stargazers_count"], reverse=True)[:5]]
    })

app = Starlette(debug=True, routes=[
    Route("/", homepage),
    Route("/user/{username}", get_user),
    Route("/repos/{username}", get_repos),
])

This gives us three endpoints: a homepage, a user lookup, and a repo list. The last two hit the GitHub API.

The Starlette application with three endpoints

Integrating Timetracer

Now add Timetracer. Import the integration and call auto_setup():

from timetracer.integrations.starlette import auto_setup

# ... your routes ...

app = Starlette(debug=True, routes=[
    Route("/", homepage),
    Route("/user/{username}", get_user),
    Route("/repos/{username}", get_repos),
])

# This is the only line you need for Timetracer
auto_setup(app, plugins=["httpx"])

That's it. One line of code. This adds middleware that captures every request and tracks all httpx calls to external APIs.

Recording Requests

Start the server in record mode:

export TIMETRACER_MODE=record
uvicorn app:app --reload

Your terminal should show Timetracer capturing requests:

Terminal output showing Timetracer recording requests with timing information

Now let's make some requests and see what gets captured.

Request 1: Homepage

curl http://localhost:8000/

Response:

{
  "message": "Welcome to the Starlette + Timetracer example",
  "endpoints": ["/", "/user/{username}", "/repos/{username}"]
}

Browser showing the homepage JSON response

Terminal output:

timetracer [OK] recorded GET /  id=cddb  status=200  total=9ms  deps=none
  cassette: cassettes/2026-01-23/GET__root__cddb6be9.json

Notice deps=none because this endpoint doesn't make any external calls.

Request 2: User Lookup

curl http://localhost:8000/user/octocat

Response:

{
  "login": "octocat",
  "name": "The Octocat",
  "bio": null,
  "public_repos": 8,
  "followers": 21594
}

GitHub user data returned through our API

Terminal output:

timetracer [OK] recorded GET /user/octocat  id=88d7  status=200  total=472ms  deps=http.client:1
  cassette: cassettes/2026-01-23/GET__user_octocat__88d76871.json

This time deps=http.client:1 shows one external HTTP call was tracked. The duration is 472ms instead of 9ms because we're waiting for GitHub's API.

Request 3: Repository List

curl http://localhost:8000/repos/octocat

Top repositories for the octocat user

This endpoint makes two GitHub API calls: one for the user data and one for the repository list.

What Got Saved?

Each cassette is a JSON file containing your request, response, and all external dependencies with timing information.

Cassette file showing the captured request, response, and external API calls

The cassette includes:

Request details (method, path, headers, body)
Response details (status, headers, body, duration)
All external dependencies (each GitHub API call with its own timing)
Metadata about the session (framework, timestamp, etc.)

Using the Dashboard

Now for the interactive part. Timetracer includes a web dashboard to browse and analyze your captured requests.

Start the dashboard server:

timetracer serve --dir cassettes --port 3000

Open http://localhost:3000 in your browser:

Dashboard showing all captured requests with statistics

The dashboard shows:

Total requests, success count, error count
Every captured request with method, path, status, duration, and dependencies
Search and filter capabilities
View details or replay any request

Viewing Request Details

Click "View" on the /repos/octocat request:

Detailed view showing request, response, and external API dependencies

The detail view shows:

Request metadata: Path, method, timestamp
Response: Status 200, duration 524ms
Dependency Events: Both GitHub API calls with individual timings
- GET https://api.github.com/users/torvalds (104ms)
- GET https://api.github.com/users/torvalds/repos (95ms)
Ready-to-use replay command

This view tells you exactly what happened during the request, including all external services that were called.

Filtering Requests

Type "repos" in the search box:

Dashboard filtered to show only repository-related requests

The dashboard now shows "Showing 5 of 19 cassettes" with only the matching requests visible.

You can also filter by HTTP method or status code to focus on specific types of requests.

Inspecting the Raw Data

For technical inspection, the dashboard includes a Raw JSON viewer:

Raw JSON view showing the complete cassette structure

This gives you direct access to the underlying cassette data, making it easy to verify exactly what state is being captured and will be replayed.

Debugging a Real Bug

Now let's use Timetracer for what it's really good at: debugging production issues without touching production.

The Bug Appears

Imagine a user reports that requesting a non-existent GitHub user crashes the server with a 500 error. The problematic code:

async def get_user(request):
    username = request.path_params["username"]
    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.github.com/users/{username}")
        return JSONResponse(response.json())  # Crashes on 404

When someone requests a user that doesn't exist, GitHub returns 404, but our code assumes success and tries to parse the error response.

Even though the app crashes, Timetracer still captures the request:

timetracer [ERROR] recorded GET /user/nonexistent-user-12345  id=bad1  status=500  total=156ms  deps=http.client:1
  cassette: cassettes/2026-01-23/GET__user_nonexistent-user-12345__bad1234.json

Inspecting the Error

In the dashboard, click "View" on the failed request:

Dashboard detail view showing a 404 error from GitHub API

The detail view clearly shows that GitHub returned a 404, which propagated to our endpoint as a 500 error. You can see exactly what happened: the external API call failed, and our code didn't handle it properly.

The Fix

Looking at the dashboard detail view, you can see GitHub returned 404. Fix the code:

async def get_user(request):
    username = request.path_params["username"]

    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.github.com/users/{username}")

        # Check status code before parsing
        if response.status_code == 404:
            return JSONResponse(
                {"error": "User not found"},
                status_code=404
            )

        return JSONResponse(response.json())

Getting the Replay Command

The dashboard provides a ready-to-copy replay command:

Ready-to-use replay command for testing the fix

Just copy this command to test your fix with the exact scenario that failed in production.

Testing the Fix Without Network

This is where Timetracer shows its real value. You can test the fix using the captured cassette without making any real API calls to GitHub.

Stop the server and restart in replay mode:

export TIMETRACER_MODE=replay
export TIMETRACER_CASSETTE=cassettes/2026-01-23/GET__user_nonexistent-user-12345__bad1234.json
uvicorn app:app --reload

Server running in replay mode with mocked external API responses

Make the same request:

curl http://localhost:8000/user/nonexistent-user-12345

Terminal shows:

timetracer replay GET /user/nonexistent-user-12345  mocked=1  matched=OK  runtime=5ms

Response:

{
  "error": "User not found"
}

Status: 404

The fix works. Notice:

No network call - the response came from the cassette
Fast: 5ms instead of the original 156ms
Exact scenario: Same 404 from GitHub that caused the original crash
Offline: This works with no internet connection

You just debugged and fixed a production bug without touching production or making a single external API call.

Performance Comparison

Let's compare the timing differences:

Record Mode vs Replay Mode

Endpoint	Record Duration	Replay Duration	Speedup
`/`	9ms	8ms	1.1x
`/user/octocat`	472ms	8ms	59x faster
`/repos/octocat`	524ms	10ms	52x faster

Comparison of request durations in record mode versus replay mode

For endpoints without external calls, the times are similar. But anything that touches an external API or database becomes dramatically faster in replay mode.

This isn't just about speed. It's about reliability. Tests that depend on external APIs can be flaky due to network issues, rate limiting, or changing data. Replay mode eliminates all those problems.

When to Use This

I've found Timetracer most useful in these scenarios:

1. Debugging Production Bugs

When a user reports an issue, capture the failing request in production. Download the cassette and debug locally with the exact same conditions. No need to reproduce complex scenarios or guess at what data caused the problem.

2. Integration Testing

Tests that hit real APIs are slow and unreliable. Record your test scenarios once, then replay them. Tests run in milliseconds instead of seconds, and they never fail due to network issues or rate limiting.

3. Offline Development

Working on a plane or anywhere without internet? Load up cassettes with the API responses you need. Everything works normally without network access.

4. Performance Analysis

The dashboard shows you exactly how long each external dependency takes. If your endpoint is slow, you can see whether it's your code or a slow external API.

5. Preventing Regressions

When you fix a bug, keep the cassette and add it to your test suite. That specific scenario is now covered forever.

Framework Support

Timetracer works with:

Supported web frameworks and external service integrations

Web Frameworks:

FastAPI
Starlette (new in v1.6.0)
Flask
Django

External Services:

httpx and requests (HTTP clients)
Motor and PyMongo (MongoDB)
SQLAlchemy (SQL databases)
Redis

The integration is similar across all frameworks. Usually just auto_setup(app) or adding middleware.

Trade-offs to Consider

Storage: Each cassette is a JSON file. If you have many unique requests, you'll accumulate files. Clean up old cassettes periodically or store them in S3.

Sensitive data: Cassettes contain your actual request and response data. Review what's being captured, especially in production. Timetracer has built-in redaction for common sensitive fields like passwords and tokens, but verify this for your use case.

Cassette maintenance: API responses change over time. You'll need to re-record cassettes when your external dependencies change their response format.

Not a replacement: This isn't trying to replace your testing framework or mocking library. It's a debugging tool that captures production context and lets you work with it locally.

Getting Started

Install Timetracer:

# For Starlette
pip install timetracer[starlette]

# For FastAPI
pip install timetracer[fastapi]

Integrate into your app:

from timetracer.integrations.starlette import auto_setup
auto_setup(app, plugins=["httpx"])

Run in record mode:

export TIMETRACER_MODE=record
uvicorn app:app

View the dashboard:

timetracer serve --dir cassettes --port 3000

Test in replay mode:

export TIMETRACER_MODE=replay
export TIMETRACER_CASSETTE=path/to/cassette.json
uvicorn app:app

Conclusion

The workflow I showed here - capturing a failing production request, viewing it in the dashboard, fixing the bug, and testing the fix in replay mode - saves hours compared to traditional debugging.

Instead of:

Trying to reproduce the bug
Adding logging
Redeploying
Hoping you captured enough context
Repeating until fixed

You can:

Download the cassette
View it in the dashboard
Fix the code
Verify the fix in replay mode
Deploy with confidence

The complete example code is on GitHub at github.com/usv240/timetracer. All 174 tests are passing, and version 1.6.0 just added Starlette support and PyMongo integration.

If you work with external APIs, spend time debugging production issues, or want faster integration tests, give it a try.

Resources

GitHub: https://github.com/usv240/timetracer
PyPI: https://pypi.org/project/timetracer
Documentation: GitHub README
Example code: See examples/starlette_example/ in the repo

Tags: #python #starlette #fastapi #debugging #testing #devtools

Timetracer v1.4: Native Django Support and Easiest pytest Integration

Ujwal Vanjare — Mon, 19 Jan 2026 18:32:01 +0000

A few weeks ago, I introduced Timetracer in my previous post: "I Got Tired of 'It Works on My Machine' So I Built a Time-Travel Debugger".

The tool allows you to record API interactions (including dependencies like databases and external APIs) and replay them locally to debug production issues.

The initial version focused on FastAPI and Flask. However, the most frequent feedback I received was the need for Django support and better integration with pytest suites.

I just released v1.4.0, which adds both.

Here is why this matters and how it works.

Why This Matters

1. No More "Enterprise Setup" Pain

Django is often used for large, mature applications. These apps tend to have complex dependencies, specific database states, VPN-locked APIs, or legacy SOAP services that are a pain to run locally.

With Timetracer's new middleware, you can record a session from a staging environment (or a colleague's machine that actually works) and replay it on your machine. You get the full app behavior without needing the full enterprise infrastructure running on localhost.

2. Tests That Don't Lie

We've all written tests with unittest.mock where we guess what the API returns. Then the API changes, our mock stays the same, the test passes, but production breaks.

The new pytest integration replaces brittle mocks with real, recorded interactions. Your tests run against actual data snapshots, making them far more reliable than manual mocks.

Django Support

Timetracer now includes middleware that works with Django 3.2 LTS and newer. It supports both standard synchronous views and the newer async views in Django 4.1+.

The integration captures:

Incoming HTTP requests
Outbound API calls (requests, httpx, aiohttp)
Database queries (via SQLAlchemy for now, native ORM soon)
Redis operations

Setting it up

First, install the package with Django dependencies:

pip install timetracer[django,requests]

Then add the middleware in your settings.py. It usually works best near the top of the list so it can capture everything:

# settings.py

MIDDLEWARE = [
    'timetracer.integrations.django.TimeTracerMiddleware',
    # ... other middleware
]

# Optional configuration
TIMETRACER = {
    'MODE': 'record',  # 'record', 'replay', or 'off'
    'CASSETTE_DIR': './cassettes',
}

If your app makes external API calls, you should enable the plugins in your AppConfig or settings.py:

# myapp/apps.py or settings.py
from timetracer.integrations.django import auto_setup

# Enable recording for the requests library
auto_setup(plugins=['requests'])

Workflow

Run your server: python manage.py runserver
Browse your site. Timetracer saves JSON "cassettes" for each request.
To debug a specific request later, restart with TIMETRACER_MODE=replay.
The server will now mock all external calls using the recorded data.

pytest Integration

Previously, using recorded cassettes in tests required manual setup. v1.4.0 adds a pytest plugin that automatically registers fixtures when you install the package.

This allows you to write integration tests that don't need live external APIs but still exercise your full stack.

Using the Fixtures

The plugin provides three main fixtures:

1. timetracer_replay
Use this to run a test against a pre-recorded session. It guarantees the test runs exactly the same way every time.

def test_user_profile(timetracer_replay, client):
    # 'user_profile.json' contains the recorded interaction
    with timetracer_replay("cassettes/user_profile.json"):
        response = client.get("/api/users/123")
        assert response.status_code == 200
        assert response.json()['username'] == 'testuser'

2. timetracer_record
Use this when writing a new test case. It captures the interaction so you can save it as a cassette.

def test_new_feature(timetracer_record, client):
    # This will execute real network calls and save the result
    with timetracer_record("cassettes/new_feature.json"):
        response = client.get("/api/new-feature")
        assert response.status_code == 200

3. timetracer_auto
This is useful for TDD. If the cassette doesn't exist, it records. If it does exist, it replays.

def test_checkout_flow(timetracer_auto, client):
    # Records first time, replays subsequently
    with timetracer_auto("cassettes/checkout.json"):
        response = client.post("/api/checkout", {'cart_id': 'abc'})
        assert response.status_code == 200

Async Support (aiohttp)

We also added a plugin for aiohttp. Building high-concurrency apps often requires async HTTP clients, and aiohttp is a popular choice alongside httpx.

Timetracer now correctly intercepts and records aiohttp.ClientSession requests, capturing the full async flow.

What's Next

The goal remains effective local debugging. If you are using Django or pytest, I'd appreciate you trying this out and letting me know if it helps simplify your debugging workflow.

Repositories and Docs:

GitHub: https://github.com/usv240/timetracer
PyPI: pip install timetracer

I Got Tired of "It Works on My Machine" So I Built a Time-Travel Debugger

Ujwal Vanjare — Sun, 18 Jan 2026 06:17:35 +0000

Last year, I spent three hours debugging a checkout bug that only happened in production. The external payment API was returning a slightly different response format than what we saw in staging. By the time I figured it out, I'd burned half my day and my patience.

That was the last straw.

I started building Timetracer that weekend. Now, when something breaks in production, I can capture the exact request, complete with every external API call, database query, and cache operation, and replay it on my laptop. No more guessing. No more "can you add some logging and redeploy?"

This post is about why I built it, how it works, and why you might want to use it too.

The Debugging Problem Nobody Talks About

Here's a scenario you've probably lived through:

A customer reports that their order failed. You check the logs. You see the error. You try to reproduce it locally. But your local setup hits a different database, a sandbox payment API, and your Redis is empty. The bug doesn't happen.

You add more logging. Redeploy. Wait for it to happen again. Check the new logs. Still can't reproduce it. Repeat.

Or maybe you're working on a feature that integrates with a third-party API, but that API is rate-limited, or requires special credentials, or just goes down at random times. Every time you run your code, you're making real API calls. Testing becomes painful.

Or you're trying to demo something to your team, but the staging environment is down. Or slow. Or someone else is testing migrations on it.

These problems have something in common: your code depends on things outside your control, and that makes debugging and development unpredictable.

What If You Could Record Everything?

The idea behind Timetracer is simple: when your API handles a request, record everything that happens. Not just the request and response, but every external call your code makes.

That HTTP call to Stripe? Recorded.
That SELECT query to Postgres? Recorded.
That Redis GET? Recorded.

All of it goes into a JSON file we call a "cassette" (borrowing the term from VCR.py, which does something similar but only for HTTP).

Later, when you want to debug, you load that cassette and replay the request. Timetracer intercepts all the external calls and returns the recorded responses instead of making real ones.

Same input. Same external responses. Same bug. But now it's on your laptop, where you can step through the code, add breakpoints, and actually figure out what went wrong.

How It Actually Works

Let's get into the technical stuff.

Setup

If you're using FastAPI, adding Timetracer is two lines:

from fastapi import FastAPI
from timetracer.integrations.fastapi import auto_setup

app = auto_setup(FastAPI())

That's it. The auto_setup function adds middleware that handles recording and replaying.

For Flask, it's similar:

from flask import Flask
from timetracer.integrations.flask import auto_setup

app = auto_setup(Flask(__name__))

You control the behavior with environment variables:

# Record mode - captures everything
export TIMETRACER_MODE=record
export TIMETRACER_DIR=./cassettes

python app.py

Now make some requests to your app. Each request creates a cassette file.

What's In a Cassette?

Here's a simplified version of what gets saved:

{
  "request": {
    "method": "POST",
    "path": "/checkout",
    "body": {"cart_id": "abc123", "user_id": "user_456"}
  },
  "response": {
    "status": 200,
    "body": {"order_id": "order_789"},
    "duration_ms": 342
  },
  "events": [
    {
      "type": "http.client",
      "method": "POST",
      "url": "https://api.stripe.com/v1/charges",
      "request_body": {"amount": 2999, "currency": "usd"},
      "response_body": {"id": "ch_xxx", "status": "succeeded"},
      "duration_ms": 187
    },
    {
      "type": "db.query",
      "query": "INSERT INTO orders (user_id, total) VALUES (?, ?)",
      "params": ["user_456", 29.99],
      "duration_ms": 12
    }
  ]
}

Everything is there. The incoming request, the outgoing response, and every dependency call in between.

Replaying

To replay, point Timetracer at the cassette:

export TIMETRACER_MODE=replay
export TIMETRACER_CASSETTE=./cassettes/checkout_abc123.json

python app.py

Now when you hit /checkout with the same request, Timetracer intercepts the Stripe call and the database query. Instead of making real calls, it returns the recorded responses.

Your code runs exactly as it did in production, but locally, without needing Stripe credentials or a production database.

The Plugins

Recording HTTP calls is useful, but real applications do more than HTTP. That's why Timetracer has plugins for common dependencies.

HTTP Clients

We support both httpx (async and sync) and the requests library:

from timetracer.plugins import enable_httpx, enable_requests

enable_httpx()    # For httpx calls
enable_requests() # For requests library calls

Databases

SQLAlchemy queries get captured with their SQL and parameters:

from timetracer.plugins import enable_sqlalchemy

engine = create_engine("postgresql://...")
enable_sqlalchemy(engine)

Caching

Redis commands are recorded too:

from timetracer.plugins import enable_redis

enable_redis()

When you replay, all of these return the recorded values. No real database connections. No real Redis. No real HTTP calls. Just the data from the cassette.

The Dashboard

After using Timetracer for a few weeks, I got tired of opening JSON files to find the cassette I needed. So I built a dashboard.

timetracer serve --dir ./cassettes --open

This starts a local web server with a table of all your cassettes. You can:

Sort by time, method, status, or duration
Filter by endpoint, HTTP method, or status code
Click a row to see full details
View the dependency timeline
See the raw JSON
Replay directly from the browser

Error responses show up with red highlighting, and slow requests (>1 second) get a warning indicator. If a request threw an exception, you see the full Python stack trace.

It's nothing fancy, just a single HTML file with some JavaScript, but it makes browsing through cassettes way faster than grepping through JSON.

Dealing With Sensitive Data

Early on, I realized that cassettes could contain passwords, API keys, and other stuff I definitely didn't want in my Git repo.

So Timetracer automatically redacts sensitive data:

Headers that get stripped:

Authorization
Cookie
Set-Cookie
X-API-Key
And about 20 others

Body fields that get masked:

password, secret, token
credit_card, cvv, ssn
api_key, private_key
And about 100 more patterns

In the latest release (v1.2.0), I added pattern detection for PII, emails, phone numbers, Social Security numbers, credit card numbers. The credit card detection even validates the Luhn checksum to avoid false positives.

A value like user@example.com becomes [REDACTED:EMAIL]. A credit card number becomes [REDACTED:CREDIT_CARD].

The goal is that cassettes should be safe to commit without thinking too hard about what's in them.

Real Use Cases

Debugging Production Bugs

This is the original reason I built it. Something breaks in production, you grab the cassette, replay locally, and debug with full context.

Regression Testing

Once you fix a bug, that cassette becomes a test case. You know exactly what input caused the problem and what the correct behavior should be. Run it against future code changes to make sure the bug doesn't come back.

Offline Development

Working on a flight? At a coffee shop with bad WiFi? If you have cassettes from previous sessions, you can keep developing without hitting real APIs.

Demos

Recording demo scenarios means your demos work even when external services are flaky. No more "let me refresh that" during a presentation.

Performance Analysis

The timeline command generates a waterfall chart showing how long each dependency took:

timetracer timeline ./cassette.json --open

You can see exactly where time is being spent. Is it the database query? The third-party API? The Redis lookup? It's all right there.

What About VCR.py?

VCR.py is great. I've used it for years. But it only records HTTP calls.

In a typical web application, a single API request might:

Query the database for user info
Call an external API for pricing
Check a cache for recent activity
Write to another database
Make another API call

VCR.py captures step 2 and 5. The rest? You're on your own.

Timetracer captures all of it. One cassette has everything.

Also, VCR.py is designed for test suites, you decorate individual test functions. Timetracer is designed as middleware. Every request through your app can be recorded. That makes it useful for production debugging, not just testing.

Getting Started

Install with pip:

pip install timetracer[fastapi,httpx]

Or for Flask:

pip install timetracer[flask,requests]

Add the middleware, set the environment variables, and make some requests. Your first cassettes will be in the directory you specified.

The documentation has more details on configuration, the CLI tools, S3 storage, and all the other features I didn't cover here.

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

What's Next

I'm using Timetracer on my own projects, and I keep finding things to improve. Some ideas on the roadmap:

Better support for async database drivers
GraphQL request parsing
Request diffing between cassettes
Maybe a VS Code extension?

If you try it out and have feedback, bugs, feature requests, or just thoughts, I'd love to hear it. Open an issue on GitHub or reach out on LinkedIn.

Thanks for reading. I hope Timetracer saves you some debugging time.

Links:

GitHub: https://github.com/usv240/timetracer
PyPI: https://pypi.org/project/timetracer/