Server Logging & Log Retention

Athena writes its own diagnostic log to disk on the server — a plain-text file you can open when you need to see exactly what the service did, when, and why. Settings → Logging is where an Admin controls how verbose that log is, where it is written, and how long old files are kept before they are cleaned up. This is the on-premises equivalent of tuning a System Center or PDQ server's own logging — no telemetry leaves your network; everything lands in a folder you choose on your own host.

Where to find it#

Open Settings and choose the Logging tab. It is divided into three sections:

• Log Levels — how much detail the server records (this page, below).
• Log Storage — the log directory and how many daily files to keep (below).
• Audit Forwarding — sending audit events to a syslog/SIEM server. That is a separate feature documented on Audit Forwarding to SIEM.

Reading and changing Logging settings both require the Admin role. The whole Settings area is Admin-only, and every save is written to the audit log (see Auditing).

Log levels#

The Log Levels section sets how verbose the server log is. There are two independent levels so you can turn up detail for Athena's own activity without drowning in low-level web-framework chatter:

Each level is chosen from a dropdown, from most to least detailed:

Log storage & retention#

The Log Storage section controls where the files live and how many are kept:

Athena rolls the diagnostic log once per day. Each day's file is named athena-YYYYMMDD.log inside the log directory — for example athena-20260721.log — so files sort chronologically and are easy to pick out by date. The server keeps the most recent files and prunes the rest according to the retention window above.

Using the log for troubleshooting#

When something on the server misbehaves — a failed startup, a certificate problem, a background job that didn't run — the diagnostic log is the first place to look. Open the most recent athena-YYYYMMDD.log in the configured Log Directory. Each line is timestamped and tagged with a severity such as INF, WRN, or ERR, and includes the component that produced it, so you can scan for the moment a problem started.

• Reproduce a tricky issue with the Default Log Level temporarily set to Debug to capture more context, then restart to apply it.
• Correlate a server-side error with the audit log (for the "who/what") and the health endpoints (for "is the service up?").
• Keep enough retention that you can still investigate an incident reported a few days late — the 30-day default is a reasonable starting point; raise it if your change-review cycle is longer.

Roles#

Reading and changing Logging settings is restricted to Admin users — the entire Settings area, its REST endpoints, and the matching PowerShell cmdlets all require the Admin role. See Roles & Permissions.

REST API#

Logging settings are exposed under api/settings/logging. Both operations are Admin-only.

A typical update body:

# Keep two weeks of logs and quiet the framework chatter
PUT api/settings/logging
{
  "defaultLogLevel": "Information",
  "aspNetCoreLogLevel": "Warning",
  "logDirectory": "Logs",
  "logRetentionDays": 14
}

Invalid values return 400; an unauthenticated call returns 401, and a non-Admin caller 403. A successful update returns a confirmation message.

PowerShell#

The PowerShell module reads and writes logging settings by category with Get-AthenaSettings and Set-AthenaSettings. Fetch the current object, change a field, and put it back:

# Inspect the current logging configuration
Get-AthenaSettings -Category Logging

# Fetch, tweak, and save back
$logging = Get-AthenaSettings -Category Logging
$logging.DefaultLogLevel  = "Debug"
$logging.LogRetentionDays = 14
Set-AthenaSettings -Category Logging -Settings $logging

# Preview a change first with -WhatIf
Set-AthenaSettings -Category Logging -Settings @{
  DefaultLogLevel  = "Information"
  LogRetentionDays = 30
} -WhatIf

Get-AthenaSettings accepts -Category General, Security, Agent, Scheduler, Database or Logging (omit it to get everything). Set-AthenaSettings supports -WhatIf / -Confirm so you can preview a change before applying it. All of these require an Admin session.

Configuration file#

Logging settings are stored in the server's appsettings.json under the Logging section, so you can also set them at install time before the console is even up. The keys map to the fields above:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    },
    "Directory": "Logs",
    "RetentionDays": 30
  }
}

Editing the file directly requires a restart to take effect, exactly as a change made in the console does. See Configuration for the full settings file.

Auditing#

Every save to Logging settings is recorded in the audit log with the Admin who made the change, so you have a record of when verbosity or retention was adjusted. If you forward audit events to a SIEM, those changes flow there too — see Audit Forwarding to SIEM.

Recommendations#

• Leave the Default Log Level at Information for everyday running; drop to Debug only while actively troubleshooting, then restore it.
• Keep the ASP.NET Core Log Level at Warning so routine web traffic doesn't bury Athena's own messages.
• Set Log Retention to cover your incident-review window — the 30-day default is a sensible baseline; increase it if you investigate reports days or weeks after the fact.
• In a container deployment, put the Log Directory on a mounted volume so logs survive restarts and can be collected by host-side tooling.
• Schedule logging changes near a maintenance window, since the new configuration applies on the next server restart.