Skip to content

Platform Guidance

Whether the dashboard is the right default depends on the runtime surface, not the product label.

Runtime surfaceRecommended control surfaceDashboard role
Standard browser web appDashboardDefault runtime control surface for targeted tracing
Browser app with limited log visibility, such as some mobile or embedded surfacesDashboard plus a platform-specific log access pathControls capture only; does not make logs visible
Console app, server, CLI, or worker processRuntime APINot applicable
Hybrid app with both browser and non-browser runtimesPer-surface choiceUse the dashboard only where a browser UI actually exists

Browser Surfaces

In browser-based apps, the dashboard is the preferred way to start dormant, target a narrow capture window, and stop quickly.

For the normal browser workflow, see Dashboard For Web Apps. For manual mounting, widget controls, and package-side dashboard settings, see Dashboard Package Reference.

That recommendation still assumes the host platform gives you a practical way to inspect the output written by the tracer.

If it does not, the dashboard remains useful for control, but not for visibility.

When the dashboard is not mounted in a browser runtime, use the lower-level runtime control surface on globalThis.autoTracer instead. The concrete public runtime APIs are documented on @autotracer/react18 and @autotracer/flow.

Non-Browser Surfaces

For console apps, servers, CLIs, and native runtimes without a browser DOM, use the runtime APIs directly.

The dashboard is a browser widget. If there is no browser UI, there is no dashboard surface to mount.

Hybrid Apps

Treat each runtime separately.

  • Browser renderer or webview surface: dashboard guidance applies.
  • Main process, backend process, worker, or CLI surface: runtime API guidance applies.

This keeps the docs honest about what the dashboard can actually do in each environment.

Released under the MIT License.