Workers Metrics charts, per Cloudflare's developer documentation changelog, now show each release contained within the chosen time range, gradual deployment progression included in full. According to the stated purpose, the aim is to help users connect shifts in memory, CPU time, errors or latency to whichever code was handling traffic at that moment.
The change is about what the chart carries alongside the metric series, not about new metrics. Memory, CPU time, errors and latency were already plotted; the entry describes release annotations being added on top of them, so a chart now records deployment activity as well as performance.
For gradual deployments the entry describes a specific visual treatment. A rollout is not broken into disconnected pieces but appears as a single rollout spanning the chart, with shading that increases as a larger share of traffic moves to the new version. Hovering over that rollout surfaces the previous and new versions, how long the rollout lasted, and the traffic percentage configured at each step.
That hover detail is what makes the annotation a record of configuration as well as of performance. A developer looking at a jump in errors can read the traffic percentage that was set when the metric moved, rather than reconstructing the rollout schedule from deployment logs or a separate dashboard.
Three questions shape how the changelog presents these annotations. Locating the onset of a regression comes first: when errors, latency, CPU time or wall time shifted, the entry says, you can view the traffic percentage that had been configured. Rollout stages form the second question, addressed by examining whether a metric moved as additional traffic was directed to the new version. Rollbacks are the third, showing up as distinct release events, so that recovery of metrics afterward can be verified.
A narrower treatment applies to releases that are not gradual. Individual markers, rather than a shaded rollout, still represent direct deployments routing 100% of traffic to one version. To cut down on visual clutter, nearby direct deployments are grouped together, so the chart does not always function as a one-marker-per-deploy ledger.
The entry also states two explicit exclusions. Versions that are only uploaded, or that are only configured at 0% traffic, do not appear on metrics charts at all. For anyone who stages a build without routing traffic to it, that upload will not show up as an annotation, so the chart cannot serve as a complete inventory of everything pushed to the platform.
Access is described in a single line: to view release annotations, open the Metrics tab for your Worker. The entry does not describe a separate opt-in, a new API, a pricing change or a plan restriction, and it does not say whether the annotations are available to all Workers accounts or only some.
The supplied evidence is one changelog entry, and its date framing needs care. The URL slug carries the date 2026-09-25, and the feed metadata carries a sourcePublishedAt value of 1790294400000. The entry is written in the present tense, describing what the charts now do, but the evidence does not establish a precise rollout date or a phased availability schedule. The event date below is taken from the slug, which is the only explicit date in the material.
For working developers, the practical value is in shortening the loop between a metric change and the deployment that caused it. A freelancer maintaining a Worker for a client can point at a specific rollout step when explaining why latency moved, rather than arguing from memory about which version was live. That is editorial interpretation of the documented behaviour, not a claim Cloudflare makes about time saved.
The feature also has a limit the changelog implies but does not dwell on. Annotations show what was configured and when; they do not attribute a metric change to a cause. A regression that coincides with a rollout step is still a correlation, and the chart will not distinguish a code problem from a traffic-mix change, an upstream dependency or an unrelated platform event.
There is a second limitation in the grouping behaviour. Because nearby direct deployments are collapsed to reduce clutter, a developer investigating a narrow window with several rapid 100% deploys may not see each one as a distinct marker. The changelog does not specify the threshold or distance at which grouping kicks in, so the exact granularity is undocumented in the supplied text.
The 0% exclusion is worth flagging for teams that stage configuration. If a version is configured at 0% and later raised, the chart will not show the earlier zero-traffic state as an annotation, so the visible rollout begins from the point at which traffic was actually assigned. Whether that matches a team's mental model of a rollout depends on how they stage configuration.
Nothing in the supplied evidence describes how the annotations interact with other Workers observability features, whether they can be exported, or whether they are retained beyond the chart's selected time range. Those are open questions rather than documented gaps, and the changelog does not address them.
The update is best understood as an observability refinement rather than a new capability. What changed is that the chart now carries deployment context alongside the existing series, including the intermediate steps of a gradual rollout that were previously harder to see as a single progression.
For a freelancer or small studio, the sensible use is diagnostic: when a client reports that something got slower, open the Metrics tab, find the rollout that overlaps the change, and read the configured traffic percentage at that point before drawing conclusions. The annotation narrows where to look; it does not answer why.
Cloudflare's changelog frames the annotations around three concrete questions — when a regression started, whether a metric changed as traffic shifted, and whether metrics recovered after a rollback. Those are the questions the feature is documented to help with, and the evidence does not support claims beyond them.