KiCad DRC Settings: Severity, Exclusions, and CLI Flags

What the settings control

The design rule check compares your board against the constraints in Board Setup and any custom rules, then reports each failure. Three things decide what you see: the limits (track width, clearance, drill, and so on), the severity assigned to each type of violation, and the exclusions you added. This article covers the second and third, plus the checkbox and command-line flags that make the check trustworthy.

Violation severity

Open Board Setup, then Design Rules, then Violation Severity. Every violation type can be set to Error, Warning, or Ignore. The defaults are reasonable for most boards. Changing them is a decision you should be able to explain.

A sensible policy for a board that will be sent to a fab:

• Leave as errors: shorting items, unconnected items, track and pad clearance, copper-to-edge clearance, hole clearance, annular width, hole size, and anything else that changes what is physically built.
• Warnings are fine: items that affect appearance or reviewability, such as silkscreen overlap or unusual text sizes, provided you have looked at them.
• Ignore sparingly: only turn a type off if you understand why it cannot matter for this board, and write the reason in the project notes. Ignoring “lib footprint mismatch” because it is noisy hides the fact that the board no longer matches the library.

Severity settings are saved with the board, so a colleague or a CI job sees the same policy. That is a strength and a risk: someone can quietly downgrade an error. Reviewing the severity table in a pull request catches that.

Exclusions

Right-click a marker in the DRC dialog and choose to exclude it. KiCad lets you add a comment. Use it. An excluded violation is a signed statement that you looked at this specific case and accept it, for example a test pad deliberately close to the edge.

Good practice:

• Exclude individual markers, not whole categories.
• Write why in the comment so someone else can judge it later.
• Re-check exclusions when the area is edited. An exclusion tied to an old position can hide a new problem.

The DRC dialog can show the excluded list so you can audit them before release.

Options worth knowing

Refill all zones before DRC. The dialog has a checkbox for this. Zone fills are cached, so without it DRC may test an out-of-date copper pour. Keep it on when you check for release.

Test for parity between PCB and schematic. This checks that footprints, values, and nets in the board match the schematic. Without it a board can pass DRC while no longer matching the circuit you drew. More on that in schematic parity.

Report all errors for each track. Useful while debugging, noisy for a final check.

Run it from the command line

The same engine runs headless, which is what you want in a script or CI job:

kicad-cli pcb drc --output drc.json --format json --severity-all --exit-code-violations board.kicad_pcb

--exit-code-violations makes the command return a non-zero exit status when violations are found, so a script can stop. The severity flags choose which levels to report, and the report format can be JSON or plain text. Check kicad-cli pcb drc --help for the options in your installed version, because flags have changed between releases (see KiCad 9 vs 8).

Two cautions for automation. First, exclusions and severities travel in the board file, so the command-line result matches the GUI only if both read the same file. Second, a clean DRC does not prove the board is releasable: it does not check the BOM, the exported files, or the schematic. The MakeIRL gate combines these in one report; the sequence is described in headless KiCad with kicad-cli.

A release-day sequence

1. Refill all zones.
2. Run DRC with parity testing on.
3. Open the excluded list and re-read each comment.
4. Fix or justify every error and warning.
5. Run the same check headless and confirm the result matches.
6. Plot the files and inspect them (Gerber viewer check).