KiCad 9 DRC & ERC rules
KiCad hole_near_hole DRC: what it means and how to fix it
Understand KiCad 9's hole_near_hole DRC rule, its MakeIRL S2 gate class, why it fires, and how to fix and verify it. Includes a practical KiCad repair workflow.
Practical PCB integration · KiCad 9 · Manufacturing gate
What KiCad's hole_near_hole rule means
drc:hole_near_hole is a real KiCad 9 rule identifier from the PCB Design Rules Checker. KiCad found drilled features close enough to trigger its near-hole diagnostic, based on their locations and rule context. The identifier is the stable part to use in reports, automation, and severity policy; the human-readable violation sentence can vary with the affected items and KiCad version.
Closely spaced drills can merge, break material between holes, or stress tooling, but the detailed geometry and fab capability decide the outcome.
Start from the marker’s exact items and coordinates. Cross-probe them in PCB Editor → Inspect → Design Rules Checker, then inspect the surrounding net, footprint, symbol, rule scope, hierarchy, or layer state. Do not begin by changing the global rule or adding an exclusion: that can hide the symptom while leaving the wrong connectivity, fabrication geometry, library data, or schematic intent in place.
| KiCad rule ID | hole_near_hole |
|---|---|
| Source | DRC |
| Meaning | holes near each other |
| MakeIRL class | S2 |
| Explicitly recognized | no — safe S2 fallback |
| Primary editor | PCB Editor → Inspect → Design Rules Checker |
Why MakeIRL classifies it as S2
This pinned rule is not explicitly enumerated in the current taxonomy, so MakeIRL's safe fallback makes it visible S2 with recognized=false.
MakeIRL does not trust the severity label saved in a customer’s .kicad_pro. KiCad can be configured to ignore a rule entirely, so the gate authors a server-owned KiCad 9 reporting policy that forces the real catalog to be emitted and then applies its own rule-ID taxonomy. A project exclusion is recorded as evidence but never lowers the classification. Unknown identifiers also remain visible as S2 rather than disappearing or becoming an unjustified blocker.
S1 is reserved for evidence that a board is actually broken or assembly identity is impossible. S2 means a human engineering decision is required and can be acknowledged; it includes fab margins, many schematic conventions, parity drift, and rules whose intent depends on the product. S3 is advisory library, drafting, text, or silkscreen hygiene. This distinction explains why KiCad’s own “error” or “warning” word is evidence, not the release verdict.
How to fix hole_near_hole in KiCad 9
- 01
Move one hole, reduce a valid drill, combine an intentional slot in a fab-supported way, or revise the scoped spacing after fabrication review.
- 02
Open PCB Editor → Inspect → Design Rules Checker, select the marker, and cross-probe every reported item before changing a rule or adding an exclusion. Fix the design or library source so the correction survives the next schematic/PCB update.
- 03
Inspect drill files and the exact DRC item pair, then re-run DRC with the chosen fab's finished-hole and slot rules.
If the marker came from a library defect, repair the controlled symbol or footprint first and update the schematic/board copy deliberately. If it came from a net class or custom rule, confirm the electrical, timing, safety, or fabrication requirement before changing the number. A narrow, documented rule is safer than weakening the global project to make one marker disappear. For parity findings, compare the exact MPN, symbol pin numbers, footprint pads, BOM, and placement output before accepting either side as authoritative.
Verify the correction before release
Inspect drill files and the exact DRC item pair, then re-run DRC with the chosen fab's finished-hole and slot rules.
Save the corrected source files, refill zones when the board contains pours, and rerun the appropriate checker from a clean state. For PCB changes, inspect Gerber, drill, solder-mask, paste, outline, and placement outputs—not only the interactive canvas. For schematic changes, regenerate the netlist/BOM and run Update PCB from Schematic so stale board state cannot survive. Cross-probe the original coordinates and confirm the intended circuit or manufacturing constraint, not merely a zero marker count.
Finally, keep the original finding, the design change, and any remaining engineering acknowledgment in the release record. That gives reviewers a traceable reason why hole_near_hole is resolved, accepted as a deliberate S2 decision, or retained as an S3 advisory. Silencing the rule in project settings is never the fix because it changes reporting, not the board.
Check the design before fabrication
Run the release gate and review hole_near_hole with the rest of the KiCad evidence.
Check a KiCad project→