No Logs in Endpoints

avatar

In the API Endpoints i get no log, its just emtpy. Anyone else had this problem before?

Version 2026.2.3 running on Windows Server with integrated Webserver

c2dfa326-6d4e-4018-9e22-4389ce742ac0.png

All Comments (14)

avatar

Hello nikopieper,

Thank you for reporting this.

I understand that on PowerShell Universal 2026.2.3, running on Windows Server with the integrated web server, the Log tab for your API Endpoints remains empty.

To help narrow down what part of the endpoint logging is affected, could you please confirm the following?

* Are the API Endpoints themselves executing and returning responses successfully, with only the Log tab remaining empty?
* Does this happen with all API Endpoints or only specific ones?
* If you keep the Log tab open and invoke the endpoint several times, does it remain completely empty?
* Are you expecting to see the automatic request activity in the Log tab, messages generated with `Write-PSULog`, or both?
* Did this behavior start after upgrading to 2026.2.3? If so, what was the last PSU version where you remember the endpoint logs working correctly?

These details will help us determine whether the issue is specific to the live endpoint log view, `Write-PSULog`, or endpoint logging more generally.

Best regards,
Ruben Tapia

avatar

Hello Ruben,

* Are the API Endpoints themselves executing and returning responses successfully, with only the Log tab remaining empty?
Yes API Endpoints are working fine, just no logs.
* Does this happen with all API Endpoints or only specific ones?
With all API endpoints
* If you keep the Log tab open and invoke the endpoint several times, does it remain completely empty?
Yes its completely Emtpy
* Are you expecting to see the automatic request activity in the Log tab, messages generated with `Write-PSULog`, or both?
Nothing is shown, the load more button is disabled
* Did this behavior start after upgrading to 2026.2.3? If so, what was the last PSU version where you remember the endpoint logs working correctly?
I belive it was already not working before, but we just started realy using Endpoints.

avatar

Hello nikopieper,

Thank you for confirming those details.

We will test this behavior today using PowerShell Universal 2026.2.3 and 2026.2.4 under comparable conditions to determine whether we can reproduce the empty API Endpoint Log behavior and whether there is any difference between the two versions.

Once our reproduction is complete, if we confirm the behavior in 2026.2.3, we will proceed with the appropriate internal escalation as a defect affecting that version.

I will update this thread once the testing is complete and we have the results.

Best regards,
Ruben Tapia

avatar

Hello nikopieper,

We completed comparative testing with PowerShell Universal 2026.2.3 and 2026.2.4. In both versions, the API Endpoint executed successfully and the request activity appeared correctly in the Endpoint Log while the Log tab was open. We were therefore unable to reproduce the empty Log behavior you are seeing.

To help us compare your environment with our clean test environment, could you please check whether the same endpoint requests appear under Platform > Logging immediately after invoking the endpoint?

Please also send the following sanitized diagnostic information to me at ruben.tapia@ironmansoftware.com referencing case 55852:

* The PSU system log covering a short time window in which you reproduce the issue. Please include the approximate timestamp and time zone of the test request.
* The relevant logging settings from `appsettings.json`, including `SystemLogLevel` and `SystemLogPath` if configured. Please do not send the complete file.
* If you have logging settings configured in `settings.ps1`, please include only the relevant logging-related lines.
* Please confirm whether the behavior is the same when accessing the Endpoint Log with an account assigned Administrator role.

Please sanitize these files before sending them. Remove credentials, tokens, license keys, cookies, private keys, connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs.

These details should allow us to determine whether the API log entries are being generated and persisted but not displayed in the endpoint-specific Log view, or whether they are being filtered earlier in the logging pipeline.

Best regards,
Ruben Tapia

avatar

Hello nikopieper,

We found one additional configuration detail that may be relevant, and I would like to verify it in your environment before drawing any conclusions.

If you are using a **Database Logging Target** for API logging, could you please check the exact value configured in the **Feature** field?

Specifically, please let us know whether it is set to:

`API`

or:

`Api`

Please do not change the setting yet. We would first like to confirm the current value in your environment and correlate it with the behavior you are seeing.

Best regards,
Ruben Tapia

avatar

Hello, ist there any update on this?
i sent you a mail with the needed data on 21.08

avatar

Hello nikopieper,

Thank you for following up and for sending the requested information.

We now have an update from our Development team. The issue has been confirmed as a bug related to the Feature value used by the Database Logging Target.

If the Feature is configured as:

`API`

please change it to:

`Api`

and test the Endpoint Log again.

This casing change is the confirmed workaround. The underlying issue has been identified and is planned to be corrected in PowerShell Universal 2026.3.0.

Please let me know if changing the value to `Api` restores the logs in your environment.

Best regards,
Ruben Tapia

avatar

Where do i configure this, i have nothing but the standard which comes with installation.
Or do i need to Add it here?

339a8956-136d-44d9-856e-4b747f3ae0c0.png

avatar

@nikopieper
Thank you for sharing that screenshot. It confirms that you are currently using the standard logging targets that come with the installation and do not have an API-specific Database Logging Target configured.

We are going to reproduce this exact configuration in our lab using the default targets only, without adding or changing anything, and verify how the Endpoint Log behaves.

If we reproduce the same behavior under those conditions, we will proceed with the appropriate internal escalation using the lab evidence.

I will update the thread once the reproduction is complete.

Best regards,
Ruben Tapia

avatar

@nikopieper

I was able to reproduce your exact default logging configuration in our lab on PSU 2026.2.3. With the same default targets, the endpoint continues to return HTTP 200, but the API log entries are not persisted, leaving both the Endpoint Log and Platform Logging empty.

I also validated that adding a Database logging target for Information | User | Api restores the API log entries. However, before asking you to make any configuration changes, I am confirming internally whether this additional target is expected to be created manually or whether the default installation should handle this automatically.

For now, please leave your current logging targets unchanged. I will update the thread as soon as I have that confirmation.

Best regards,

avatar

I Tried adding it as a File and Database Target for System And User, it then appears in the Log File on the Server but in PSU in the Logs of the Endpoint there is still nothing and i cant click load more.

And i discored that in Platform -> Logging the logstream is also stuck to 20.08 even if "Live" is checked

avatar

Hello @nikopieper

Thank you for the update.

Since you are now seeing entries in the server log file but the Endpoint Log remains empty, and Platform > Logging appears to stay on older entries even with Live enabled, I would like to compare your current logging configuration with the scenario we reproduced in our lab.

Could you please share a sanitized screenshot of your current Logging Targets after the changes you made? We need to see the following values for each relevant target:

* Type
* Level
* Scope
* Feature
* Resource, if configured

Please also run one affected endpoint and note the exact time of the request. Then confirm:

* Whether that request appears in the File log.
* Whether it appears in Platform > Logging after a manual refresh.
* Whether Platform > Logging still shows the last entries from 20/08.

Please do not make any further logging changes yet. Once we have those details, I will reproduce your exact current configuration in the lab and compare File logging, database persistence, Endpoint Log, and Platform Logging behavior.

Best regards,
Ruben Tapia

avatar

Hello Ruben,

this is whats in the Application.json:
"SystemLogPath": "%ProgramData%\\PowerShellUniversal\\Logs\\System\\systemLog.txt",
"SystemLogLevel": "Information",



Logging Targets:


Please also run one affected endpoint and note the exact time of the request. Then confirm:

* Whether that request appears in the File log. -> Yes it appears in the file log

* Whether it appears in Platform > Logging after a manual refresh. -> No it stays the same, when i filter for user or Feature then nothing is shown.

* Whether Platform > Logging still shows the last entries from 20/08. -> yes

1bfb1f5f-4ff2-4331-9fa9-6e2bd0c4e8c0.png

024a9b44-abaa-45f0-8fa8-ea264e57f613.png

avatar

Hello @nikopieper

Thank you for the additional details.

At this point, we have enough information from your environment and from our internal reproduction to continue the investigation on our side.

Please do not make any additional changes to the Logging Targets for now. Since several configuration changes have already been tested, keeping the current state unchanged will help us avoid introducing additional variables while we complete the internal review.

Your latest test was useful because it confirmed that the endpoint activity is reaching the File log while the Endpoint Log and Platform Logging are still not showing the same entries.

We will continue with the internal investigation using the evidence already collected and will update this thread once we have the next confirmed step.

Best regards,
Ruben Tapia