logsite

Your logs say something broke. logsite tells you which line of your code, and writes a test that proves it.

pip install logsite

Point it at your code and the logs you already have (a log file, Loki, OpenSearch / Elasticsearch or CloudWatch). It turns thousands of stack traces into a few causes, each pointing at your line of code. No SDK, nothing to add to your services. Python, Java and Go.

How is this different from Sentry, Datadog or Grafana?

It needs no SDK and works on the logs you already have. Sentry and Datadog see errors from services you've instrumented, inside their platform. Grafana and Loki store and search your logs, but don't know your code. logsite reads both your logs and your code, on your machine:

It doesn't replace them: there's no hosted UI or real-time alerting of its own. It works alongside them, and plugs into Grafana as a data source and into Grafana alerts.

Try it in 2 minutes

The repo has a small demo shop, examples/bookstore, with a planted bug: calls to a supplier time out and are never retried. Its production log is in the repo too.

pip install logsite pytest
git clone https://github.com/rajpaynaik/logsite && cd logsite/examples/bookstore

1. What's failing? Read the log and group the errors by cause:

$ logsite errors --from ../../bench/repro/scenarios/supplier-timeout/incident.log
28 errors in incident.log · 2 group(s)

  #  TREND  COUNT  ERROR                                      RAISED AT       LOGGED AT
  1            25  TimeoutError: timed out                    supplier.py:31  api.py:36
  2             3  ConnectionRefusedError: cache unavailable  cache.py:15     api.py:23

━━ 1. TimeoutError: timed out ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 25
   Raised at    bookstore/supplier.py:31  restock()  (in socket)
                31 │ with urllib.request.urlopen(request, timeout=self.timeout) as resp:
   Logged at    bookstore/api.py:36
   Call path    api.handle › api.<lambda> › inventory.reorder › supplier.restock › socket

28 errors, 2 causes, and the exact line behind each one.

2. Turn the error into a failing test. logsite takes the function to call, the values the failing request logged and the dependency to fake, and writes a pytest test:

$ logsite repro --from ../../bench/repro/scenarios/supplier-timeout/incident.log --write-test
Reproduce 346fa937 · TimeoutError: timed out · 25 error(s)
  Fail with    TimeoutError through bookstore/supplier.py:31 (restock)
  Call         reorder(sku, qty)  from bookstore.inventory  bookstore/inventory.py:13
  Fake         bookstore/supplier.py:31 calls urllib.request.urlopen(…): patch urllib.request.urlopen raise TimeoutError
  Inputs       sku   = BK-1802               logged at bookstore/inventory.py:17
               qty   = 10                    logged at bookstore/inventory.py:17

wrote tests/test_repro_346fa937.py

3. Check it fails the way production did: the same exception, through the same line.

$ logsite agent --expect 346fa937 -- python -m pytest tests/test_repro_346fa937.py
✓ 346fa937 reproduced: TimeoutError through bookstore/supplier.py:31, as in production

Now fix supplier.py until the test passes. Run your tests through logsite agent to get the causes instead of hundreds of lines of output:

$ logsite agent -- python -m pytest
pytest: 1 failed, 6 passed · 1 cause(s) · exit 1

1. 1 test(s)  TimeoutError: timed out
   raised   bookstore/supplier.py:31 in restock()

Use it on your own service

cd your-service
logsite lint                         # logging mistakes in your code; no logs needed
logsite errors --from downloaded.log  # errors grouped by cause, from any log file

To read from your log store, add a logsite.toml:

[backend]
type = "loki"                        # or "opensearch", "cloudwatch", "file"
url = "http://localhost:3100"
selector = '{service_name="checkout"}'

logsite errors                       # production errors from the last 24h, grouped by cause
logsite investigate                  # linked into incidents, with the deploy and commit behind them
logsite about app/checkout.py:42     # what production says about this line, before you change it

See Configuration for every backend.

What else it does

• Finds the change behind an incident: logsite investigate names the deploy and the commits just before the errors started. → Errors and incidents
• Remembers past fixes: when an old error comes back, it shows the commit that fixed it last time. → History
• Blocks bad releases in CI: logsite errors --since-deploy $TAG --fail-on-new fails the build if the release brought a new error.
• Helps AI coding assistants: the Claude Code plugin and the MCP server tell the assistant what a function does in production before it changes it. /logsite:fix-error reproduces an error, then fixes it.
• Shows production in your editor: how often each log call runs and which lines raise errors, right above the code. VS Code, or any LSP editor.
• Cuts log costs: which logger.info(...) calls make up your log bill, and secrets that reached your logs. → Cost and leaks
• Works with Grafana: a data source, dashboards, alert summaries and Alloy rules to drop noisy lines. → Grafana

Supported

Install

pip install logsite                  # the command-line tool
pip install "logsite[lsp,mcp]"       # + the editor language server and the MCP server

Documentation

Commands · Configuration · Errors and incidents · Agent mode · Reproduce an error · History · Grafana · Languages · Lint rules · Cost and leaks · Request timeline · MCP server · Claude Code plugin · How it works · Roadmap

Status

Early (0.x): feedback and contributors welcome. Formerly loglens: loglens.toml and [tool.loglens] configs keep working. See CONTRIBUTING.md; a new log backend is a good first PR.

License

Apache License 2.0. See LICENSE.