Cloudflare has added view-action capture to Audit Logs v2, according to an entry in the company's developer changelog. The logging system now records read activity for endpoints it supports, rather than limiting the record to other action types. The changelog frames the addition as a way to give customers visibility into read activity across Cloudflare products.
The mechanism described is narrow and specific: view actions correspond to GET requests. That mapping matters for anyone who reads audit output, because it means the new records are tied to a request method rather than to a product-specific event name. The changelog does not enumerate which endpoints are covered, describing them only as supported endpoints.
The most consequential operational detail is a default. The Audit Logs v2 dashboard excludes view actions by default, and the changelog states the reason plainly: to reduce noise. The source does not explain why the default was chosen beyond that word, and it offers no measurement of how much noise the filter removes.
That default is a filter, not a data-retention decision. According to the changelog, view actions remain available through the Audit Logs v2 API and through Logpush regardless of what the dashboard filter is set to. Teams that need the read trail can therefore retrieve it programmatically even if the dashboard view stays quiet.
For dashboard users who do want the records, the changelog describes two adjustments. One is to remove the default filter labelled Action type is not view, which brings view actions into the existing view. The other is to set Action type to view, which narrows the dashboard to view actions only. Both are described as filter changes rather than as settings that alter what is collected.
The changelog positions the addition in the context of security investigations and forensic analysis, saying the new actions provide additional context for those tasks. That is the stated purpose in the source; the entry does not include a worked example, a sample investigation, or any measurement of how much additional context the records supply.
For freelancers and small studios that manage Cloudflare accounts on behalf of clients, the practical consequence is a change in what can be reconstructed after an incident. If a client asks who accessed a configuration area, or when a particular read occurred, the answer may now exist in the audit trail where it previously did not, provided the relevant endpoint is among those supported and the query is made through the API or Logpush rather than the default dashboard view.
The default-filter design is a tradeoff worth noting. Cloudflare has chosen to collect the data broadly while presenting it narrowly, which keeps the dashboard usable but means a user who never touches the filter may not realise the records exist. Anyone relying on the dashboard alone for a picture of account activity should treat the default as a starting point rather than a full record.
What remains unknown from the supplied material is substantial. The changelog does not list the supported endpoints, does not state when the change took effect beyond the changelog entry itself, does not describe any API parameter or field names for isolating view actions, and does not say whether the behaviour differs by plan or account type. It also does not state whether historical view activity predating the change is available.
The entry closes by pointing readers to the Audit Logs v2 documentation for more information, which is where those specifics would presumably live. Nothing in the supplied text indicates that the documentation was reviewed for this report, so the gaps above should be treated as open rather than as confirmed absences.
For developers building tooling on top of the audit API, the change is a reminder that filter defaults and data availability are separate concerns. A pipeline that assumes the dashboard's default view matches the API's contents would be wrong here. The safer assumption, supported by the changelog, is that the API and Logpush carry the fuller set.
The broader takeaway for this audience is modest but concrete: an audit surface that previously emphasised changes now also covers reads, with visibility controlled by a filter rather than by collection. Whether that improves a given team's investigations depends on endpoints and tooling the changelog does not describe.
Freelancers who resell or manage Cloudflare setups should verify their own workflows against the documentation before promising clients a complete access history. The changelog supports the claim that view actions are recorded and retrievable; it does not support any claim about completeness, coverage, or fitness for a particular compliance requirement.