"Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated.

Severity is an absolute metric, priority is a relative metric.

In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management.

> If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on.

Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority.

Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity.

The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.