Got a Docker Compose file? Your project goes live in seconds — one command on cdn.com.tr. See how Built your app with AI? From folder to live URL with one command — no git, no registry: cdnctl deploy. See how Code on GitHub? Every push auto-deploys to cdn.com.tr — connect your repo and ship. See how

CDN.com.tr Help

Activity history: who changed what

Every operational change on an account is recorded with the person behind it, the time, and the before and after values. Activity history answers "who purged that path" and "when did this record change" without asking support.

Organization, permissions, support

Activity history: who changed what

Every operational change on an account is recorded with the person behind it, the time, and the before and after values. Activity history answers "who purged that path" and "when did this record change" without asking support.

What makes the history worth reading

An audit log is only as useful as the identities behind it: give each person their own login and the right role.

Named actors

Team roles

Viewer, editor and owner. A shared login makes every row on this page say the same name.

Open the topic
Related page

Notifications and operations

Asynchronous deploy and purge operations and their status, alongside the change record.

Open the topic
Background

CDN activity log and team roles

Why an audit trail and least-privilege roles are usually asked for together, and what to check in a tender.

Read the guide

Panel path

  1. Management Panel
  2. CDN Accounts
  3. Observability
  4. Activity history

Prerequisites

  • You need the web.cms.cdn.activities permission. Owner, editor and viewer roles can all read the page.
  • An account must be selected — the page always shows one account at a time.
  • Only changes made after the audit log went live are listed; older operations were not backfilled.

Decision model

Which filter answers your question?

The Action type filter is the difference between reading three rows and scrolling a week of history.

  • Cache purged: who cleared what, with the purge type and the path count.
  • Setting updated: delivery rules, security presets and the blacklists, with the before and after values.
  • DNS record created or deleted: the record that appeared or disappeared.
  • All: the plain chronology, useful when you know the time but not the kind of change.

Panel or API?

The same records are available both ways.

  • Panel: fastest for one question, and the Detail column is already formatted.
  • API: right when you want the records in a ticket, a report, or your own monitoring.

Step-by-step guide

1

Open Activity history for the account

The page lives in the account sidebar, under Observability, next to Data consumption and Cache overview.

  • Select the account you are investigating.
  • Open Observability, then Activity history.
  • Check the account name in the switcher — the history you are reading belongs to that account only.

Expected result: The table lists Time, User, Action and Detail for the most recent changes on this account.

cdnctl equivalent 
GET /api/accounts/<account_uuid>/activities?per_page=25
2

Filter down to the change you are chasing

Action type plus Per page is usually enough to get the answer on one screen.

  • Pick the action type — for example Cache purged — and raise Per page if the change is older.
  • Click Refresh.
  • Find the row by time, and read the User column for the person behind it.

Expected result: Only the relevant kind of change is listed, with a named actor on every row.

cdnctl equivalent 
GET /api/accounts/<account_uuid>/activities?per_page=25&action_type=purge_cache
3

Read the before and after values

The Detail column is where an audit log earns its keep: it says what the value was and what it became.

  • Read the Detail line of the row: for a settings update it names the setting and shows the change as old value to new value.
  • For a purge, read the paths, the purge type and the path count.
  • Take the actor, the timestamp and the setting name into the ticket or the post-mortem.

Expected result: You can state exactly what changed, who changed it and when, without guessing.

cdnctl equivalent 
GET /api/accounts/<account_uuid>/activities?per_page=25&action_type=settings_update

Verification

  • Make a small, reversible change — purge one path — and confirm it appears in the list with your name on it.
  • The account shown in the switcher matches the history you are reading.
  • A sub-user action shows that sub-user, not the account owner.

Use cases

Something changed and nobody remembers doing it: a DNS record is different, a delivery rule was edited, the cache was purged mid-campaign. With sub-users on the account, "we did not touch it" needs an answer with a name and a timestamp on it.

Quick workflow

  1. Open the account and go to Activity history under Observability in the account sidebar.
  2. Narrow the list with the Action type filter — cache purges, DNS changes, settings updates, certificates.
  3. Read the Detail column: it carries the changed setting and the before and after values, not just the fact that something happened.
  4. If you need the same data in a script or a ticket, call the activities API for the account.

Checks

  • Recorded actions include cache purges, DNS record create and delete, delivery rule and preset changes, certificate operations and hostname changes.
  • The actor is the signed-in user, including sub-users. An action taken by an editor shows that editor, not the account owner.
  • The scope is the account. Each account has its own history, so switch accounts to follow a change on a different one.
  • It is a record, not an undo. Activity history tells you what changed; reverting it is done on the page that owns the setting.