Logs

Every sign-in and what became of it, and a separate record of who changed what. When a customer says it does not work, start here.

Open it now:Logs

Two logs

Tab	Answers
Connection logs	What your program and its customers did: sign-ins, refusals, bans, sessions ending, messages your program sent. Page title: Request logs.
Application logs	What people and tools did to the application: you, your resellers and your integrations generating keys, banning, changing settings. See Application logs below.

Reading a row

A row has a colored type, the time with how long ago, and the message. Under it, the identity of the event: USER for an account or LICENSE for a key, EMAIL, IP, LOC (location), DEV (device), HWID, the build's HASH and SESS (session). Hover a truncated value for the whole of it. Click a key, address or hardware ID to open everything linked to it, or click the row for the event inspector.

Many refusals carry an i button after the message. Hover it, or tap it on a phone, for what the message means. Where one click fixes the cause, the right of the row has a button:

Button	Appears on	Does
Authorize this build	An unauthorized build	Adds the build's hash to the authorized list at once. The program can sign in on its next try. Drop the `.exe` under Builds as well so its code is recorded.
Reset this license	A hardware or IP mismatch	Opens Users filtered to the key.
Extend this license	An expired license	Opens Users filtered to the key.
Manage this license	A paused license	Opens Users filtered to the key.
Search licenses	A key that does not exist	Opens Users filtered to what was typed.
Review the ban	A banned sign-in	Opens Bans filtered to the key, hardware ID or address.
Open Builds, Review Anti-VPN, Adjust geofencing, Open Monitor, Enable application	A removed build, a VPN, a blocked country, too many sessions, a disabled application	Opens the page that holds the setting.
Allow this machine	A network flag	Stops that machine being flagged for this application. Undo it in Automation.

Event types

Type	Means
`SUCCESS`	A sign-in was accepted.
`DENY`	A sign-in was refused. The message says why; Why a sign-in was refused lists every cause and fix.
`BAN`	A ban was applied, by you or by an alert rule.
`DISCONNECT`	A session ended: the program signed out or disconnected, timed out with no check-in for 30 seconds, was ended by an admin, or ended because the key was banned or the application disabled.
`ADMIN`	An action you or a teammate took on a session, such as a kill or a message. The message starts with the person's name in brackets.
`ERROR`	The server hit a problem handling a request.
`WARN`	Worth a look, nothing was refused. A client detection reported by the program, and a failed running-build proof in Log only mode, are both WARN rows.
`LOG`	A message your own program sent with `Network::SubmitLog`.

Account events carry the operation in the message: Register, Account login, Verify (email codes and resends), Redeem and Password reset. For an account row the key column holds the account, shown as USER with the username.

A Client detection row is the SDK reporting that one of its runtime protection checks tripped inside a customer's program. The message names the check and whether the program ended or only reported.

What the page holds

The page loads the newest 100 events of the application. Everything on the page works on those 100: the counters, the search, the filters and Export. Older events are not shown, so filter or search for a specific license or address from the Users or Bans page rather than scrolling back. Connection logs are kept for 180 days.

The list checks for new events every 30 seconds and adds only what is new. It stops checking after 5 minutes without activity in the tab and catches up when you return.

Find things

The strip across the top counts the loaded events by type: Total, Auth OK, Denied, Banned, Errors. Click one to filter, click again to clear.
The filter buttons are All, Success, Denied, Admin, Bans, Errors, and for accounts Register, Account login, Verify, Redeem and Password reset.
Search matches the message, key, username, email, IP, hardware ID, device and location.
Sort by Date or Log type, newest or oldest first.
Live tail checks every 4 seconds and follows new events. A Jump to newest button appears when you have scrolled down. With it off, new events raise a pill that counts them instead of moving the list.
Export downloads the filtered events as atlas-logs-<application>-<time>.csv with the columns timestamp, type, username, license_key, ip, location, device, hwid and message.

Arriving from a key, an address or a ban opens the list already filtered to it.

Clear logs

Clear logs permanently deletes every connection log of the application after a confirmation. It needs the Logs, Clear permission and cannot be undone. The act itself is recorded in the application logs with who did it and how many rows went.

Application logs

The record of who did what to the application: licenses generated, bans made and lifted, settings changed, sessions ended, builds authorized, files uploaded, API keys reset. It loads the newest 500 actions; Refresh reloads it.

Each row names the actor (Owner, Reseller, API for an integration token, or System), the family of action (LICENSE, BAN, SESSION, SETTINGS and so on), what happened in words, the time, who, the thing it was done to and the address it came from. The raw action name is on the row too, handy for a support ticket.
+ details opens the specifics: counts, the keys involved and, for a change, what it was before.
Filter by Actor and Family, or search the action, actor, thing and address.

Use it to answer who turned a lock off at 3 a.m. or which token generated 5,000 keys. It cannot be cleared from the dashboard.

Was this page useful?