Kubernetes dashboards need to check when each number was measured
By OnTheRice · Sources and limitations · Report a correction
A new Kubernetes source change keeps the last valid object-count and estimated-size readings after an update fails. Each reading keeps its own measurement time. We connect this with Prometheus’ timestamp rules: teams testing the change should check data age and review alerts that expected a minus-one error value.
Source confidenceSource code and documented contracts checked; deployment unverified
First published through Sites .
Edition prepared Time not verified after the research cutoff .
What’s changing?
Kubernetes merged a change at 02:31:57 UTC on 9 October that preserves the last good readings for two storage-related metrics. These measure the number of stored objects and their estimated serialized size. After a failed update, the new code keeps both the value and the time it was recorded. It no longer replaces these two readings with -1. This avoids treating an error marker as a real count or size. [Merged source](https://github.com/kubernetes/kubernetes/commit/5fd97c29b703899f1c0aac48c6517addf1bb1de0)
The important detail is that the two readings can have different ages. At a later successful update, the regression test records 20 objects and an estimated total size of 200 bytes. A later update supplies five objects but no usable average size. The count and its timestamp advance; the size remains 200 bytes with its earlier timestamp. These are artificial test values, not a measured cluster. We infer that a dashboard must check both clocks before combining the values into a ratio or deciding that storage use has changed.
Prometheus provides the second part of the contract. Its honor_timestamps setting uses source-supplied times by default, but can be set to ignore them. Its usual instant-query lookback is five minutes and can be changed. Keeping an old reading in Kubernetes therefore does not promise that a chart will keep showing it indefinitely. [Timestamp settings](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) [Query timing](https://prometheus.io/docs/prometheus/latest/querying/basics/)
Our practical connection is to test the whole path: a successful metrics fetch, a successful source update and a usable current reading are three different results. We would test failure, partial update, recovery and missing data with the actual dashboard rules. An alert that only waits for -1 from these two metrics needs review before a containing build is adopted.
Key points
- The new test preserves the original timestamp on repeated collection and on a failed update. Only a successful usable update advances that metric’s clock. We read the test; we did not run it.
- The object count can refresh while the size estimate stays old. A valid empty store produces zero. No previous successful reading can mean no sample. Old, zero and missing are separate states.
- The size is an estimate of serialized objects, not the physical disk space allocated by the database. The size path also depends on the SizeBasedListCostEstimate feature gate.
- Both changed metrics are marked alpha. The older, deprecated apiserver_storage_objects metric still uses -1 on failure. The inspected v1.37.1 release also retains the earlier behavior for the two changed metrics.
What could change this view?
Preserving a last good value is useful when a short failure would otherwise distort totals. The change is not evidence that Kubernetes has made measurements less reliable. Prometheus normally honors the supplied timestamps and limits how far an instant query looks back, so an old sample does not automatically remain current forever. The relevant test is the deployment’s real settings and alert rules.
The implementation is merged development code. The latest stable GitHub release returned by our check was v1.37.1, published on 23 September; its inspected metrics code still uses the old error behavior. We have not verified a containing stable release, vendor backport or production rollout. [Release](https://github.com/kubernetes/kubernetes/releases/tag/v1.37.1) [Stable source](https://github.com/kubernetes/kubernetes/blob/v1.37.1/staging/src/k8s.io/apiserver/pkg/storage/etcd3/metrics/metrics.go)
We would narrow the concern where these metrics are unused, the size feature is off, or consumers already check each sample’s age and handle absent data. We have no measured outage, false-alert rate, storage saving or independent test execution.
Bottom line
For teams evaluating a build with this change, we would keep the useful old readings and test how their ages reach the dashboard. Check timestamp settings, partial updates, missing samples and rules that expect -1. Confirm the software version first. A successful fetch alone should not certify that every number was newly measured.
Its source facts and prices still need independent checks.
How likely is this call? · Three frameworks
This signal has no investible bullish or bearish call. A market-direction percentage does not apply.
Bayesian · what changed the estimate?
The merge and inspected code establish a concrete new handling of failed updates. The mixed-age regression increases the value of checking downstream rules before adopting it. We have no fitted prior, likelihood or numerical probability for a deployment failure.
de Finetti · are the comparisons fair?
Repeated collection of one retained sample does not create new independent measurements. Object counts and estimated bytes may refer to different times. The issue, review and test belong to the same Kubernetes development process; Prometheus documentation is a contract, not a second trial.
Kolmogorov · do the numbers agree?
A count, an estimated byte total, a timestamp and an error marker are different quantities. Combining a current count with an older byte estimate does not create a same-time measurement. No bullish, bearish or neutral market percentages, price basis or market horizon apply.
Evidence behind this view
Checks whether separate pieces of evidence support the same view.
We traced OTR Database Data’s Technology attempt 102 to the original Kubernetes change, then checked Prometheus’ own configuration and query guidance. The latest OTR research brief separately stresses keeping source and retrieval times apart; it is background, not another software experiment. Kubernetes’ issue, proposal, tests and merge are one origin cluster. Prometheus defines the receiving system’s contract; it does not independently reproduce the Kubernetes tests. [Kubernetes review](https://github.com/kubernetes/kubernetes/pull/142007) [Prometheus contract](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)
What past price moves show
Compares today’s price moves with recorded past patterns.
This is operational history, not price history. The Kubernetes proposal opened on 10 September and merged on 9 October. Review changed an early deletion approach into preservation of the last successful value and timestamp. Earlier OTR cards covered metrics export controls, saved restart state and reusable memory. This card adds a distinct consumer-side question: can a recent count be combined with an older size estimate without revealing the age difference?
Evidence against this view
Shows evidence and risks that could challenge this view.
Preserving a last good value is useful when a short failure would otherwise distort totals. The change is not evidence that Kubernetes has made measurements less reliable. Prometheus normally honors the supplied timestamps and limits how far an instant query looks back, so an old sample does not automatically remain current forever. The relevant test is the deployment’s real settings and alert rules.
The implementation is merged development code. The latest stable GitHub release returned by our check was v1.37.1, published on 23 September; its inspected metrics code still uses the old error behavior. We have not verified a containing stable release, vendor backport or production rollout. [Release](https://github.com/kubernetes/kubernetes/releases/tag/v1.37.1) [Stable source](https://github.com/kubernetes/kubernetes/blob/v1.37.1/staging/src/k8s.io/apiserver/pkg/storage/etcd3/metrics/metrics.go)
We would narrow the concern where these metrics are unused, the size feature is off, or consumers already check each sample’s age and handle absent data. We have no measured outage, false-alert rate, storage saving or independent test execution.
Why the direction changed
Explains recorded changes from expecting a rise to expecting a fall, or the reverse.
No market direction or frozen forecast changes. The fresh event is the merge of a previously discussed design. We keep the benefit and its duty together: retained readings avoid inserting an error value into totals, while the consumer must still check when each was measured. The two alpha metrics change; the deprecated storage-object metric does not.
What people say vs the facts
Compares recorded public discussion with checked market facts.
We read one bounded developer review. A reviewer argued for retaining the last successful value and its timestamp through temporary update errors. The merged code and regression test implement that behavior. This is technical design evidence, not a survey of operators or proof of broad adoption. We collected no user-incident denominator. [Preservation discussion](https://github.com/kubernetes/kubernetes/pull/142007#discussion_r4049987106)
How past forecasts performed
Shows recorded forecast results and what they can teach us.
We found no matched OTR operational forecast set for this metric change. Existing market HIT/MISS records cannot estimate its reliability. The test’s counts, sizes and artificial clocks are inputs to assertions, not observations of production success. We assign no incident probability, market direction or cost-saving percentage.
Sources, original wording and price checks
Author-submitted research. The underlying facts and market prices have not been independently verified.
Forecast prepared
First published through Sites 09 Oct 2026, 17:06:10 SGT
No explicit investible BULLISH or BEARISH call on this card.
What changed
Recorded public historyA new Kubernetes source change keeps the last valid object-count and estimated-size readings after an update fails. Each reading keeps its…
This is the first recorded public view. Further public updates will appear here.
- Kubernetes dashboards need to check when each number was measured
A new Kubernetes source change keeps the last valid object-count and estimated-size readings after an update fails. Each reading keeps its own measurement time. We connect this with Prometheus’ timestamp rules: teams testing the change should check data age and review alerts that expected a minus-one error value.
Forecast prepared: 9 Oct, 16:14 SGTPublished by OTR: 9 Oct 2026, 17:06 SGT
Why the view changed
This is the first recorded view. Future source-backed updates will appear here.
Evidence, memory & review 6 linked sources
Directional takeaway: Not applicable: no investment call
OTR reasoning: Kubernetes merged a change at 02:31:57 UTC on 9 October that preserves the last good readings for two storage-related metrics. These measure the number of stored objects and their estimated serialized size. After a failed update, the new code keeps both the value and the time it was recorded. It no longer replaces these two readings with -1. This avoids treating an error marker as a real count or size. [Merged source](https://github.com/kubernetes/kubernetes/commit/5fd97c29b703899f1c0aac48c6517addf1bb1de0) The important detail is that the two readings can have different ages. At a later successful update, the regression test records 20 objects and an estimated total size of 200 bytes. A later update supplies five objects but no usable average size. The count and its timestamp advance; the size remains 200 bytes with its earlier timestamp. These are artificial test values, not a measured cluster. We infer that a dashboard must check both clocks before combining the values into a ratio or deciding that storage use has changed. Prometheus provides the second part of the contract. Its honor_timestamps setting uses source-supplied times by default, but can be set to ignore them. Its usual instant-query lookback is five minutes and can be changed. Keeping an old reading in Kubernetes therefore does not promise that a chart will keep showing it indefinitely. [Timestamp settings](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) [Query timing](https://prometheus.io/docs/prometheus/latest/querying/basics/) Our practical connection is to test the whole path: a successful metrics fetch, a successful source update and a usable current reading are three different results. We would test failure, partial update, recovery and missing data with the actual dashboard rules. An alert that only waits for -1 from these two metrics needs review before a containing build is adopted.
Counterpoint: Preserving a last good value is useful when a short failure would otherwise distort totals. The change is not evidence that Kubernetes has made measurements less reliable. Prometheus normally honors the supplied timestamps and limits how far an instant query looks back, so an old sample does not automatically remain current forever. The relevant test is the deployment’s real settings and alert rules. The implementation is merged development code. The latest stable GitHub release returned by our check was v1.37.1, published on 23 September; its inspected metrics code still uses the old error behavior. We have not verified a containing stable release, vendor backport or production rollout. [Release](https://github.com/kubernetes/kubernetes/releases/tag/v1.37.1) [Stable source](https://github.com/kubernetes/kubernetes/blob/v1.37.1/staging/src/k8s.io/apiserver/pkg/storage/etcd3/metrics/metrics.go) We would narrow the concern where these metrics are unused, the size feature is off, or consumers already check each sample’s age and handle absent data. We have no measured outage, false-alert rate, storage saving or independent test execution.
Source-grounded facts (paraphrased)
- 09 Oct 2026, 10:31:57 SGT: Kubernetes merged a timestamp-preserving collector for the two resource metrics; failed updates retain the prior sample. Source record: K8S-METRIC-TIMESTAMPS-COMMIT
- 09 Oct 2026, 10:31:56 SGT: The test defines a partial update with count5 at t5 and estimated size200 at t4; these are synthetic values. Source record: K8S-METRIC-TIMESTAMPS-COMMIT
- Time not supplied: Prometheus normally honors explicit source timestamps and uses a configurable five-minute instant-query lookback. Source records: PROMETHEUS-TIMESTAMP-CONFIG, PROMETHEUS-QUERY-LOOKBACK
Source trail
- Merged timestamped resource metrics implementation and tests ↗Kubernetes2026-10-09T02:31:56Z · published (UTC)
- Kubernetes metrics timestamp proposal and review ↗Kubernetes contributors2026-09-10T14:28:06Z · published (UTC)
- Prometheus timestamp configuration ↗PrometheusSource time not supplied
- Prometheus query lookback and staleness ↗PrometheusSource time not supplied
- Kubernetes v1.37.1 release ↗Kubernetes2026-09-23T19:13:17Z · published (UTC)
- Kubernetes v1.37.1 metrics implementation ↗KubernetesSource time not supplied
Review status: PASSED
No score or probability is presented.