Static analysis has been part of pre-deploy quality gates for over a decade. ESLint, SonarQube, Semgrep, Checkmarx — the category is mature, widely adopted, and genuinely useful. When a pre-deploy static analysis step catches a type error, a SQL injection pattern, or a null dereference, it's doing exactly what it was designed to do.
What static analysis was not designed to do: tell you that touching this function will break the checkout flow on a service three hops downstream in your service graph. That's a different category of problem, and it requires a different category of tool.
The two failure modes that pre-deploy checks should address
Production incidents in microservice architectures tend to fall into two categories that map roughly to what different pre-deploy checks can and cannot catch.
In-service failures are bugs within the changed service itself: logic errors, type mismatches, resource exhaustion, security vulnerabilities. Static analysis, type checking, and unit tests catch most of these. These are the failure modes that static analysis was designed for, and it handles them reasonably well.
Cross-service cascade failures are failures triggered by a service change that breaks a dependent service. The changed service might work perfectly in isolation. Its unit tests pass, its type checker is clean, static analysis finds nothing. But it made a behavioral change — a different response structure, a stricter validation, a new rate limiting behavior — that a downstream service wasn't expecting. Static analysis of a single service cannot catch this class of failure by definition. It doesn't know about the downstream service.
Platform engineering teams that have invested heavily in static analysis and still see a steady rate of production incidents are often primarily experiencing cross-service cascade failures — precisely the failure mode that static analysis cannot address.
The specific gaps in static-only pre-deploy analysis
It's worth being concrete about where the gap is, not just asserting that one exists.
Static analysis runs on a single repository or service boundary. It does not have a model of other services. When your payments-api changes the response schema for /v2/charges — adding a required field that wasn't there before — a static analyzer looking at the payments-api codebase sees nothing wrong. The issue only becomes visible when you ask: which other services call /v2/charges and expect the old schema? That requires cross-service knowledge that static analysis doesn't have.
API contract linting (tools like Spectral for OpenAPI, Buf for Protocol Buffers) gets you closer for interface-defined dependencies. These tools can detect breaking changes against a previous version of a spec. But they still don't tell you which services in your architecture will be affected by a given breaking change. They flag the break; they don't quantify the impact.
How dependency analysis complements static analysis
Dependency graph analysis doesn't replace static analysis. It addresses the gap static analysis leaves: cross-service impact quantification.
The two layers work together in a pre-deploy gate. Static analysis runs first, checking for in-service quality and security issues — this should be a hard block for critical findings. Dependency analysis runs in parallel or immediately after, computing blast radius from the service dependency graph and reporting which downstream services are in the impact zone for this specific change.
Consider an early-stage platform team that ran both checks on their staging pipeline for 60 days before enabling them on production PRs. Static analysis caught 23 issues in that period — type errors, a few security findings, some linting violations. Dependency analysis identified that 8 PRs during that window had blast radius 5 or higher, three of which would have received only one reviewer under the team's existing process. Two of those three were subsequently identified as high-risk by the reviewers who were routed in as additional approvers. Both were caught before production deploy.
Those two catches are not the kind of catch that static analysis delivers. They required knowing the downstream impact surface, not the internal correctness of the changed code.
Building the combined workflow
The practical implementation runs both checks as parallel GitHub Actions jobs (or equivalent) triggered on each PR push. Static analysis produces annotations on the diff. Dependency analysis produces a risk score and a named status check.
The combination gives reviewers two distinct signals before they open the diff: "here are the code quality issues" and "here is the downstream impact surface." Engineers can then allocate review depth accordingly — quick review for low-blast-radius, clean-static-analysis PRs; detailed cross-service review for high-blast-radius ones.
We're not saying static analysis coverage should be reduced. We're saying that organizations that treat static analysis as their complete pre-deploy safety net are leaving a specific category of production risk unaddressed — the exact category that causes cascade failures at 2 AM. The two layers answer different questions, and both questions matter.