Discovery loading delay due to API timeouts (ref#OM39X5)

Jason_Kim · January 22, 2026, 1:50am

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· The app takes a long time to respond to commands

Please try to reboot your Roon Server

· No, the issue is still the same even immediately after a reboot

Please try to reboot your networking gear (Router/Switches/etc.)

· No, the issue is still the same even after a reboot

Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?

· No, the issue is still the same

Does the issue happen on multiple Roon Remotes (controllers) or just one?

· Issue happens on multiple remotes

Router Domain Name System (DNS) change

· I was able to change my router's DNS servers but it did not help

What is the operating system of your Roon Server host machine?

· Linux Server (Ubuntu, Fedora, ArchLinux...)

Timestamp of issue occurrences

· It's been a while but the most recent timestamp on the log was 01/22 10:41:53

Describe the issue

Loading discovery takes long time possibly because of API timeouts.

Describe your network setup

Korean local ISP + wired ethernet over a home router (iptime).

Jason_Kim · January 22, 2026, 1:55am

I checked the RoonServer_log.txt. It looks like this specific API is the problem.

https://api.roonlabs.net/discover/1/mixes

01/22 10:30:48 Debug: [easyhttp] [102753] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-22T10%3a30%3a00.0935720&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 48070 ms, status code: 500
01/22 10:30:48 Debug: [easyhttp] [102789] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-22T10%3a30%3a04.1173310&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 44271 ms, status code: 500
01/22 10:36:54 Debug: [easyhttp] [102886] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-22T10%3a36%3a02.5957810&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 51373 ms, status code: 500
01/22 10:41:53 Debug: [easyhttp] [102914] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-22T10%3a40%3a53.0959100&c=tidal-us&languages=en,ko,%3Een&tidal=max timed out after 59999 ms
01/22 10:46:46 Debug: [easyhttp] [48] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-22T10%3a45%3a45.6857690&c=tidal-us&languages=en,ko,%3Een&tidal=max timed out after 60003 ms

They all took very long time and failed with 500 or timed out after 60s.

alex_h · January 22, 2026, 1:58pm

Hello @Jason_Kim,

Thanks for sharing that with us.

Do we understand correctly that the data shown in your screenshot is taking a long time to load?

If so, this behavior can sometimes be caused by packet fragmentation if the default packet size is too large for your specific network path. To test this, we recommend temporarily adjusting the MTU (Maximum Transmission Unit) on your Roon Server machine.

Here is how to do it:

Step 1: Find your network interface name Open your terminal and run the following command: ip addr

Look for your primary network interface in the list. It is usually named eth0, eno1, or enp3s0, and you will see your IP address (e.g., 192.168.x.x) listed under it.

Step 2: Apply the setting Run the command below, replacing eth0 with the actual interface name you found in Step 1:sudo ip link set dev eth0 mtu 1400 (If asked, enter your admin/root password).

Step 3: Verify Restart Roon Server to force a reconnection: sudo systemctl restart roonserver

Then, check the Roon app (specifically the Discovery page) to see if performance has improved.

Note: This setting is temporary and will revert to default after a system reboot. If this fixes the issue, let us know, and we will provide instructions to make it permanent.

Looking forward to your reply.

Jason_Kim · January 23, 2026, 12:11am

Hi Alex,
Thank you for the reply.

Unfortunately, it doesn’t solve. I checked packets with tcpdump and there was no outgoing package with too large. Do you mean there was some incoming packet from your api.roonlabs.net could be too big for my MTU?
My original MTU was 1500 so I can not imagine how lowering it to 1400 can fix the problem.

As I have several concrete timestamps and the target API is roonlabs, was there any of error logs you could check from your API server side? This is 100% reproducible.

Jason_Kim · January 23, 2026, 12:12am

Just FYI, I use tailscale VPN but disabling it also didn’t solve the problem.

Jason_Kim · January 23, 2026, 3:45am

A part from the timeouts, there were 500 internal error as well. There must be an error log in your API server.

FYI, all the timestamps are +09:00 KST timezone.

01/23 09:15:35 Debug: [easyhttp] [69] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-23T09%3a14%3a44.8969350&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 50872 ms, status code: 500
01/23 09:15:43 Debug: [easyhttp] [55] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-23T09%3a14%3a42.5230350&c=tidal-us&languages=en,ko,%3Een&tidal=max timed out after 60001 ms
01/23 12:38:21 Debug: [easyhttp] [355] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-23T12%3a37%3a23.5249024&c=tidal-us&languages=en,%3Een&tidal=max timed out after 60000 ms
01/23 12:38:21 Debug: [easyhttp] [365] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-23T12%3a37%3a23.6320023&c=tidal-us&languages=en,%3Een&tidal=max timed out after 60003 ms

vadim · January 23, 2026, 2:54pm

Hi @Jason_Kim, thank you for the detailed logs and timestamps — this is very helpful.

From what you’ve shared, the delays are clearly coming from repeated calls to the Discovery / mixes API, which are either timing out or returning HTTP 500 after long response times.

As a quick additional test, could you please try accessing Roon through any VPN (even a temporary or free one) and let us know whether Discovery loads any faster? This will help us determine whether the behavior is related to the network path between your ISP/region and our servers.
Thanks again for your patience.

Jason_Kim · January 24, 2026, 12:36am

VPN (NordVPN) didn’t help. I’m not sure of ISP/region issue because this only happens with a specific URI pattern. /discover/1/mixes/*

As you can see, there are many other API call without any problem but only this mixes has the problem. I’m quite sure it’s an issue from you backend internal.

01/24 09:32:20 Debug: [easyhttp] [149] GET to https://api.roonlabs.net/internetradio/2/api/location?format=msgpack& returned after 383 ms, status code: 200, request body size: 0 B
01/24 09:32:20 Debug: [easyhttp] [153] POST to https://api.roonlabs.net/roonmobile/1/cores/announce returned after 97 ms, status code: 200, request body size: 1 KB
01/24 09:32:21 Debug: [easyhttp] [158] GET to https://api.roonlabs.net/profileimages/five-5d096e30-096a-459b-bc59-c13adfb8070a--5ae07ba6-2475-4637-aedc-45ea6fd8672d.jpg?random=f3ecacb5-1106-4f4e-b666-9e9db2a0034f returned after 365 ms, status code: 200, request body size: 0 B
01/24 09:32:21 Debug: [easyhttp] [157] GET to https://api.roonlabs.net/profileimages/five-5d096e30-096a-459b-bc59-c13adfb8070a--6ac695f0-1dbd-47d1-8902-de49a5bfc72e.jpg?random=dca161de-c0a9-4827-bf6a-8ff9d13aca3f returned after 382 ms, status code: 200, request body size: 0 B
01/24 09:32:25 Debug: [easyhttp] [159] POST to https://api.roonlabs.net/discovery/1/register returned after 253 ms, status code: 200, request body size: 1 KB
01/24 09:32:25 Debug: [easyhttp] [161] POST to https://api.roonlabs.net/discovery/1/query returned after 344 ms, status code: 200, request body size: 74 B
01/24 09:32:26 Debug: [easyhttp] [160] POST to https://api.roonlabs.net/porttest/1/port/check returned after 853 ms, status code: 200, request body size: 746 B
01/24 09:32:26 Debug: [easyhttp] [162] POST to https://api.roonlabs.net/porttest/1/port/check returned after 856 ms, status code: 200, request body size: 746 B
01/24 09:32:26 Debug: [easyhttp] [163] POST to https://api.roonlabs.net/roonmobile/1/cores/announce returned after 110 ms, status code: 200, request body size: 1 KB
01/24 09:32:31 Debug: [easyhttp] [164] POST to https://api.roonlabs.net/device-map/1/register returned after 272 ms, status code: 200, request body size: 5 KB
01/24 09:32:39 Debug: [easyhttp] [112] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-24T09%3a31%3a39.9756357&c=tidal-us&languages=en,%3Een&tidal=max timed out after 59999 ms
01/24 09:32:39 Debug: [easyhttp] [120] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-24T09%3a31%3a39.9940445&c=tidal-us&languages=en,%3Een&tidal=max timed out after 59999 ms
01/24 09:32:39 Debug: [easyhttp] [130] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-24T09%3a31%3a39.9947705&c=tidal-us&languages=en,%3Een&tidal=max timed out after 60002 ms

Jason_Kim · January 24, 2026, 12:40am

Oops.. I just realized that the above logs I pasted had tokens. I’m not sure what it does but… Would it be any security issue? I edited the comment but it seems like I can not delete the history.

vadim · January 26, 2026, 5:50pm

Hi @Jason_Kim,

No worries — there’s nothing to be concerned about regarding the logs you shared.
The tokens visible in those entries are short-lived, scoped identifiers and don’t pose a security risk on their own. You did the right thing by editing the post, but there’s no action needed on that front.

Regarding the VPN testing: based on the logs you’ve provided, we don’t see any indication that the active network interface or external IP address changed during the times you mentioned testing with a VPN. In other words, from the server’s point of view, the traffic appears to be coming from the same network path.

To help us correlate this more clearly, could you please clarify:

Where exactly was the VPN enabled?
(On the Roon Server machine itself, on a client/remote, or at the router level?)
If possible, please try enabling the VPN directly on the Roon Server host and then reproduce the issue once more.

That will help us confirm whether the /discover/1/mixes timeouts are influenced by routing/peering versus something happening upstream on our side.

Thanks again for the very thorough investigation — it’s genuinely helpful, and we’ll keep digging with you.

Jason_Kim · January 27, 2026, 5:56am

I ran the NordVPN directly on the roon server host.

I can try that again but I’m not sure how it’s routing/peering related issue as it’s only with a specific path under the same https://api.roonlabs.net/*.

If you still want, I can try that again later after work.

Jason_Kim · January 27, 2026, 6:24am

Weird. This time, I restarted roon server after connecting to VPN to make sure to reset the keepalive sessions. And the timeouts are gone for now. Even with/without VPN, the mixes returned in 8~15 seconds.

However, those are all 500 internal server error now.

01/27 15:17:59 Debug: [easyhttp] [30] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a17%3a42.4876670&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 14250 ms, status code: 500
01/27 15:18:10 Debug: [easyhttp] [68] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a18%3a02.2388280&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 8470 ms, status code: 500
01/27 15:18:35 Debug: [easyhttp] [136] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a18%3a25.5181930&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 9783 ms, status code: 500
01/27 15:19:39 Debug: [easyhttp] [35] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a19%3a30.7561700&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 8055 ms, status code: 500
01/27 15:19:44 Debug: [easyhttp] [27] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a19%3a27.0674620&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 14919 ms, status code: 500
01/27 15:20:04 Debug: [easyhttp] [74] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a19%3a58.4088930&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 5927 ms, status code: 500
01/27 15:23:08 Debug: [easyhttp] [124] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-27T15%3a23%3a00.0226970&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 8022 ms, status code: 500

vadim · January 27, 2026, 1:29pm

Hello @Jason_Kim,

Thank you for the update. We’re glad to hear the latency issue is resolved for now.

We’re currently reviewing the HTTP 500 error internally with the team, and we’ll share any updates here as soon as we have them.

In the meantime, even though we’re seeing this 500 in the logs, could you please confirm whether you’re noticing any visible issues in the UI (for example: recommendations missing, pages failing to populate, or any error prompts)?

Jason_Kim · January 27, 2026, 2:02pm

This is what I see. Not sure what other should have been here in this page.

Not sure if we can call it resolved. For now, it’s <15s but it can get worse as before. I’m gonna monitor it. Also, although it’s better then before, it’s still taking ~15s. Do you think that’s a normal latency?

vadim · January 27, 2026, 6:24pm

Hello @Jason_Kim,

Thank you for the update.

This is a highly utilized service, and while some latency is expected, the latency we’re seeing in your case is higher than average. This may be related to your geographic location and the CDN routing paths involved.

Regarding the 500 error, this is currently being investigated by our R&D team. From what we can see so far, the error appears to be related to an authentication token issue.

As a next step, could you please log out of the Roon application and then log back in, and let us know if the behavior changes afterward?

Thanks again for your patience — we’ll continue to monitor this closely.

Jason_Kim · January 28, 2026, 12:26am

I did logout/login twice but it didn’t help unfortunately.

And now the timeout again.

01/28 09:19:20 Debug: [easyhttp] [1764] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-28T09%3a18%3a19.8955450&c=tidal-us&languages=en,ko,%3Een&tidal=max timed out after 60004 ms

And I tried restart roon server and then not timeout but still 48s with 500 error.

01/28 09:23:50 Debug: [easyhttp] [43] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-28T09%3a23%3a02.1012510&c=tidal-us&languages=en,ko,%3Een&tidal=max returned after 48171 ms, status code: 500

So, IMO the latency varies for some reason but the core problem is the 500 error.

connor · January 29, 2026, 11:26pm

Hi @Jason_Kim,

Thank you for your work to identify this pattern.

Based on testing and reports from other regions, the Discovery API itself is operating normally, and a backend outage would not selectively affect a handful of users. Since the issue reproduces only on that network path and when traffic is routed via Tailscale, the most likely cause is regional ISP routing or CDN edge behavior rather than a failure in Roon’s API infrastructure. Tailscale changes egress IPs and can result in different CDN edge selection, which in some regions can expose transient or localized edge-level errors that surface as 500 responses even when the origin service is healthy.

Both Tailscale and commercial VPNs can still egress through nearby or similarly peered IP ranges, so switching VPN providers doesn’t guarantee a different CDN path. At this point, the remaining variables to test would be a different physical network (such as a mobile hotspot from your phone) or waiting for the regional CDN routing to recover, as there’s no indication of a systemic issue with Roon’s API infrastructure.

We’ve reported this to the relevant teams just in case.

Jason_Kim · January 30, 2026, 5:44am

Hi connor,

Thank you for the investigation.

As I mentioned before in this thread, I tried after disabling all the VPNs but it didn’t help.

Btw, this is the traceroute result from my roon server.

sudo mtr --tcp -rz api.roonlabs.net
Start: 2026-01-30T14:40:01+0900
HOST: roonbox                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    _gateway             0.0%    10    0.5   0.6   0.5   0.7   0.1
  2. AS4766   222.116.34.1         0.0%    10    2.6   3.4   2.5   6.2   1.2
  3. AS4766   61.78.46.211         0.0%    10    2.5   3.0   1.2  10.8   2.8
  4. AS4766   112.188.227.149      0.0%    10    1.8   2.0   1.6   2.6   0.3
        112.188.226.149
     AS4766   112.188.226.149
  5. AS4766   112.174.47.101       0.0%    10    6.9   8.8   6.9  10.4   1.4
        112.174.49.97
     AS4766   112.174.49.97
        112.174.47.233
     AS4766   112.174.47.233
        112.174.49.229
     AS4766   112.174.49.229
        112.174.49.233
     AS4766   112.174.49.233
  6. AS4766   112.174.91.158       0.0%    10    8.4   8.2   6.5  10.3   1.3
        112.174.86.90
     AS4766   112.174.86.90
        112.174.86.74
     AS4766   112.174.86.74
        112.174.91.254
     AS4766   112.174.91.254
        112.174.91.106
     AS4766   112.174.91.106
        112.174.91.154
     AS4766   112.174.91.154
        112.174.91.206
     AS4766   112.174.91.206
  7. AS13335  172.70.199.2         0.0%    10   14.9  16.1  13.5  22.7   3.0
  8. AS13335  172.66.148.147       0.0%    10   11.5  13.2  11.4  14.8   1.5

dig api.roonlabs.net

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> api.roonlabs.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24701
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api.roonlabs.net.              IN      A

;; ANSWER SECTION:
api.roonlabs.net.       140     IN      CNAME   api.roonlabs.net.cdn.cloudflare.net.
api.roonlabs.net.cdn.cloudflare.net. 300 IN A   172.66.148.147
api.roonlabs.net.cdn.cloudflare.net. 300 IN A   104.20.47.62

;; Query time: 112 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Jan 30 14:37:52 KST 2026
;; MSG SIZE  rcvd: 123

Jason_Kim · January 30, 2026, 5:48am

Also, I know this can not work without the auth headers but just to check the network connectivity.

curl -4 -v https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes\?localTime\=2026-01-29T13%3a19%3a56.1591080\&c\=tidal-us\&languages\=en,ko,%3Een\&tidal\=max
* Host api.roonlabs.net:443 was resolved.
* IPv6: (none)
* IPv4: 172.66.148.147, 104.20.47.62
*   Trying 172.66.148.147:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=api.roonlabs.net
*  start date: Jan 24 04:25:28 2026 GMT
*  expire date: Apr 24 05:25:25 2026 GMT
*  subjectAltName: host "api.roonlabs.net" matched cert's "api.roonlabs.net"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Connected to api.roonlabs.net (172.66.148.147) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-29T13%3a19%3a56.1591080&c=tidal-us&languages=en,ko,%3Een&tidal=max
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: api.roonlabs.net]
* [HTTP/2] [1] [:path: /discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-29T13%3a19%3a56.1591080&c=tidal-us&languages=en,ko,%3Een&tidal=max]
* [HTTP/2] [1] [user-agent: curl/8.14.1]
* [HTTP/2] [1] [accept: */*]
> GET /discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-01-29T13%3a19%3a56.1591080&c=tidal-us&languages=en,ko,%3Een&tidal=max HTTP/2
> Host: api.roonlabs.net
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 403
< date: Fri, 30 Jan 2026 05:47:24 GMT
< content-length: 0
< cf-ray: 9c5eaca7dbaffcdb-FUK
< cf-cache-status: DYNAMIC
< server: cloudflare
< strict-transport-security: max-age=31536000; includeSubDomains
< vary: accept-encoding
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host api.roonlabs.net left intact

FWIW

vadim · January 30, 2026, 5:21pm

Hello @Jason_Kim

R&D confirmed that we were able to reproduce the issue and are currently investigating it.