A histogram bucket cannot be changed retroactively

Bucket boundaries are chosen before any data exists, and re-bucketing loses the history rather than recomputing it.

// chosen around the thresholds that matter, not a neat curve
$registry->getOrRegisterHistogram(
    'app', 'http_request_duration_seconds', 'duration',
    ['route', 'status'],
    [0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]
);

// the SLO threshold is 0.5, so 0.5 must BE a boundary —
// otherwise the percentile has to interpolate.

Including the objective threshold as an explicit boundary is what makes the good-events query exact rather than interpolated, and it is the single most useful rule when choosing buckets. Every bucket is a series per label combination, so a twelve-bucket histogram across four routes and three statuses is 144 series before anything else. Starting narrow and adding buckets later is possible; removing them without losing comparability is not.