Audit Logs

The audit log is a running record of who did what in your organization: who signed in, who changed a setting, and what happened to your subscription. Each entry shows the person, the time, the IP address and the country it came from.

Try this: open Settings → Audit Logs, switch on Hide session sign-ins, and read what is left. That is every change anyone has made recently.

Who can see it

Only owners and admins see the audit log. Editors and viewers do not get the Audit Logs tab at all, because each entry carries another member's IP address.

The audit log is available on every plan. Open it from Settings → Audit Logs.

The log shows only the organization you have selected. If you belong to more than one, switching organizations in the organization switcher switches the log, even when you are an owner or admin of each. An API key reads only the organization it was created in.

What is recorded

Events fall into three categories. The names below are the labels you see in the log.

Account access

These describe a person's sign-in and account security, not a change to the organization.

Event	When it is recorded
Signed in	A new session starts
Signed out	A member signs out of the current session
Session revoked	A member ends one of their other sessions
All sessions revoked	A member signs out everywhere
Failed sign-in attempt	A wrong password for an account that exists
Failed two-factor code	A wrong two-factor or backup code for an account that exists
Password changed	A member changes their password
Password reset requested	A reset link is requested for an account that exists, or one is sent automatically after an email address change is undone (the entry's `cause` is then `email_change_reverted`) or after Pingara support removes two-factor (the actor is then System and the `cause` is `console_two_factor_removal`)
Password reset completed	A reset link is used to set a new password
Two-factor authentication turned on	A member finishes two-factor setup
Two-factor authentication turned off	A member disables two-factor, or Pingara support removes it at the owner's request. In the second case the actor is System and the entry's `cause` is `support_request`
Backup codes regenerated	A member generates a new set of backup codes
Email address change requested	A member asks to change the email address on their account, after entering their current password. The change is held until the new address confirms it
Email address changed	The new address confirms the change and the account's email moves
Email address change cancelled	A waiting change is cancelled: from the link sent to the old address, from the member's Profile tab, because the member changed or reset their password or signed out of every session, or because Pingara support removed their two-factor authentication. The entry says which
Email address change undone	The link in the notice sent to the old address is used after a change went through. The old address is restored, every session is signed out and the password is replaced. API keys the account created since the change was requested are revoked, each with its own API key revoked entry
Email change undo link cancelled	A member cancels the undo link sent to their old address, from Settings → Security → Undo links, after entering their current password. The link keeps working for 24 hours

Each of the first four lists the old address and the requested or new address as the change. The old address is the member's own. In Email address change requested and Email address change cancelled the second address is only the one the member asked to move to, which they may not have confirmed owning, so the log shows it with part of it hidden (for example j***@example.com) and you should not read it as an address that belonged to the account. Only Email address changed shows both addresses in full. Email address change undone shows the address the account moved away from with part of it hidden, and the restored address in full. A cancelled entry has a second change, named cause, that says why the change was withdrawn: cancel_link, settings, password_change, password_reset, sign_out_everywhere, email_change_reverted or support_two_factor_removed. Email change undo link cancelled shows the address the link would have restored with part of it hidden. Like a sign-in, all five appear in every organization the member belongs to. A request that lapses after 24 hours, or is replaced by a newer request, leaves no entry of its own, so a requested entry with no changed or cancelled entry after it means the request lapsed or was replaced.

Failed attempts are recorded only when the email address is typed exactly as the account holds it. A failed attempt against an address Pingara has never seen leaves no trace, so the log cannot be used to find out which addresses have accounts. An attempt typed with different capital letters or stray spaces leaves no trace either, because no password was ever checked against the account. A failed attempt can appear a few moments after it happens rather than instantly.

Subscription

Most of these come from your billing provider rather than from a person, so they show Stripe as the actor and no IP address.

Event	When it is recorded
Subscription started	A paid plan becomes active
Subscription changed	The plan or status of the subscription changes
Payment failed	A payment fails and the subscription moves to past due or unpaid, whichever order your billing provider reports it in
Downgraded to Free	The organization moves back to the Free plan
Subscription restored	A downgraded organization gets its paid plan back
Billing portal opened	An owner opens the Stripe billing portal

Billing portal opened is the one subscription event caused by a person, so it shows that person. Its IP address is the one from the owner's most recently active session, marked via session, not the address of the request itself.

When Pingara support gives an organization a complimentary Pro plan, or takes it away, and the organization's plan actually changes, a Subscription changed entry appears with System as the actor. See Entries made by Pingara.

Settings

Event	When it is recorded
Organization settings changed	The organization's details are edited
Ownership transferred	The owner role moves to another member
Member invited, Invitation cancelled, Member joined	The invitation lifecycle
Member role changed, Member removed, Member left	Changes to who is in the organization and what they can do
API key created, API key revoked	A Developer API key is created or revoked
Alert policy created, changed, deleted	Changes to alert policies
Alert channel created, changed, deleted	Changes to alert channels
Webhook subscription created, changed, deleted	Changes to webhook subscriptions
Webhook signing secret rotated	A webhook subscription gets a new signing secret

Where a setting changes, the entry lists the fields that changed with their before and after values, such as a role going from Editor to Admin.

Entries made by Pingara

Some entries have System as the actor, which means the platform did it rather than a member of your organization:

When Pingara support deactivates a user account, that person's API keys are revoked, and each key gets an API key revoked entry in the organization the key belongs to.
When a member undoes a sign-in email change, every API key that account created at or after the change was requested is revoked, in any organization, and each key gets an API key revoked entry in the organization the key belongs to. The entry's cause change reads email_change_reverted.
When Pingara support removes a member's two-factor authentication at their request, you see Two-factor authentication turned off and Password reset requested, both with System as the actor and the member as the target. The entries' cause changes read support_request and console_two_factor_removal. If an email address change was waiting, it is cancelled too, and Email address change cancelled appears with System as the actor and the cause support_two_factor_removed. See If Two-factor Authentication Locks You Out.
When Pingara support changes a member's role, you see Member role changed, or Ownership transferred if the owner role moves to someone new.
When Pingara support grants or removes a complimentary Pro plan, you see Subscription changed, as above.

The Pingara staff member involved is never named in your log, and the reason they gave is not copied into it. System entries have no IP address.

What an entry never contains

Entries hold names, labels, roles, plans and statuses, and nothing that could be used to reach into your systems. The log never shows a webhook URL, an alert channel's address or routing key, the contents or hash of an API key (only its name), a webhook signing secret, a password, or a two-factor secret or code. When you rotate a signing secret, the entry says that it was rotated, not what the new value is.

IP address and country

Each entry shows the IP address the event came from and the country that address resolves to.

Sign-ins, sign-outs, session revokes, failed sign-ins, password changes and resets, email address change requests, confirmations, cancellations and undos, two-factor changes, API key creation and revocation, and webhook subscription changes record the IP address of the request itself. For an email change, that includes the request made from the link in an email: a confirmation, a cancellation or an undo shows the address the link was opened from.
Changes made in the browser, such as editing the organization, changing a member's role, creating an alert policy, or opening the billing portal, show the IP address of that member's most recently active session, marked via session. This is usually the same machine, but it is not proof of where the request came from, so do not treat a via session address as evidence in a dispute. Read it as a hint.
Stripe and System entries have no IP address, because nobody in your organization made the request. The cell shows a dash.
Some events have no usable address, for example when a member has no active session carrying one. These also show a dash.

The country comes from IP geolocation, a free lookup service that Pingara shares across the whole platform and limits to a small number of lookups an hour. A brand-new entry can therefore show no country for a while, and a lookup that fails is retried at most once a day. The country fills in by itself once a lookup succeeds. An address that is not on the public internet, such as one on a private network, never has a country. When the service answers for an address but has no country for it, Pingara remembers that for 30 days and does not ask again, so such an entry stays blank rather than being retried.

Entries made with an API key

A webhook subscription change made through the Developer API shows the person who created the API key as the actor, with via API key and the key's name underneath. That person did not make the change in the app themselves. The key's name is the one it had when the request was made.

Sign-ins appear in every organization you belong to

A sign-in belongs to a person, not to an organization. If you belong to three organizations, your sign-in, sign-out, failed sign-in, password, email address and two-factor events appear in all three audit logs, so each owner and admin can see how their members access the account. Settings and subscription events appear only in the organization they affect.

Filter the log

Two controls sit above the table:

Event type shows only one kind of event, for example API key created. The list is grouped by the three categories above.
Hide session sign-ins removes Signed in entries. Sign-ins are by far the most frequent event, so hiding them is the quickest way to find a change someone made. It applies only while Event type is All events; once you pick one event type, the switch is disabled.

Use Load older entries to go further back. The log lists the newest entries first. While you page back, the table keeps every entry it has shown, including ones that new events push off the first page, so nothing disappears between two presses of Load older entries.

When a filter hides most of what Pingara has just read, a page can come back empty even though older entries remain. The log then says that no matching entries were found yet and offers Load older entries, so keep going before concluding that nothing matches. If the log shows a notice that it has stopped refreshing, Pingara was updated while the tab was open or your session expired. Reload the page.

How long entries are kept

Entries are kept for 90 days and then deleted automatically. Deleting an organization deletes its audit log with it.

If you need a longer record, read the log through the API on a schedule and store it in your own systems.

Query the log through the API

The settings tab covers the common questions. For anything else, the Developer API has a GET /api/v1/audit-logs endpoint that filters by actor, email address, IP address, event type and date range, and returns the same fields shown here.

Audit log access is its own API key permission. Only a key that carries the audit:read scope, together with read, can read the audit log, and only while the person who created it is currently an owner or admin of the organization. Neither the Read only nor the Read & write choice includes it, because the log holds your members' IP addresses. Tick Audit log access when you create a key in Settings → API & Webhooks to give a key the scope. It is off by default, and keys show an Audit log badge when they have it.

Keys created before this permission existed do not have it, so they can no longer read the audit log. To keep an integration working, create a new key with Audit log access. Review the keys that carry the Audit log badge, and revoke any you no longer need. A key stops working for the audit log as soon as its creator is no longer an owner or admin, although it keeps working for everything else.

Frequently asked questions

Why can't I see the Audit Logs tab?

Your role in the current organization is editor or viewer. Ask an owner or admin to change your role, or to read the log for you. See Managing Your Team for what each role can do.

Can I edit or delete an entry?

No. Entries are written by Pingara at the moment something happens, and nobody in your organization can change or remove one. They expire after 90 days.

Why does an entry say "via session"?

The change was made in the browser, where Pingara cannot see the exact request address. It shows the IP address of the member's most recently active session instead. That is usually the same machine, but it is not proof of where the request came from.

Why is the country blank?

The country is looked up after the event is recorded, using a shared lookup service with an hourly limit, so a new entry can wait a while. A failed lookup is retried at most once a day. An entry with no IP address, or an address on a private network, never has a country.

Why does an entry say "via API key"?

The change was made through the Developer API with that API key, and the actor is the person who created the key. See Entries made with an API key.

Does the log record every setting?

No. It covers the events above: sign-ins and account security, the subscription, the organization, members, API keys, alert policies and channels, and webhook subscriptions. Everyday work such as creating a monitor or acknowledging an incident is not in the audit log.

Next Steps

Managing Your Team - Roles and who can see the audit log
Developer API - Query the audit log with filters
Billing and Plans - What the subscription events refer to