The question a shared login cannot answer
Most small teams start with one set of credentials. It works until the first incident, and then it fails in a very specific way: something changed, the change is visible, and nobody can say who made it or what it replaced.
That gap costs more than the embarrassment. Without a record you cannot tell a mistake from an intrusion. You cannot undo the change confidently, because you do not know the previous value. And you cannot improve the process, because "be more careful" is the only lesson available when nobody knows what actually happened.
There is an outside view as well. A reviewable trail of administrative actions and meaningful access control are standard expectations in security questionnaires and in frameworks like ISO 27001, and data-protection regimes such as KVKK and GDPR expect you to be able to show who had access to what. Whether or not you are certifying anything, the requirement describes something you want for your own sake.
What gets recorded
The activity history covers the changes that can affect what visitors see: cache purges, DNS record changes, delivery rule changes, security preset changes — including HSTS and the country and ASN blocklists — certificate actions and hostname changes.
Each entry carries four things that make it useful. Who: the actual person, so a sub-user appears as themselves rather than as "the account". When. Which account and path the change touched. And before and after, so the previous value is there instead of being something you reconstruct from memory.
That last field is what turns the log from a report into a tool. "Delivery rule changed" tells you where to look. "Cache TTL 3600 → 60" tells you what happened to your origin traffic at the same moment.
Reading it while something is broken
Open the account sidebar, then Monitoring → Activity history — /management/cdn/activities.
During an incident, a sequence that works: narrow to the window you care about, look at the whole account rather than only the change you already suspect, and read the before/after values instead of the entry titles. The change that broke the site is frequently not the one you had in mind, and the giveaway is usually the ordering — two entries by different people five minutes apart is generally the whole story.
Filtering by action type is what makes a busy account readable. A site with an automated purge on every publish generates a great many entries that are not what you are looking for; filter those out and the handful of configuration changes left is short enough to read in full.
Outside an incident, the same page answers a quieter question: is anything changing that nobody mentioned? That is worth five minutes a month.
Reaching it from the API
The history is available over the API as well, which is what you want if you archive it, forward it into your own logging system, or simply keep more of it than you feel like scrolling through. action_type takes the same categories as the filter in the panel, and the endpoint only ever shows you accounts your token is allowed to see.
The last 25 purges on one account
curl -s -H "Authorization: Bearer $TOKEN" \
"https://cdn.com.tr/api/accounts/<account-uuid>/activities?per_page=25&action_type=purge_cache"Three roles, and what each one is for
A log tells you what happened. Roles reduce what can happen. A sub-user on cdn.com.tr gets one of three.
Viewer reads everything the account shows and changes nothing except their own profile and password. This is the right role for a manager who wants the graphs, an agency reporting on performance, or anyone who needs to look during an incident without being able to make it worse.
Editor does the operational work: purge cache, edit delivery rules, manage DNS records, certificates and hostnames. What an editor cannot do is change the shape of the account itself — no creating or removing sub-users, no billing, no deleting the account. This is the role for the people who run the site day to day.
Owner does all of it, including the three things an editor is deliberately kept away from. It is the account holder, and it should stay a very short list.
Two details worth knowing. If a sub-user is created without a role being chosen, they become a viewer — the safe end of the scale, so a forgotten field can never hand out more than you meant. And the roles are enforced for API tokens exactly as they are in the panel: a viewer's token can read and cannot write, so a script run by somebody who may not change DNS cannot change DNS.
Adding somebody, with the access they need
Go to Authorization — /management/authorization — and choose New user. Fill in their details and pick the role before saving; it is the field that decides everything else about what that person can do.
Two habits make this work in practice. Give each person their own login rather than sharing one: the activity history is only as useful as the names in it, and "purged by the shared account" is the same dead end you started from. And when somebody joins for a specific piece of work — a migration, an agency engagement, a contractor — give the role that piece of work needs and remove them when it ends. Dormant access that nobody is accountable for is the most common finding in any access review, and the easiest one to avoid.
Least privilege without being annoying
Least privilege has a bad reputation because it is usually implemented as "ask me every time", which people route around within a week. The version that survives contact with a working team is simpler.
Default everyone to viewer and promote on request. It costs one message the first time somebody needs to purge, and it means nobody is carrying access they never asked for.
Give editor to the people whose job is to change things — and notice where the boundary is drawn: an editor can do everything that fixes a live site and nothing that changes who else holds keys or what you are billed. That is the line you actually care about, and it is why the role is not a compromise.
Keep owner for the people who answer for the account, and act on changes the day they happen. The log records what was done, not who should still be able to do it; that part stays yours.
The two features are one control
It is tempting to treat the log as the security feature and the roles as administration. It works the other way round.
Roles are prevention. They decide what is possible at all, which is the only thing that stops an accident before your visitors see it. The log is detection and accountability: it tells you what was done, by whom, and what the value used to be.
Neither is worth much alone. Roles without a record mean you trust a boundary you can never check. A record without roles means you can describe every incident perfectly and prevent none of them. Together they answer the question that actually gets asked after an outage — never "what is a CDN", always "who changed this, and why were they able to?"
Frequently asked questions
Does the log show individual sub-users or just the account?
Individually. The entry records the real person who made the change, so a sub-user appears under their own name rather than as the account owner. That is the whole point: a log that says "the account did it" answers nothing you did not already know.
How do I find out who purged the cache?
Open Monitoring → Activity history on the account, filter by the purge action type, and find the entry at the time in question. It shows the person, the exact time and the path or pattern that was purged.
What is the difference between viewer and editor?
A viewer can look at everything and change only their own profile and password. An editor can do the operational work — purging, delivery rules, DNS records, certificates and hostnames — but cannot add or remove sub-users, cannot touch billing and cannot delete the account.
What happens if I create a sub-user and forget to pick a role?
They become a viewer. The default is deliberately the read-only end of the scale, so an unfilled field never quietly grants more access than you intended.
Do the roles apply to API tokens as well?
Yes. The API enforces the same roles as the panel, so a bearer token belonging to a viewer can read and cannot write. Access is decided by who the person is, not by which door they came through.
Can I keep the history somewhere of my own?
Yes — the activities endpoint is the export route. Page through it with a bearer token, filtering by action type if you only want a subset, and store the JSON wherever you keep your records.