Red Flag Thresholds
TeamGlimpse evaluates teammate activity against a set of detection rules and surfaces anomalies as Warning or Critical red flags on the dashboard and in the Signals view. By default, each rule uses a built-in threshold. The Red Flag Thresholds settings page lets admins override those defaults per organization so the alerts match your team’s actual norms.
Access: Requires an Admin or Owner role. Viewers cannot view or change threshold settings.
Navigate to Settings > Red Flag Thresholds to reach this page.
How Thresholds Work
Each field in the page corresponds to one detection rule. When a field is left blank, the system default shown in the placeholder is used. When a value is entered, that value replaces the default for your organization.
Thresholds are evaluated each time red flags are computed, from the activity already stored. Saving a change takes effect immediately: the Red Flags views reload with the new thresholds and there is no need to re-sync any data.
Issues
| Field | Severity | Default | What triggers it |
|---|---|---|---|
| Too many issues (count) | Critical | 25 | Fires when the number of assigned Jira issues exceeds this value |
| Too few issues (count) | Warning | 2 | Fires when the number of assigned Jira issues drops below this value |
| Stale issue/MR threshold (days) | Warning | 60 | Issues and open merge requests not updated within this many days are flagged as stale |
The two count rules apply to Jira issues only — GitHub issues, Azure DevOps work items and Salesforce records are deliberately not counted, because they are different kinds of record and mixing them would make the count meaningless.
The stale threshold, by contrast, applies to both issues and merge requests from all connected sources (Jira, GitLab, GitHub, Azure DevOps). The maximum accepted value is 365 days.
The Too few issues value must be strictly less than Too many issues when both are set.
Merge Requests
| Field | Severity | Default | What triggers it |
|---|---|---|---|
| Too many MRs — warning (count) | Warning | 10 | Fires when open GitLab merge requests assigned to a teammate exceed this value |
| Too many MRs — critical (count) | Critical | 20 | Fires when open GitLab merge requests assigned to a teammate exceed this value |
These two rules count GitLab merge requests only — GitHub pull requests do not contribute to them.
Both thresholds must be consistent: the warning value must be strictly less than the critical value. Saving equal or inverted values is rejected with a validation error.
Worklogs
These thresholds apply to time logged per day, drawn from Jira worklogs and other sources that report duration.
| Field | Severity | Default | What triggers it |
|---|---|---|---|
| High worklog — warning (h/day) | Warning | 10 | Fires when daily logged hours exceed this value |
| High worklog — critical (h/day) | Critical | 12 | Fires when daily logged hours exceed this value |
| Low worklog — warning (h/day) | Warning | 6 | Fires on weekdays where some time was logged but the total is below this value |
The low-worklog rule only evaluates weekdays — it does not fire on Saturdays and Sundays regardless of the configured threshold. It also requires some logged time: a weekday with zero logged hours never fires, because an absent worklog is treated as a day off rather than a short day.
All worklog hour fields are expressed in hours per day. The maximum accepted value is 24. The warning and critical thresholds must be in ascending order, and the low-worklog value must be strictly less than the high-worklog warning value when both are set.
Meetings
These thresholds apply to Microsoft 365 Teams meeting and call data.
| Field | Severity | Default | What triggers it |
|---|---|---|---|
| Too many meetings — warning (avg h/day) | Warning | 3 | Fires when the daily average meeting load exceeds this value |
| Too many meetings — critical (avg h/day) | Critical | 5 | Fires when the daily average meeting load exceeds this value |
| Camera usage threshold (%) | Warning | 90 | Fires when a teammate’s camera-on time is below this percentage of their total audio time in calls |
| Meeting no-shows — critical (count) | Critical | 5 | Fires when a teammate has missed this many accepted meetings |
The camera usage threshold is expressed as a whole-number percentage (0–100). A threshold of 90 means the warning fires when less than 90% of audio time has the camera on.
The no-show rule counts meetings that were accepted in the calendar but where the teammate did not join. A warning fires when at least one meeting is missed; the critical threshold controls when severity escalates. The minimum accepted value for the critical count is 2.
The meeting warning and critical thresholds must be in ascending order.
Saving Changes
Click Save thresholds to apply your changes. A confirmation toast appears when the update succeeds.
Resetting to Defaults
Click Reset to defaults to clear all custom thresholds and revert to the built-in system values. This action saves immediately — you do not need to click Save thresholds separately. A confirmation toast appears when the reset succeeds.
Relationship to the Red Flags View
The thresholds configured here directly control what appears in:
- The Dashboard red flags summary widget
- The Signals > Red Flags view and its date-range filter
- Any red flag notifications sent by email
For an overview of how red flags are surfaced and what the built-in detection rules cover, see the Overview page.