Skip to main content

​
Overview

Instrumentation Reviewer reviews telemetry-related code changes in pull requests and merge requests before they are merged. It is built to catch instrumentation problems early, while the change is still in code review, instead of after the change has already affected dashboards, alerts, traces, logs, or telemetry cost.

​
What It Reviews

Instrumentation Reviewer focuses on code changes that affect logs, metrics, traces, structured fields, telemetry routing, and related observability behavior. It is designed to help teams catch issues such as:
  • high-cardinality fields or labels
  • PII exposure in telemetry
  • metric correctness problems
  • spammy or overly noisy logs
  • incorrect severity levels
  • wrong telemetry pillar selection
  • telemetry regressions caused by removed or degraded signal quality
  • telemetry schema consistency problems

​
Why Teams Use It

Instrumentation quality often drifts over time, especially when many teams ship quickly across many services. Common outcomes of that drift include:
  • inconsistent instrumentation patterns between services
  • dashboards and alerts that become harder to trust
  • noisy or low-value telemetry
  • hidden operational cleanup work for platform, DevOps, and SRE teams
  • unnecessary telemetry growth and less predictable observability cost
Instrumentation Reviewer helps move those checks earlier into the development workflow.

​
How It Works

Instrumentation Reviewer runs as an SCM-driven review workflow. At a high level it:
  1. Detects a relevant pull request or merge request event.
  2. Fetches the PR or MR metadata, changed files, and repository context.
  3. Clones the repository so it can inspect the changed code in context.
  4. Runs objective-based telemetry review logic over the change.
  5. Synthesizes the results into a customer-safe review.
  6. Publishes the output back to GitHub or GitLab.
The reviewer is designed around real code review context, not isolated snippets. It uses both the diff and surrounding repository code to understand the instrumentation change.

​
Review Workflow

Instrumentation Reviewer currently uses a staged workflow:
  • Gather context: fetch PR or MR metadata, changed files, comments, and repository checkout
  • Objective execution: run telemetry-focused review objectives against the change
  • Synthesis: merge, deduplicate, and normalize findings
  • Postprocess and publish: convert findings into SCM-ready review output
This lets the reviewer keep internal analysis artifacts separate from the final customer-facing review.

​
GitHub Behavior

On GitHub, Instrumentation Reviewer is driven by the GitHub App integration. It supports:
  • automatic review runs on pull request events
  • review publishing as PR reviews and inline review comments
  • review-comment replies for follow-up interactions
  • GitHub Checks integration for review lifecycle status
  • rerun from the Checks UI
  • comment-driven interactions such as @<app-handle> cancel
GitHub setup and permissions are documented in Enable GitHub Integration.

​
GitLab Behavior

On GitLab, Instrumentation Reviewer is driven by a dedicated GitLab integration and webhook per configured scope. It supports:
  • automatic review runs on merge request events
  • inline merge request discussions when diff position data is available
  • summary merge request notes as the review-level output
  • note-driven commands such as /sawmills review
  • cancellation commands such as /sawmills cancel
GitLab setup and access requirements are documented in Enable GitLab Integration.

​
What Gets Published Back

Instrumentation Reviewer publishes the result back to the source control system rather than only storing it internally. Depending on provider and event, that can include:
  • a review summary
  • inline comments or inline discussions on changed code
  • follow-up replies in existing review threads
  • GitHub check-run status and annotations
This keeps the telemetry feedback in the same review workflow where engineers are already making code decisions.

​
Trigger Model

Instrumentation Reviewer can run both automatically and interactively. Examples include:
  • pull request open, reopen, synchronize, and ready-for-review events on GitHub
  • merge request open, reopen, and update events on GitLab
  • GitHub comment-driven reruns or cancellation
  • GitHub Checks rerun actions
  • GitLab note-driven review or cancellation commands
In beta, trigger behavior and exact command phrasing may continue to evolve.

​
Access and Integrations

Instrumentation Reviewer depends on source control integrations because it needs to read code changes and publish the results back to the review surface. To use it, your workspace needs the relevant SCM integration: Those integrations provide the reviewer with:
  • access to PR or MR metadata
  • access to changed files and repository context
  • access to publish review results back to the SCM
  • webhook-driven review triggering

​
Best Fit Use Cases

Instrumentation Reviewer is especially useful when teams want to:
  • catch telemetry problems before merge
  • enforce instrumentation standards across many repositories
  • reduce telemetry noise and cardinality growth
  • improve consistency across logs, metrics, and traces
  • keep telemetry review inside the normal PR or MR workflow
  • give platform and observability teams stronger guardrails without creating a central bottleneck