Skip to main content
Risk signals are Periscope’s automated problem detection layer. Rather than requiring you to manually review every chart and metric, risk signals surface actionable problems that need attention. Periscope uses two complementary approaches:
  1. Rule-based detection — deterministic rules with clear thresholds
  2. AI-powered analysis — Claude-powered analysis of all metrics data to find patterns that rules miss

​
Rule-based risk signals

Periscope continuously monitors your engineering data for common risk patterns:
  • Stale services — repositories with no recent merge activity
  • Bus factor risk — services with insufficient contributor diversity
  • Slow cycle times — PRs taking unusually long to merge
  • Large PRs — oversized changes creating review bottlenecks
  • Workload imbalance — uneven distribution of work across contributors
  • Activity anomalies — significant drops or spikes in activity compared to previous periods
  • High failure rate — elevated deployment failure rates
Each risk signal includes a severity level, a description of what was detected, the affected entity, and a recommended action.

​
AI-powered risk signals

On Business and Enterprise plans, Periscope analyzes your metrics data using AI to generate additional insights. The AI analysis looks for patterns that span multiple metrics — for example, a service with declining throughput, increasing cycle time, and limited contributor diversity. It produces natural language descriptions with actionable recommendations specific to your team’s data.
AI risk signals are generated on demand when you view the risk signals panel or query them via MCP. They are not stored or tracked historically.

​
Interpreting risk signals

​
Stale services

A service flagged as stale has not had a PR merged in over 14 days. This could mean:
  • The service is mature and stable (acceptable)
  • The service has been abandoned (needs ownership decision)
  • Work is happening but not going through PRs (unusual)

​
Bus factor

A service with only one contributor is at risk if that person leaves, goes on vacation, or gets sick. Even if the service is actively maintained, having a single point of failure is a structural risk. Action: Cross-train another team member or establish a rotation for code review.

​
Slow reviews and large PRs

These signals often appear together. Large PRs take longer to review, which increases cycle time, which delays delivery. It is a reinforcing loop. Action: Coach the team on breaking work into smaller PRs. Set guidelines for maximum PR size.

​
Workload imbalance

When one person does more than half the work on a service or across the team, it creates both a bus factor risk and a burnout risk. Action: Review task distribution in sprint planning. Consider pairing or rotating assignments.

​
Activity anomalies

Sudden drops or spikes in activity are worth investigating:
  • Drops may indicate blockers, team attrition, or a shift to non-PR work
  • Spikes may indicate deadline pressure, a large feature landing, or a catch-up after a blocker is resolved

​
MCP tool

Query risk signals from your AI coding assistant: 
get_risk_signals(time_range: "30d")
Returns all detected risk signals with category, severity, description, affected entity, and recommendations.

Service health

Service health provides the per-repository view that risk signals draw from.