Open DevTools and inspect the element first — that answers this in about ten seconds and skips all guessing. Right-click the element, Inspect, and look at the Styles panel: if your rule appears with a strikethrough it's being overridden; if it doesn't appear at all your selector isn't matching or the file isn't loading.
The checklist, in the order that catches the most cases:
1. Is the stylesheet actually loading? Check the Network tab for a 404 on your CSS file. A wrong path is the single most common cause, and nothing about the page hints at it.
2. Is the selector matching? A typo, a class vs id mix-up (`.btn` vs `#btn`), or a nesting assumption that isn't true. In DevTools, if the element's Styles panel never mentions your rule, this is why.
3. Is something more specific overriding you? An id beats a class, a class beats an element, and inline styles beat almost everything. Specificity is why your rule shows struck through. Fix it by making the selector appropriately specific — not by reaching for `!important`, which just moves the problem into the future.
4. Is another rule later in the file winning? With equal specificity, the last one wins. Two rules for the same class in different places is very common in a growing stylesheet.
5. Is the property valid for that element? `width` and `height` do nothing on an inline element like `<span>` until you set `display: inline-block` or `block`. Flex and grid properties on children do nothing unless the parent is `display: flex` / `grid`. This causes a lot of 'my CSS is ignored' confusion.
6. Syntax error above the failing rule? A missing `}` or `;` silently kills everything after it. If a whole block of styles stopped working at once, look at the rule immediately above the first broken one.
7. Cached old CSS? Hard refresh (Ctrl+Shift+R / Cmd+Shift+R). Surprisingly often the culprit when the code looks obviously correct.
The habit worth building: stop reading your CSS looking for the mistake, and start inspecting the element to see what the browser actually computed. DevTools tells you exactly which rules applied, which were overridden and by what, and what the final computed value is. Ten minutes learning the Styles and Computed panels will save you hundreds of hours across a career — CSS debugging is almost entirely a tooling skill, not a memorisation one.