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

SignalThresholdCategory
Stale serviceNo merge activity in 14+ daysstale_service
Bus factor riskOnly one contributor to a servicebus_factor
Slow cycle timesPR cycle time exceeding 72 hoursslow_reviews
Large PRsPRs with 500+ lines taking 48+ hourslarge_prs
Workload imbalanceOne contributor doing 50%+ of workreview_bottleneck
Activity drop30%+ decrease in activity vs previous periodactivity_drop
Activity spike50%+ increase in activity vs previous periodactivity_spike
High failure rateDeployment failure rate above thresholdfailure_rate
Each risk signal includes:
  • Category — the type of risk
  • Severity — how critical the signal is
  • Description — what was detected
  • Affected entity — which service, contributor, or PR is involved
  • Recommendation — suggested action to take

AI-powered risk signals

On Business and Enterprise plans, Periscope can analyze all your metrics data using Claude to generate additional insights. The AI analysis:
  • Looks for patterns that span multiple metrics (e.g., a service with declining throughput and increasing cycle time and a single contributor)
  • Generates natural language descriptions of the risk and its potential impact
  • Provides actionable recommendations specific to your team’s data
  • Uses the same RiskSignal format as rule-based signals for consistency
AI signals are cached for 5 minutes to balance freshness with API cost.
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.