Activity logs

Connection records and the shadowing audit trail on Business and Enterprise plans — what each row contains, how it is collected and how long it is kept.

Updated · ·By Ivan Vyshniak

Nothing on this page changes with your selection.

On Business and Enterprise plans, devices report what happens on the network: which devices connected to which, and every shadowing session on the device being shadowed. You find both under Logs in the console, on the Networking and Shadowing tabs. Viewing them requires the Owner, Admin, IT admin, Network admin or Auditor role.

On other plans, the tabs show an upgrade prompt and nothing is collected. Upgrading doesn't add history: collection starts within about a minute of the upgrade.

Networking tab

Each row summarizes traffic between two devices over about 30 seconds:

ColumnContents
TimeWhen Peerlify received the record.
Source → DestinationThe two devices' overlay addresses and ports. The reporting device is always the source.
ProtoTCP, UDP, ICMP, SCTP, or the protocol number.
TransportDirect, Relay, Mixed (both within the period, typically a switch to direct) or Unknown.
Sent, ReceivedBytes and packets, counted including IP and TCP/UDP headers but not Peerlify's encryption or relay framing.
  • Each device reports its own view, so a connection between two devices usually appears twice, once from each end, with source and destination swapped.
  • A long connection produces a row about every 30 seconds.
  • Internet traffic sent through an exit point isn't recorded.
  • Only IPv4 traffic between devices in the network is recorded.
  • A very busy device may not report every flow: devices report up to 8192 flows per period, and Peerlify stores up to 2000 per report.

Filter by Range and by transport, and search by source or destination address.

Shadowing tab

Records shadowing sessions. Events are written by the device being shadowed.

EventShown asWritten when
startedStartedThe session's helper process started on the target. This happens before the person at the target answers a consent prompt.
terminatedEndedThe session ended, with its duration.
deniedDeniedThe target refused a request to start, with the reason: acl, policy, no_session, session_not_allowed, permission, unsupported or viewer_video_unsupported.
revokedRevokedA running session was ended because the policy changed (policy, acl, session_not_allowed) or the user signed out (no_session).
stopped_by_targetStopped by targetThe person at the target ended the session with Stop or Ctrl+Alt+S (⌃⌥S on a Mac). An Ended row follows.
sas_requestedSas requestedA viewer from an older Peerlify version sent Ctrl+Alt+Del. Current versions no longer offer it.
clipboard_enabled, clipboard_disabledClipboard enabled / disabledThe viewer turned clipboard sharing on or off.
audio_enabled, audio_disabledAudio enabled / disabledThe viewer turned audio on or off.
chat_openedChat openedThe viewer sent the first chat message. Message text isn't recorded.
file_offered, file_sent, file_failedFile offered / sent / failedThe viewer sent a file to the target.

Each row shows the viewer's address or device ID, the target device with its signed-in user or session number, and the reason, the duration, or whether control and consent applied.

What isn't recorded:

  • Consent answers. A session the person at the target declined, or didn't answer within 30 seconds, appears as Started followed shortly by Ended, with no reason.
  • Refusals before a session is requested. When the desktop app lists a device's sessions, a refusal at that step (for example because no rule matches) isn't recorded.
  • The rule that allowed a session, the viewer's name and bytes transferred. These fields exist but are always empty.

The event filter offers Started, Ended, Denied and Revoked. Search matches the viewer's address or device ID, the target device's name and the signed-in user.

Retention

Rows on both tabs are deleted 90 days after they are received.

Next steps

Was this page helpful?