POST /v1/events from the CLI/SDK (+ docs snippet) · open source (MIT) · ask in plain English

Add analytics to your dev tool Dev tools.

Analytics for dev tools is awkward because your users live in a terminal, not a browser. Activation is not a pageview, it is the first successful command or first API call. smolanalytics takes events from anywhere over POST /v1/events, so a CLI, an SDK, and your docs site all report into one funnel, and you ask the numbers from your editor over MCP.

POST /v1/events from the CLI/SDK (+ docs snippet)
# from your CLI or SDK, on key moments (opt-in telemetry):
curl -X POST https://YOUR-INSTANCE/v1/events \
  -H "Authorization: Bearer WRITE_KEY" \
  -d '{"name":"cli_run","distinct_id":"anon_or_project_id","properties":{"cmd":"build","ok":true,"version":"1.4.0"}}'

<!-- docs site head, to see docs-to-install: -->
<script src="https://YOUR-INSTANCE/sdk.js"></script>
<script>smolanalytics.init("WRITE_KEY", { host: "https://YOUR-INSTANCE" });</script>

There is no browser SDK for a CLI: POST batched events to /v1/events on install, first run, and errors. Put the script snippet on the docs site so you can join docs reads to actual installs.

how do I add analytics to dev tools?

Analytics for dev tools is awkward because your users live in a terminal, not a browser. Activation is not a pageview, it is the first successful command or first API call. smolanalytics takes events from anywhere over POST /v1/events, so a CLI, an SDK, and your docs site all report into one funnel, and you ask the numbers from your editor over MCP.

Measure the developer activation path: docs visit, install, first run, first successful run, then repeat use across days. The signal that predicts retention is first successful run, so tag whether each invocation succeeded and which command it was, plus tool version so you can see adoption of new releases and where old versions get stuck. Errors are product feedback here: send failed runs with a reason and you get a ranked list of what breaks people on day one.

The fit is that dev tools emit events from everywhere except a browser, and this is a single endpoint that takes JSON from any language, batched up to 10k to save calls. Keep telemetry opt-in and PII-free with an anonymous or project-level distinct_id. Best part for a builder: you ask usage questions in plain English from your editor over MCP, so checking whether the new release lifted successful-run rate never leaves your terminal, and the answer is a deterministic report, not a guess.

Honest pricing: 14-day full trial, no credit card. Then Solo $29/mo, never metered on seats or sites. Overage is $5/million with an emailed receipt, the dashboard never locks, and self-hosting the single Go binary is free forever (MIT).

Add analytics to Dev tools tonight.

One snippet, or one endpoint. Tomorrow morning the verdict tells you which part of the funnel to fix.

questions

How do I add analytics to Dev tools?
Analytics for dev tools is awkward because your users live in a terminal, not a browser. Activation is not a pageview, it is the first successful command or first API call. smolanalytics takes events from anywhere over POST /v1/events, so a CLI, an SDK, and your docs site all report into one funnel, and you ask the numbers from your editor over MCP.
Do I need a cookie banner?
Not in cookieless mode. smolanalytics can run without storing anything on the device, so there is no consent banner to add. You still get visitors, referrers, funnels, retention, and paths, and AI-assistant referrals (chatgpt.com, claude.ai, perplexity.ai) show up as their own channel.
Is it enough for a real product, or just page counts?
It does funnels, retention, paths, cohorts, and a daily verdict on what to fix, from the same events, and you ask it in plain English. It deliberately skips session replay, feature flags, and experiments. If you want a straight answer on what to fix, that you own and can self-host free, it fits.

keep reading