How the PanDev Metrics plugin works
TL;DR. PanDev Metrics plugins live inside the IDE, browser, and CLI. They record activity events — not source code, not screenshots, not command arguments. The backend then turns those events into hours using a 15-minute gap rule: short gaps are active work, long gaps are breaks. AI prompts count as developer activity, AI-generated code is a separate counter, and offline work is queued locally until the connection returns.
What the plugin actually sees
The PanDev Metrics plugin is deliberately small. It registers when something happens — a keypress, a scroll, a file open, a prompt to an AI coding tool — and forwards a compact event to the PanDev Metrics server. It does not stream your screen, attach files, or scrape your editor buffer.
Each event carries enough metadata to attribute time, but not enough to leak your work:
- The file name you are touching (so PanDev Metrics can group time by project and language).
- The activity type: edit, scroll, file-open, file-close, navigation, AI-prompt, terminal-command-start.
- A timestamp and the source (IDE plugin, browser extension, CLI).
- The current repository, project, and module — the IDE plugin reads project structure to attribute time to the right repo and module/package without ever looking at the source code.
- The Git branch name, which lets PanDev Metrics auto-link the session to a task in Jira, GitLab, GitHub, or another tracker.
The plugin runs event-driven, not on a fixed timer. A truly idle window — IDE open, nobody touching the keyboard — produces zero events. That property is what makes the 15-minute gap rule below meaningful.
The privacy model, up front
Trust in a telemetry tool starts with knowing what it does not collect. PanDev Metrics is explicit about both sides of the line.
| Collected | Not collected |
|---|---|
| File names | Source code, even fragments |
| Activity events (typing, scroll, open, close, save, AI prompt) | Screenshots or screen recordings |
| Git branch name, repository, project, and module/package | Clipboard, secrets, environment variables |
| Terminal command name and the fact it was entered | Terminal command arguments or stdout |
| Timestamps and IDE/browser/CLI source tag | Keystrokes themselves (only the fact a keystroke occurred) |
PanDev Metrics shows individual events per person to that person's manager and aggregates the same events across the team. There is no "anonymous mode" — by design, engineering analytics is most useful when activity can be attributed. What that attribution cannot surface is the actual content of your work.
Your manager can see "you spent 2 h 14 m in payments-service on branch feature/PAY-812". Your manager cannot see what you typed in those 2 h 14 m. That distinction is the entire privacy contract.
How active time becomes "IDE hours"
PanDev Metrics turns an event stream into hours using a single rule, applied uniformly across IDE, browser, and CLI sources.
The 15-minute gap rule. If the gap between two consecutive events from the same person is shorter than 15 minutes, the interval between them counts as active time. If the gap is 15 minutes or longer, the interval is treated as a break and dropped.
The rule is simple on purpose. Anything more elaborate — eye-tracking, mouse-velocity heuristics, calendar lookups — would require collecting more data than PanDev Metrics is willing to collect. The 15-minute window is a practical compromise: it catches normal think-time and short context switches without paying out for lunch.
In the timeline above, four short bursts of events sit between two long gaps. The gaps are at least 15 minutes wide and never become hours. The bursts inside each cluster — each gap below 15 minutes — count fully. The rule applies independently to each source: IDE bursts in JetBrains and browser bursts in Chrome are both subject to the same gap test before being merged into a per-person daily total.
This is the only algorithm behind "Activity Time" and "IDE hours" on the dashboard. There are no hidden multipliers, no manual idle detection, no "minimum session length". The number you see is gap-filtered event-derived time.
Three sources, one timeline
PanDev Metrics treats the plugin family as a single observer with three eyes:
- IDE plugins — JetBrains family (IDEA, PyCharm, WebStorm, PhpStorm, GoLand, Rider, CLion, RustRover, RubyMine, Android Studio), VS Code and its forks (Cursor, Windsurf), Visual Studio, Xcode, and the Eclipse family.
- Browser extensions — Chrome, Brave, Edge, Firefox, Opera, Arc, Vivaldi, Yandex Browser, Whale, Sidekick. Tracking runs against an allowlist of corporate domains configured at the organization level, with a per-user blocklist on top.
- CLI agent — captures the name of commands you run (build, deploy script, custom shell tool). It does not record arguments. macOS and Linux ship today; Windows support is in development.
All three feed into the same event stream, and the same 15-minute gap rule applies. When sources overlap — you alt-tab between an IDE and a documentation tab in the browser — the per-source intervals are merged so a single minute is not counted twice.
AI coding tools, counted separately
PanDev Metrics distinguishes two kinds of AI work, because they answer different leadership questions.
| What happened | Counted as |
|---|---|
| You typed a prompt into Copilot, Cursor's chat, Claude in your IDE, or ChatGPT in the browser | Developer activity — you were working |
| The AI generated lines of code, suggested a refactor, or autocompleted a block | AI activity — a separate counter |
The first metric answers "how much did the engineer engage with the work today?". The second answers "how much code on this team is AI-produced, and is that share growing?". Mixing them would make both useless. By keeping the counters apart, PanDev Metrics lets a manager see, for the same hour, a human writing prompts and a model writing code — and lets the dashboard show the human-vs-AI ratio as it shifts.
Offline mode
Plugins are designed to lose the network and forget about it.
When the PanDev Metrics server is unreachable, each plugin appends new events to a local queue on disk. The queue survives IDE restarts, laptop sleep, and plane mode. When the plugin next establishes a connection, it drains the queue in order and the server stitches the events back into the user's timeline at their original timestamps. From the dashboard's point of view, the offline period is indistinguishable from an online one — except for the few minutes of latency between reconnect and full sync.
The implication for the 15-minute gap rule is mild: an offline-then-online flush still produces the same active/break decisions, because the rule operates on event timestamps, not arrival times.
How task attribution works without reading code
A natural worry is: "how can PanDev Metrics link time to a task if it doesn't read my code?" The answer is the Git branch.
When you check out feature/PAY-812, the plugin reads the branch name. It parses out the task key (PAY-812) using your tenant's branch convention and links every event that follows to that task in your tracker — Jira, GitLab Issues, GitHub Issues, Yandex Tracker, ClickUp, or Azure Boards. No code content needed; the branch name is metadata.
If the branch doesn't match a convention, events still flow but stay un-linked. They show up on the dashboard as time spent on the project, just not attached to a specific issue.
How the plugin fits with Git and tracker data
The plugin is only one of three input streams into PanDev Metrics. The other two pull from the systems you already use.
Plugin events answer "how was time spent?". Git events answer "what shipped?". Tracker events answer "what was planned?". DORA metrics like Deployment Frequency and Lead Time come almost entirely from Git and the tracker, not from the plugin. The plugin's role in DORA is contextual — explaining who and for how long — not authoritative.
FAQ
Can my manager see my code through the plugin?
No. The plugin never transmits source code, screenshots, or clipboard contents. Managers see activity events with file names and timestamps, plus aggregated hours. They do not see the content of the file. This is a product-level guarantee, not a configuration option that can be toggled.
What does the plugin track during a coffee break?
If the break is shorter than 15 minutes, the time between your last event and your next event is still counted as active — short gaps are normal think-time. If the break is 15 minutes or longer, the interval is treated as idle and excluded from your hours. You don't need to press anything; the rule applies automatically.
What happens to my events if my internet drops?
Each plugin maintains a local event queue. New events keep getting captured into the queue while you are offline. When the connection returns, the queue is drained to the PanDev Metrics server in order, with the original timestamps preserved. Your dashboard catches up within a few minutes of reconnecting.
Are AI prompts and AI-generated code counted the same way?
No. The prompt you write to an AI tool is your activity — you were actively working. The code or suggestion the AI generates is a separate counter labelled AI activity. This split lets PanDev Metrics show two numbers per person: how much they engaged, and how much code came from a model rather than from them.
Does the CLI plugin see my command arguments?
No. The CLI integration records only the command name (for example, npm, gradle, terraform) and the timestamp of the input, as a heartbeat of activity. It does not capture flags, arguments, environment variables, or stdout. Sensitive operations such as production deployments leave the same lightweight footprint as a directory listing.
How does the plugin know which task I'm working on?
The plugin reads the current Git branch name and matches it against your tenant's task-key convention — for example, branches starting with PAY- link to Jira tickets in the PAY project. Activity then attaches to that task on the dashboard. If the branch doesn't match a convention, time still counts for the project but stays unattached to a specific issue.
Related
- Concept: Key indicators — what the events become on the dashboard.
- How-to: Install the JetBrains plugin
- How-to: Install the VS Code plugin
- Concept: Product overview