Log Retention Falls to 90 Days, and Two More Defaults You Did Not Choose

The last post here went out on 27 August, so this is the digest for the window since, and the thread running through it is not a feature. Three platform changes landed, each carrying a date, and in two of them what moved is a number you get billed by or measured on. In the third, only a version string moved.

GitHub puts checks and workflow runs on the log retention clock

From 1 October 2026, checks, workflow runs, and statuses follow the same retention rules as artifacts and logs. The changelog is explicit that these objects had been kept for more than 400 days regardless of what a repository had configured, and that the change is not retroactive: raising the setting afterwards will not bring back anything already deleted. The setting itself gets renamed to name all five object types rather than just artifacts and logs.

The announcement gives the new default as 90 days and notes that public repositories cap there. The docs page for repository Actions settings is where the shape of the problem shows up. Private repositories can be set anywhere from 1 to 400 days. Public repositories can be set anywhere from 1 to 90. Managed repositories cannot exceed a cap set by the owning organization or enterprise, and a custom period applies only to objects created after it is set.

So the two cases are not the same change. On a private repository this is a configuration task: move the value off the 90-day default, up to 400, and you land roughly where you were — at the cost of storage billing moving the same direction, which the changelog says plainly. On a public repository there is no value above 90. Whatever your check history was worth after three months, from 1 October you keep it by exporting it or you do not keep it.

That is the falsifiable claim in this post: after 1 October, no available setting keeps checks, workflow runs, or statuses on a public repository past 90 days. A settings page that offers a public repository a larger number, or a separate control for checks distinct from artifacts, would show it wrong.

Anything that reconstructs engineering history from the API — deployment frequency, change failure rate, flaky-test trends, an auditor asking which commit passed which check in March — is reading objects that now expire. That is the audit trail half of the integration problem in why enterprise AI doesn't ship: the pipeline is only as good as the data still in it, and nobody notices a retention default until the quarter they need the record.

Copilot retention moves the other way, on a 28 September deadline

The same platform moved a retention number in the opposite direction in the same week. No earlier than 28 September 2026, Copilot Chat on github.com, GitHub Mobile, and the cloud agent merge into one experience under a single policy, and the changelog states that chat data will be retained for the life of the account rather than the 28 days that applied on github.com. Business and enterprise administrators have to review and confirm that policy before the date; declining it removes Copilot access on github.com and GitHub Mobile.

The same entry also carries a default flip that is easy to skim past: on 28 September the code review effort level changes from Lite to Balanced unless an organization or repository selects Lite explicitly first. The changelog does not price that. The docs page for review effort levels does. Lite is described as fast targeted feedback on common issues and is put at roughly 0.05 to 1 US dollar of AI credits per review. Balanced routes the pull request to a higher-reasoning model for longer analysis and is put at roughly 0.25 to 5 US dollars, and is noted as consuming marginally more Actions minutes as well. A team that changes nothing is accepting a documented worst case per review that is five times the one it has now.

Separately, from 1 October, new Copilot Business and Enterprise seat assignments require payment before the user gets access, charged upfront at the start of the billing cycle, with no prorated refund when a seat is revoked. Prices are unchanged.

Kubernetes graduated a metrics API that nothing has moved to yet

The counterexample arrived on the same days. Kubernetes v1.37 promoted metrics.k8s.io from beta to stable, nearly nine years after it went to v1beta1 in v1.8. The release post is direct that the surface is identical: no renamed fields, no new fields, no change to the CPU and memory values returned. It also says the HorizontalPodAutoscaler controller supports only v1beta1 in this release, with discovery-based version selection planned rather than shipped.

The artifact confirms the same picture from the other end. The compatibility matrix in the metrics-server repository names metrics.k8s.io/v1beta1 as what it serves, with 0.9.x tracking Kubernetes 1.34 and later and 0.8.x tracking 1.31 and later. The version string graduated. Neither the autoscaler controller nor the reference server documents itself as having followed it.

The thread, and what to do about it this week

Two of these announcements changed a number and left the naming alone. One renamed a version and left the numbers alone. Read at announcement speed the three are indistinguishable — each is a paragraph about a default — and which kind you are looking at only appears in the docs page or the repository. Platform defaults are the part of a vendor contract nobody diffs, and this window produced three of them with deadlines inside five weeks.

Concretely, before the dates:

• Before 1 October. For each private repository whose check history is evidence, set the retention period above the 90-day default, up to 400, and accept the storage line moving with it. For each public repository, decide what you export, because 90 days is the ceiling.
• Before 28 September. Confirm the unified Copilot policy or lose access on github.com and Mobile, and select Lite explicitly if you want the review cost profile you have now rather than the one with a five-dollar ceiling.
• On any 1.37 cluster. Run kubectl get --raw /apis/metrics.k8s.io/ | jq . and kubectl get apiservice v1.metrics.k8s.io before assuming anything reads v1. If your autoscaling depends on it, it does not yet.

The general form of the check is the one we argue for when a proof of concept turns into a system in poc to production: write down the numeric defaults your system depends on, and re-read them on a schedule, because the vendor changes them on theirs.