WordPress
Rewrite rules
Rewrite rules is the list of URL patterns WordPress uses to turn a pretty path like /about/ into an internal query such as index.php?pagename=about. They are stored in the database and applied by PHP.
How it is measured
The compiled list lives in the rewrite_rules option as an array of regular expression to query-string pairs. List it with wp rewrite list. Plugins add patterns with add_rewrite_rule() on init, and flush_rewrite_rules() or Settings > Permalinks > Save rebuilds the stored option.
A symptom of stale rules is a 404 on a URL that works with ?p=ID. Run wp rewrite flush to rebuild; on Apache, add --hard to rewrite .htaccess too.
Worked example
A job board registers a post type called listing and a rule so /jobs/remote/ shows only remote listings. In production /jobs/remote/ is a 404. The staging copy works because someone saved permalinks there.
The deploy does not flush rules. Adding a flush to the plugin activation hook and running wp rewrite flush after the release fixes the 404 in seconds.
How it differs
Rewrite rules map a URL to a query inside WordPress, while a permalink is the resulting address a visitor sees. The rules also differ from .htaccess, which only sends requests that do not match a real file to index.php. If a rule is missing, the server still reaches WordPress and WordPress returns the 404.
Common errors
Calling flush_rewrite_rules() on every page load. Registering a rule after init. Forgetting to flush after registering a custom post type. Expecting an .htaccess edit to change WordPress URLs. Writing a pattern that matches too much, like (.+), and swallowing other routes.
In practice
Add rewrite flushing to your deploy checklist whenever a release registers a post type, taxonomy, or rule. Use wp rewrite list on staging to check that a new rule is present before you ship.