Skip to main content
Version: v2 (current)

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. A few channels do carry content — database cell edits, meeting transcripts, AI prompt text — and they are listed in Sensitive data. 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.

CollectedNot collected
File namesSource code, even fragments
Activity events (typing, scroll, open, close, save, AI prompt)Screenshots or screen recordings
Git branch name, repository, project, and module/packageClipboard, secrets, environment variables
Terminal command name and the fact it was enteredTerminal command arguments or stdout
Timestamps and IDE/browser/CLI source tagKeystrokes 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.

Read it differently

Your manager can see "you spent 2 h 14 m in payments-service on branch feature/PAY-812". Your manager cannot see the code you typed in those 2 h 14 m. The exceptions are the content channels listed in Sensitive data: the text of your AI prompts, manual database edits, and meeting transcripts.

Sensitive data: content that is collected​

The table above describes the IDE, browser, and CLI plugins. The channels below carry content, not just activity metadata. They are the most sensitive part of the telemetry, so they are listed here explicitly. All of it is stored in the PanDev Metrics PostgreSQL database — in your own perimeter for on-prem installs.

Database cell values and SQL text​

  • What: the value of a database cell before and after a manual edit (table, column, row id), and the text of SQL queries run from the database client.
  • Source: the DBeaver plugin.
  • Why: shows manual changes to data — who changed which table, column, and row — and counts database work as activity.
  • Stored in: activity_events.meta (old_cell_value, new_cell_value, database_script) and db_manual_cell_changes.
  • How to turn it off: plugin settings Manual data edits in the results grid and Store new values of manually edited cells; Hide values in query text masks literals and is on by default. The master switch turns off collection as a whole.
  • Retention: no automatic expiry.

Meeting intervals​

  • What: who attended which Microsoft Teams, Zoom, or Google Meet meeting, and when.
  • Source: the Teams and Zoom integrations; the browser extension for Google Meet.
  • Why: meeting time on the activity timeline and the employee page.
  • Stored in: calls, call_participants.
  • How to turn it off: do not connect the Teams or Zoom integration. Google Meet collection is off until a department enables it.
  • Retention: Teams — no automatic expiry. Zoom — until the PanDev Metrics app is removed from the Zoom account, which deletes the department's Zoom calls. Google Meet — 180 days by default (department setting; 0 keeps them forever).

Meeting transcripts​

  • What: the text of the conversation.
  • Source: Teams (off by default), Zoom (on by default once the Zoom integration is connected), Google Meet captions via the browser extension (off by default).
  • Why: AI meeting analysis — summaries and tasks extracted from the conversation.
  • Stored in: call_transcripts, encrypted with AES.
  • How to turn it off: department settings for Teams transcripts, Zoom transcripts, and Google Meet collection. When Google Meet capture starts, other participants get a notice in the meeting chat.
  • Retention: same as meeting intervals.

AI prompt text​

  • What: the full text of prompts sent to AI tools.
  • Source: AI coding assistants and CLI agents connected to PanDev Metrics.
  • Why: counts AI usage, links agent sessions to tasks (a prompt that names a task), and feeds AI period analysis.
  • Stored in: activity_events.meta (prompt).
  • How to turn it off: there is no separate server-side switch yet; prompts are not collected from tools that are not connected.
  • Retention: no automatic expiry.

If your organisation needs a shorter retention period or needs one of these channels off entirely, decide it before rollout and inform employees accordingly.

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 happenedCounted as
You typed a prompt into Copilot, Cursor's chat, Claude in your IDE, or ChatGPT in the browserDeveloper activity — you were working
The AI generated lines of code, suggested a refactor, or autocompleted a blockAI 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. Content that is collected — AI prompt text, manual database edits, and meeting transcripts — is listed in Sensitive data.

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.

Citations​