diff --git a/nix/host-modules/hive-forge/default.nix b/nix/host-modules/hive-forge/default.nix
index edb3b94a..2d937ba4 100644
--- a/nix/host-modules/hive-forge/default.nix
+++ b/nix/host-modules/hive-forge/default.nix
@@ -757,6 +757,26 @@ in
               # service would buy nothing and would be the one that stops
               # getting rotated.
               metrics.ENABLED = cfg.behindGateway;
+              # The two per-dimension breakdowns, on the same condition as
+              # the endpoint itself: `gitea_issues_by_label{label=…}` and
+              # `gitea_issues_by_repository{repository=…}`. Off by default
+              # upstream because they are the only metrics here whose series
+              # count grows with the CONTENT of the forge rather than with
+              # its feature set — so the question is cardinality, and it was
+              # measured rather than assumed.
+              #
+              # Measured on this instance: ~19 distinct labels and ~29 repos
+              # ⇒ **well under 100 series**, against a store that took +2234
+              # from nine host scrapers. Two orders of magnitude below the
+              # cost that already argued against shipping a `process`
+              # scraper, so the breakdowns are affordable here.
+              #
+              # ⚠️ Both grow with repo and label count, not with traffic. A
+              # forge that grew to thousands of repos would want this
+              # revisited — that is a real trigger, unlike a time-based one:
+              # `count(gitea_issues_by_repository)` answers it directly.
+              metrics.ENABLED_ISSUE_BY_LABEL = cfg.behindGateway;
+              metrics.ENABLED_ISSUE_BY_REPOSITORY = cfg.behindGateway;
               # Repo migrations / pull-mirrors fetch from the source
               # URL *inside* Forgejo. hyperhive code is synced from
               # `localhost` (and the host LAN), which Forgejo's