{
  "version": "2",
  "id": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd",
  "title": "Cloudflare adds release and gradual-deployment markers to Workers Metrics charts",
  "summary": "A changelog entry says Workers Metrics charts now mark every release in the selected time range, drawing a gradual deployment as one shaded rollout and showing versions, duration and configured traffic percentages on hover.",
  "body": "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.\n\nThe 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.\n\nFor 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.\n\nThat 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.\n\nThree 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.\n\nA 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.\n\nThe 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.\n\nAccess 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.\n\nThere 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.\n\nThe 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.\n\nNothing 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.\n\nThe 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.\n\nFor 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.\n\nCloudflare'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.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-09-25T18:18:50.638Z",
  "dateModified": "2026-09-25T18:18:50.638Z",
  "eventDate": "2026-09-25",
  "sourcePublicationDate": "2026-09-25T00:00:00.000Z",
  "source": {
    "name": "developers.cloudflare.com",
    "url": "https://developers.cloudflare.com/changelog/post/2026-09-25-release-flows-workers-metrics/",
    "kind": "official-publisher"
  },
  "practicalImpact": "Editorial interpretation: for freelancers and small teams running Workers for clients, the annotations turn the Metrics tab into a first stop when a performance or error complaint arrives, because the chart now shows which rollout step was configured when a metric moved. It narrows the search to a specific deployment window, but it does not attribute cause, so it should be treated as a starting point for investigation rather than a diagnosis.",
  "limitations": "The supplied evidence is a single Cloudflare changelog entry. It does not state availability by plan or account, pricing, retention of annotations, export options, or the threshold at which nearby direct deployments are grouped. The only explicit date is the 2026-09-25 URL slug; the feed metadata carries a separate sourcePublishedAt value, and the entry gives no measured results and no independent verification. The 0% and upload-only exclusions mean the chart is not a complete record of every version pushed.",
  "keyPoints": [
    "Workers Metrics charts now annotate every release in the selected time range, including the full progression of gradual deployments.",
    "A gradual deployment appears as one rollout with shading that grows as traffic shifts; hovering shows previous and new versions, rollout duration and the configured traffic percentage at each step.",
    "Direct 100% deployments still appear as individual markers, and nearby ones are grouped to reduce clutter.",
    "Versions that are only uploaded, or only configured at 0% traffic, do not appear on metrics charts.",
    "Cloudflare documents three uses: locating when a regression started, comparing rollout stages, and confirming rollbacks."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-09-25T18:18:50.638Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://developers.cloudflare.com/changelog/post/2026-09-25-release-flows-workers-metrics/",
      "publisher": "developers.cloudflare.com",
      "title": "Changelog",
      "publishedAt": 1790294400000,
      "fetchedAt": 1790360288354,
      "hash": "c414caf4dea3490f958fa75c7a226107c39f93793eb6c719173b3cf7eeea6124",
      "kind": "official-publisher"
    }
  ],
  "claims": [
    {
      "claim": "Workers Metrics charts now show every release in the selected time range, including the full progression of gradual deployments.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd#claim-1"
    },
    {
      "claim": "A gradual deployment is drawn as a single rollout with shading that increases as more traffic moves to the new version.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd#claim-2"
    },
    {
      "claim": "Hovering over a rollout shows the previous and new versions, the rollout duration, and the traffic percentage configured at each step.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd#claim-3"
    },
    {
      "claim": "Direct deployments sending 100% of traffic to one version appear as individual markers, and nearby ones are grouped to reduce clutter.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd#claim-4"
    },
    {
      "claim": "Versions that are only uploaded, or only configured at 0%, do not appear on metrics charts.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd#claim-5"
    },
    {
      "claim": "Rollbacks appear as separate release events, allowing a check of whether metrics recovered afterwards.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd",
    "markdown": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd.md",
    "json": "https://freelancenews.online/news/cloudflare-adds-release-and-gradual-deployment-markers-to-workers-d3dfa4fd.json"
  }
}