Quick start

Three steps take you from a new workspace to live team intelligence. Steps 1–3 are required; everything else is optional and can be added at any time.

Key concepts

Lenses

TeamEye organizes signals into four independent lenses. Each lens can be active or inactive depending on which integrations you've connected. A bad or missing lens never degrades another.

Visible teammates

A visible teammate is a person whose operational engineering metadata is included in TeamEye reports. They are selected explicitly by a workspace owner and can see the same data used for their profile.

Plan tiers are based on engineering team size, not per-seat billing. You can add or remove visible teammates from Setup → People.

Data Trust score

The Data Trust score (0–100) measures how usable a Jira project's data actually is. TeamEye audits five hygiene rules and weights them into a single score.

A score below 60 (the default threshold) puts the project in hygiene report mode: delivery numbers won't be used in operational risk summaries until the data is reliable enough. The hygiene findings themselves are still visible — you can see what's dragging the score down and fix it. The threshold is configurable via the TEAMEYE_JIRA_TRUST_MIN environment variable.

Excused absences

When a visible teammate is on approved leave (confirmed by Google Calendar, Microsoft 365, or BambooHR), their status is set to Excused. While excused:

• No low-activity or availability-related risk signals are generated during approved leave
• Their absence window is shown on their profile and in daily digest summaries
• Operational activity is interpreted with availability context, so planned absence is not treated as a risk

Tentative/pending leave events are not treated as excused by default. Enable them with TEAMEYE_ABSENCE_INCLUDE_TENTATIVE=true if your team approves leave retroactively.

GitLab integration

GitLab provides the Engineering Activity lens. It gives TeamEye read-only metadata about commits, merge requests and review flow. GitLab is usually the first integration because it identifies visible teammates and engineering activity sources.

Setup steps

Parameters

Required scopes

The token needs exactly two scopes:

• read_user — identifies the token owner and validates the connection
• read_api — reads group membership and daily activity (commits, MRs, reviews)

No write scopes are ever needed. TeamEye never creates, edits, or deletes anything in your GitLab.

Self-hosted GitLab

Fill in the Instance URL field with your GitLab root (e.g. https://gitlab.example.com). The API is accessed at {instance_url}/api/v4/…. GitLab versions 14.0 and above are supported. Older versions may work but are not tested.

What data is read

• Group and member lists (names, usernames, email addresses)
• Commit timestamps and counts per author per day
• Merge Request open/merge/close events and review activity
• Nothing from private message contents, wikis, or issue descriptions

Jira integration

Jira adds the Delivery lens — throughput, cycle time, and a Data Trust hygiene audit. It adds delivery planning context and is analyzed independently from Git activity, so weak Jira hygiene is visible instead of silently corrupting management conclusions.

Setup steps

Parameters

Data Trust thresholds

Delivery numbers only feed into operational risk summaries when a project's Data Trust score is at or above 60 (default). Below that, the hygiene audit findings are still shown so you can see exactly which rules are dragging the score down.

The stale/stuck thresholds that affect two of the five rules:

Excluded done statuses

Issues closed as Cancelled, Won't Do, Duplicate, etc. should not inflate throughput. By default, TeamEye excludes the following status names from the delivered count:

Cancelled · Canceled · Won't Do · Won't Fix · Won't fix · Duplicate · Rejected · Declined · Abandoned · Obsolete

If your board uses different wording, override with the TEAMEYE_JIRA_EXCLUDED_DONE_STATUSES environment variable (comma-separated, case-sensitive to your Jira status names).

Story points custom field

Atlassian Cloud assigns a unique custom field ID to story points per instance (commonly customfield_10016, but not guaranteed). Without this configured, TeamEye counts issues instead of summing points — throughput still works, the points column stays blank.

To find your field ID: open any Jira issue that has points, press ? to open keyboard shortcuts, then navigate to … → View issue in XML and search for customfield_ next to the story points value. Set TEAMEYE_JIRA_STORY_POINTS_FIELD=customfield_XXXXX.

What data is read

• Project keys and names
• Issue status, assignee, created/updated/resolved timestamps
• Story point estimates (if field is configured)
• Issue type and resolution — no issue descriptions or comments

Sentry integration

Sentry powers the Reliability lens — a live view of what's breaking across your projects: error volume, new issues, severity and timing. It's completely optional, read-only, and never touches your source code or event payloads.

Setup steps

Parameters

Required scopes

The auth token needs three read-only scopes:

• org:read — resolves the organization and validates the connection
• project:read — lists your projects
• event:read — reads aggregate error statistics (counts, levels, timing)

No write scopes are ever needed. TeamEye never creates, edits, or resolves anything in Sentry.

What data is read

• Project list (names and slugs)
• Error / event counts over a trailing window, as a timeseries
• New-issue counts and the top issues leaderboard
• Severity levels and timing — never event payloads, stack-trace source, or your code

Tuning

Reliability tuning is controlled by environment variables (sensible defaults shown):

Google Calendar integration

Reads Out-of-Office events for your Google Workspace users so TeamEye knows when someone is officially away and can suppress false alerts.

How it works

TeamEye uses a Google service account with domain-wide delegation (DWD). The service account impersonates a Workspace admin to enumerate per-user OOF event types and dates. No event titles, descriptions, or attendees are ever read.

Setup steps

Parameters

Microsoft 365 integration

Reads Out-of-Office calendar blocks and auto-reply date ranges via the Microsoft Graph API. Requires an Azure App Registration with admin consent.

Setup steps

Parameters

BambooHR integration

Pulls approved time-off requests for your team members so TeamEye never fires false alerts when someone is officially on leave. The simplest absence integration — two fields, no admin console required.

Setup steps

Parameters

Matching logic

TeamEye matches BambooHR employees to visible teammates by work email address. If an employee's email in BambooHR matches a visible teammate's email in TeamEye, their approved leave days are automatically marked as Excused.

If the emails don't match (different domains, aliases), the coverage report in Setup will show the employee as unmatched. Fix this by ensuring the email in BambooHR matches the one used in GitLab, or by manually linking the person in TeamEye.

Roles & permissions

TeamEye has two roles: Owner and Member. One workspace can have multiple members but currently only one owner.

Invites are sent by email from Setup → Team. The invited person must register or log in; they land in the same organization automatically once they accept the invite link.

FAQ

Do I need Jira to use TeamEye?

No. TeamEye can start from GitLab engineering activity metadata. Jira adds delivery flow and planning context. If Jira is not connected, or if its Data Trust score is too low, TeamEye simply excludes Jira-based delivery signals from operational summaries.

Can the same person appear in multiple workspaces?

Yes — a user account can belong to multiple organizations, each with its own visible teammates, integrations, and billing. Switching between them is done via the organization switcher in the app shell.

My Jira Data Trust score is below 60. What do I do?

Open Delivery → Hygiene. The audit lists every project with its score breakdown by rule. The most common fixes: assign In-Progress issues, add story point estimates, and move stale issues forward or close them. Once the score crosses the threshold, delivery data will appear in the next nightly sync.

How often does data sync?

Most integrations sync nightly (once per day, EU time). Absence syncs cover a 30-day lookback and 60-day lookahead window by default. You can trigger a manual Jira hygiene run from the Hygiene page; GitLab and absence syncs cannot be triggered manually.

Sentry is the exception — reliability stats are read live from the Sentry API on demand and cached for about 10 minutes, so there's no nightly Sentry sync and figures may lag Sentry by up to that cache window.

Is there a way to exclude certain GitLab groups or projects?

Exclusion happens at the people level, not the group level. If you don't want someone included, deselect them in the people picker. TeamEye only stores metadata for selected visible teammates. Activity from people who are not selected is ignored.

What happens when someone leaves the team?

Remove them from Setup → People. Their historical operational data can remain available for reports, but they stop appearing in future daily briefings and risk summaries.

Where are credentials stored?

All tokens, API keys, and secrets are encrypted at rest under your workspace's isolated options store. Credentials are never shared across workspaces and are never logged or sent to third parties.

How do I disconnect an integration?

Go to Setup and click Disconnect next to the relevant integration. All stored credentials for that integration are deleted immediately. Historical data synced before disconnection is retained.