Red Flag Thresholds
ActivityPulse 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 when red flags are computed — changing a threshold takes effect on the next data sync or on-demand refresh. There is no need to re-sync historical data; the new thresholds apply immediately to future evaluations.
Issues
| Field | Severity | Default | What triggers it |
|---|---|---|---|
| Too many issues (count) | Critical | 25 | Fires when the number of assigned issues exceeds this value |
| Too few issues (count) | Warning | 2 | Fires when the number of assigned 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 stale threshold 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 merge requests assigned to a teammate exceed this value |
| Too many MRs — critical (count) | Critical | 20 | Fires when open merge requests assigned to a teammate exceed this value |
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 when logged hours are below this value |
The low-worklog rule only evaluates weekdays — it does not fire on Saturdays and Sundays regardless of the configured threshold.
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.