OpenTrace Guide

Telemetry for
background work

OpenTrace is lightweight, self-hosted telemetry for scripts, workers,
batch jobs, and operational processes.

Some code is important but invisible. A nightly import runs for forty minutes. A scraper makes its way through thousands of pages. A data quality job checks fresh records and decides whether a downstream report should be trusted. Logs can tell you what happened line by line, but they rarely provide a clean live view of progress, current counts, notes, payloads, and milestones.

OpenTrace is built for that gap. It gives operational code a simple HTTP surface for reporting what it is doing to a live dashboard. A process can send progress, metrics, notes, JSON payloads, and milestones without adopting a full observability stack or designing a custom admin page.

When it fits

The best OpenTrace use cases are concrete and process-oriented: batch job monitoring, web scraper progress, data import visibility, data quality checks, drift reports, incident timelines, worker process dashboards, and internal operations monitoring. In each case, the goal is not to replace logs. The goal is to make status obvious while the work is still happening.

When it does not fit

OpenTrace is deliberately not positioned as a replacement for Prometheus, Grafana, ELK, OpenSearch, or Sentry. Infrastructure metrics, complex dashboarding, log search, and exception tracking already have mature tools. OpenTrace stays smaller: code reports what it is doing, and operators get a focused view.

How to start

The README starts with the shortest useful path: run docker compose up -d --build, then begin sending telemetry from the scripts and workers you care about. Start with one high-value process and add events where an operator would otherwise ask, "is it still running?", "how far did it get?", or "what happened next?"