In my experience metrics are not a very reliable tool to gauge code quality. They are useful to a certain limited extent, if used as an indicator rather than an absolute measure. And they can cause even more harm if used without thinking or overzealously.* Ultimately only the expert developers familiar with the code can assess its quality. So I wouldn't spend an inordinate amount of time trying to "perfect" automated metrics - IMHO team members' energy is probably more efficiently used to fix blockers or work on value generating tasks instead.
Once they are set up and tailored to our needs, I prefer to use criteria similar to what @yegor256 describes in his answer. IMHO it may be enough to do a full review of the metrics a few times a year. I would rather look at it from the other end of the pipe: whenever we find a code defect (in the broadest sense), inspect how it could have been prevented. If we find that better code quality metrics or different evaluation criteria would have prevented it, change the rules accordingly.
* Recently in one of our projects, higher management requested that all issues brought up by an automated code quality metrics tool be fixed. And the task was given to a junior developer who completed it to the letter... The end result was a stinking heap of mysterious bugs all over the codebase (mysterious until we realized their source, that is).