Hello,

They do arrive, but you need to keep refreshing the logs in the ODC Portal. You’re right that there can be a slight delay. I tested it on my side and noticed the logs appeared about one minute later, but the timestamp of the log matches the exact time when the action was triggered.

Hi Jeroen,

This is expected behavior in ODC.

When LogMessage is executed from a client action, the log is created on the client side and is not immediately sent to the server logs. Client logs are buffered locally and only transmitted under certain conditions, such as:

• a server interaction (for example, calling a server action),
• the app going to the background or being closed,
• or when the internal client logging buffer is flushed.
  
  

Because of this, LogMessage entries from client actions may appear with a delay in Monitor, or in some cases may not appear at all if the session ends unexpectedly. Real-time visibility is therefore not guaranteed.

A few practical tips that you can test:

1. If you need immediate and reliable logging, place the LogMessage in a server action.
2. For client-side debugging, rely on browser developer tools or device logs, rather than platform logs.
3. Double-check that the relevant log levels and categories are enabled in the environment configuration.

This behavior is by design in ODC to minimize network traffic and avoid performance impact on the client.

Hope this helps clarify what you are seeing.

Best regards, Miguel

@Miguel Verdasca ,
maybe the problem is all these 403 I receive?

Hi Jeroen,

Yes, that 403 is very relevant and it explains why the LogMessage entries are not reaching Monitor.

In ODC, client-side logs are sent to the platform through a dedicated logging endpoint (/v2/logs). If those requests are returning 403 Forbidden, the logs are being rejected by the platform and will never be persisted, regardless of buffering or timing.

This usually points to one of the following:

• Invalid or expired API key / app credentials used by the mobile app.

• Environment mismatch, for example the app built against a different ODC environment than the one receiving the logs.

• Security or access restrictions at the environment level preventing client log ingestion.

• In rarer cases, a temporary platform-side restriction on the logging endpoint.

So, while client logs are indeed buffered and not sent immediately, they should still be successfully posted once a flush occurs. A consistent 403 means the flush is happening, but the platform is explicitly rejecting the request.

I would recommend:

1. Verifying the app’s environment configuration and credentials.

2. Regenerating the API key and redeploying the app.

3. Checking whether other client-to-platform calls succeed from the same app/session.

4. If the issue persists, raising it with OutSystems Support, as the request is reaching CloudFront but being denied upstream.

In short: this is not just delayed logging; it’s failed log ingestion.

Hope this helps clarify what you’re seeing.

Best regards, Miguel