Use LGTM as a CI gate
Configure LGTM's review verdict as a required Check Run in branch protection. A failed review blocks the merge until findings are resolved — automated quality gate, no human bottleneck.
Merges happen because nobody looked. PR approvals get rubber-stamped. Code quality slips. A CI gate from LGTM forces a clean review (or a human override) before merge.
What 'CI gate' means with LGTM
When LGTM reviews a PR, it posts the review as a normal GitHub PR review (visible inline comments, summary, verdict) AND as a Check Run via the Checks API. The Check Run has a conclusion: `success` if verdict is APPROVE, `failure` if REQUEST_CHANGES, `neutral` if COMMENT.
GitHub's branch protection rules respect Check Runs. Add the LGTM Security check + the LGTM Review check as required checks on your default branch. Failed checks = no merge.
Critical detail: branch protection is the gate, not LGTM itself. We CAN'T block merges directly — we publish a check, GitHub enforces. This means the gate works exactly like CI gates devs already understand (CI fails → can't merge). Same UX, same admin override.
Setup — 3 minutes from install to gated
(1) Install LGTM GitHub App on the repo. (2) Open a PR (any PR). LGTM reviews it, posts a Check Run named 'LGTM Review'. Confirm the check appears in the PR Checks tab. (3) Settings → Branches → Add rule → Require status checks to pass before merging → search 'LGTM Review' → add. Save.
Repeat for 'LGTM Security' check if you want the security gate too. (Most teams enable both.)
Now: every PR opened against the protected branch must have a passing LGTM Review Check before it can merge. Failed reviews show in the PR's merge box with a 'Required check failed' message and a 'Re-run' button.
What blocks vs what warns
Review verdict mapping:
- APPROVE (no blocker/critical findings) → check `success` → green merge box.
- REQUEST_CHANGES (blocker or critical findings) → check `failure` → merge blocked.
- COMMENT (only minor findings) → check `neutral` → merge allowed but check visible.
Custom-tuning the threshold: Settings → Repos → Verdict Rules → set the severity threshold that triggers REQUEST_CHANGES. Default is `blocker` or `critical`. Stricter teams set it to `any-finding`; relaxed teams set it to `blocker` only.
Override + bypass
Admin override: GitHub branch protection lets admins bypass required checks (the 'Allow specified actors to bypass required pull requests' setting). LGTM doesn't interfere with this — admin override works normally.
Force-push: if a force push lands during review, the check's commit SHA no longer matches. Branch protection sees the check as stale → blocks merge until a fresh review runs. LGTM auto-reruns on synchronize webhook, typically within 30 seconds.
Emergency bypass workflow: admin force-merges (`Allow administrators to bypass branch protection`), commits to default branch directly. LGTM's runtime watchdog (separate from the PR gate) still sees the push and posts a follow-up check on the merge commit — even if the merge wasn't gated, the audit log captures it.
Configuration examples
# Repository → Settings → Branches → Rule on 'main':
#
# ☑ Require status checks to pass before merging
# Required checks:
# ☑ LGTM Review
# ☑ LGTM Security
# ☑ build (your existing CI)
# ☑ test (your existing CI)
#
# ☑ Require branches to be up to date before merging
# ☑ Restrict who can push to matching branches
# (admins bypass: optional, choose carefully)Read LGTM Security's enforcement model
Three gates: inline PR · merge-block Check Run · runtime watchdog
Go to the product pageFAQs
Will the LGTM check fail intermittently and block valid merges?
Reviews are deterministic given the same diff + context + model. The only intermittent failure mode is LLM provider downtime (OpenAI direct, OpenRouter, or Managed AI backend outage), which we handle with retries + multi-provider failover. A merge blocked by a transient failure can be unblocked by re-running the review (button in the PR Checks tab).
What about emergency hotfixes?
Admin bypass + clear post-incident audit. Branch protection lets admins force-merge; LGTM's audit log captures every bypassed merge with metadata. Post-incident, review the audit log to confirm the bypass was legitimate.
Does the gate slow down our team's velocity?
LGTM review completes in 30-90s. If your team's CI is 5-15 minutes, the LGTM check is on the critical path NO additional delay. If your CI is 30s, LGTM adds about a minute. Net velocity usually goes UP because reviews catch issues that would otherwise become production bugs.
Can I gate only on security findings, not code-style?
Yes — Settings → Repos → Verdict Rules. Set 'Block merge only on findings from: Security agent'. Then the gate only fails on security issues; bug/perf/style findings post inline but don't block.
What if LGTM is down?
The check goes into a pending state. GitHub branch protection lets you set a timeout on required checks (Settings → Branches → Required checks → Strict). Most teams set 10 minutes. After that, the check is treated as 'never reported' — branch protection blocks until LGTM comes back. Our uptime is 99.9%+ but downtime happens.
Related across LGTM
CI/CD security explained
Why pipeline-config scanning is its own discipline distinct from AppSec.
Pinned action explained
One of the merge-block rules — flagging non-SHA action refs.
LGTM Security overview
All 36 detectors (GitHub Actions, GitLab CI, CircleCI, Azure Pipelines) + the 3 enforcement gates a CI gate composes from.
GitHub App permissions
Which scopes LGTM needs to post Check Runs that branch protection respects.
Related use cases
Pre-push local review
Review your working diff locally with the lgtm CLI before pushing — catch issues before the PR opens, save round-trips with reviewers, faster iteration.
Onboard a monorepo to AI code review
Connect a 1k–100k-file monorepo to LGTM in under 10 minutes. Tree-sitter indexes all 12 languages, PageRank ranks cross-package context, BYOK keeps per-PR cost manageable.
Generate compliance audit evidence
Every LGTM review is a timestamped, immutable audit log entry. Export per-repo or per-quarter as JSON or CSV for SOC2, ISO 27001, or DPDP evidence.