High rate of 500 errors for TrustAsia Log2026[ab]

[Chris Hartwig]

Hi all,

note: please tell me if it's not the best place to post this...

SSLBoard has been noticing high 500 HTTP error rates for get-entries on TrustAsia logs since around 2025-11-18 at 23:00 UTC. We're falling behind on scanning (graph below of lag vs. GMT+7 time).

Anyone else noticed it?

[Xiaoming Yang]

Hi, this is the TrustAsia Log Operator.

 We checked the CDN error stats and our internal logs. We didn't see any massive or continuous HTTP 5xx errors during that period, nor did we find any obvious HTTP 500 errors related to SSLBoard requests. Our CDN HTTP 5xx error rate is currently under 0.2% of total requests.

Also, regarding the RFC6962 logs, our max_get_entries is set to 32. If possible, please adjust your start and end parameters to increment by multiples of 32. This will allow for better cache hit rates and provide faster responses.

[Chris Hartwig]

Hey thanks for your message. 

It looks like the situation changed today just before 6:00 UTC: errors stopped, lag is going down now (as seen on second graph).

Also 32 is already the size of the requests sslboard is sending to TrustAsia logs. 

We didn't change anything and it resolved itself.

Also included is our graph of 500 errors for 2026[ab]. Before that, it was at exactly 0 for the whole of 14 days (retention limit). The 500 errors have not stopped completely though. We're talking about 15 to 30 500 errors per 5 minutes according to our logs. They all caused exponential backoff.

If there's anything I can do to help you track and solve this, I'm up for it.

Again thanks for checking on your side

Chris

[Matt Palmer]

On Thu, Nov 20, 2025 at 02:25:23AM -0800, Xiaoming Yang wrote:
> Also, regarding the RFC6962 logs, our max_get_entries is set to 32. If
> possible, please adjust your start and end parameters to increment by
> multiples of 32. This will allow for better cache hit rates and provide
> faster responses.

If you want to serve cacheable tiles, you'll do better if you return a
mid-tile response with the remaining subset of entries in that tile. That'll
cause the monitor to automatically synchronise itself with the tile
start for future requests.

- Matt