OpenLDBWS HTTPS down?

139 views
Skip to first unread message

Mark Jenkins

unread,
Aug 12, 2026, 10:12:10 AM (6 days ago) Aug 12
to A gathering place for the Open Rail Data community
Hi all,

Appealing for help. My app NexTrain is suffering a major outage at the moment.  Is anyone else seeing OpenLDBWS down?

I just saw Rob's note about HTTP but pretty sure HTTPS.  Unsure how to check for any status updates to know if server side, my API token or some other issue.  

Any pointers appreciated! Eg How would I raise a suport ticket with CACI, I think they handle support? Thanks

Ps stuck at work and struggling with Google Groups on my phone so apologies for any spam / broken messages.  Unable to check anything from my developer set up at the moment....

Cheers
Mark

Peter Hicks

unread,
Aug 12, 2026, 10:27:53 AM (6 days ago) Aug 12
to openrail...@googlegroups.com
Hi Mark

You will need to check yourself that you’re using HTTPS and not HTTP, and fix it if needed.  But you’ll also need to check if you’re getting an error back when you make a request for your token, that you’re resolving the URL to the correct IP addresses (they may change) etc.

It’s part of observability for any system to be able to see what’s going on rather than “not working”, and quicker than sending in a ticket that could well be sent back with “So what’s the error?”

Report back when you’ve been able to check on your server.


Peter



Sent from Proton Mail for iOS.


-------- Original Message --------
--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/babb6186-9105-499e-88ac-9b99001a45f7n%40googlegroups.com.

Mark Jenkins

unread,
Aug 12, 2026, 10:47:32 AM (6 days ago) Aug 12
to A gathering place for the Open Rail Data community

Thanks Peter - no server in the loop, will know more when I get in front of my development machine and can look at code.  At work right now, so no access, frustrating as you can appreciate.

I was just trying to understand my options as to how I can escalate and get support once I have the details of what's happening.

Thanks
Mark

Mark Jenkins

unread,
Aug 12, 2026, 10:57:52 AM (5 days ago) Aug 12
to A gathering place for the Open Rail Data community

Seems to be back up now.   Anyone got any pointers as to if this was scheduled down time? Many thanks.

Mark Jenkins

unread,
Aug 12, 2026, 11:08:29 AM (5 days ago) Aug 12
to A gathering place for the Open Rail Data community
But very sluggish... dropping requests.  Still more to check...

David Wheatley

unread,
Aug 12, 2026, 11:12:16 AM (5 days ago) Aug 12
to openrail...@googlegroups.com
My OpenLDBSVWS service via Huxley has been returning spurious 500s ever since Darwin Evolution rolled out, but I don't really use it much anymore (other than monitoring its status!) so I haven't taken the time to look at what is happening.

I must say my monitoring doesn't paint a very positive light!





Gaelan Steele

unread,
Aug 12, 2026, 11:27:18 AM (5 days ago) Aug 12
to openrail...@googlegroups.com
For those with public-facing tools built on top of OpenLDBWS, crawlers may be part of the problem - the LDBWS rate limits are not at all generous, so an aggressive crawler (which are dime a dozen these days) that doesn’t respect rate limits can bring you down quite easily.

Indeed this happens to my own service (trains.gaelan.me) far more often than I’d like to admit. I’ve been meaning to switch to push port to avoid it, but obviously that’s a substantial amount of implementation work. 

Oh, to live in less interesting times. 

Best,
Gaelan

On Aug 12, 2026, at 16:12, 'David Wheatley' via A gathering place for the Open Rail Data community <openrail...@googlegroups.com> wrote:


My OpenLDBSVWS service via Huxley has been returning spurious 500s ever since Darwin Evolution rolled out, but I don't really use it much anymore (other than monitoring its status!) so I haven't taken the time to look at what is happening.

I must say my monitoring doesn't paint a very positive light!


<Screenshot_20260812-161104.png>


David Wheatley

unread,
Aug 12, 2026, 11:55:43 AM (5 days ago) Aug 12
to openrail...@googlegroups.com
A top tip is that the RDM LDB feed has no rate limit!

russell pirie

unread,
Aug 12, 2026, 12:46:11 PM (5 days ago) Aug 12
to openrail...@googlegroups.com
We swapped back to RDM earlier today as Soap became very flaky. We
were having issues with the RDM when first trialing it and was the
reason we stayed with soap, but this forced our hand. RDM looking good
so far.... fingers crossed...

Regards
Russell Pirie

UK Departure Boards LTD
Company 12166351
VAT 435869454



On Wed, 12 Aug 2026 at 16:55, 'David Wheatley' via A gathering place
> To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/CAGZsNij8u9NgAXWGfdvwGVydxVK5pTMB26iy-P4q2BEdP9i8OQ%40mail.gmail.com.

Mark Jenkins

unread,
Aug 12, 2026, 5:42:32 PM (5 days ago) Aug 12
to A gathering place for the Open Rail Data community
Finally got access.  Response code 429 - Too Many requests (I literally made 1 request to test).  This looks like rate limiting.  Unclear why this has suddenly kicked in, my user base has not hit this limiter in over 5 years, my main concern here being a compromised API key.

Peter I'm guessing you're reasonably familiar with this. How would I got about it if I need to a) upgrade my subscription to a paid tier to unblock a rate limit or b) re-subscribe under a different API key in case the current key is being abused (and how could I find that out).  Many thanks

Apologies as you'll appreciate its been several years since I originally did this setup.

Many thanks
Mark

On Wednesday, August 12, 2026 at 3:27:53 PM UTC+1 Peter Hicks wrote:

Mark Jenkins

unread,
Aug 12, 2026, 6:05:08 PM (5 days ago) Aug 12
to A gathering place for the Open Rail Data community
Tried raising CACI support via https://www.caci.com/contact.  I wrote the following (yes its with ChatGPT help)

URGENT – OpenLDBWS production service returning HTTP 429

I am an existing long-standing OpenLDBWS subscriber and have been using the service continuously for more than five years.

Since approximately lunchtime on 12 August 2026, my production application has started receiving HTTP 429 Too Many Requests responses from OpenLDBWS. Prior to today the service had operated reliably for more than five years.

This is currently preventing my application from returning live railway information to paying customers.

I understand that CACI's support system requires a portal login, but I do not have credentials for that system and therefore cannot raise a support ticket.

Please urgently escalate this to the team responsible for OpenLDBWS and advise:

  1. Whether there is currently an incident or rate-limiting problem affecting OpenLDBWS.
  2. Whether my existing API key/subscription has had its rate limit changed.
  3. Whether an existing OpenLDBWS subscriber can have their rate limit increased or their subscription moved to a paid/higher tier.
  4. Whether my existing API key can be reset/reissued.
  5. If OpenLDBWS subscriptions are no longer available, what supported route exists for existing customers whose production applications depend upon the service.

This is an urgent production issue because the application has paying customers and is currently unable to provide its core live-data functionality.

Please let me know if you require my existing OpenLDBWS token, registered email address or application details to identify the subscription.

And I got the attached as a response

Yes I think the universe is against me today :((
Screenshot 2026-08-12 at 23.03.36.png

Mark Jenkins

unread,
Aug 13, 2026, 3:26:47 AM (5 days ago) Aug 13
to A gathering place for the Open Rail Data community
Thanks Russell, that was the missing piece for me - I'm obviously well behind with recent feed changes and have some work to do.

To emphasise the point got through to CACI (old NROD) support and of course they confirmed they don't support it any longer.

Working again this morning, but as noted, flaky and hitting the buffers on rate limits.

Appreciate all the feedback.

Peter Hicks

unread,
Aug 13, 2026, 4:33:31 AM (5 days ago) Aug 13
to openrail...@googlegroups.com
Hi Mark

As David pointed out, you could use RDM because that apparently doesn't enforce a per-user rate limit.  But if you wanted to remove the rate limit for your app, you could:

  1. Email datase...@raildeliverygroup.com to ask for details of a paid tier
  2. Get additional authentication tokens for your app in case you hit a rate limit (i.e. you retry with another token)

I'd advise doing option 1, because option 2 isn't particularly respectful - a bit like going to a free buffet and walking off with three catering plates of sandwiches because "there's no sign saying I can't do this".

At the risk of giving you free consultancy, I think your root problem is the architecture of your app.  Hitting RDG's API directly limits your troubleshooting abilities, risks your API key being discovered in your app and used/abused by others, and doesn't allow you to cache any data across your user base.  You've already seen the issue with troubleshooting.

I'd recommend you build some kind of API that your app hits, which caches responses for 10 seconds so that if somebody hits 'refresh' on your app 15 times in 10 seconds, you're only making a single API call to the LDB API.  Or, if ten people request the departure board for the same station within 10 seconds, you still only make one API call until the cache period expires.  Since you've mentioned you having paying users, I don't think it's unreasonable that you put some effort in to running a server or two, especially since you want to operate a robust production service.

This approach will also remove the API key from distribution within your app.  If you've been using HTTP, then it's trivial for somebody to discover your API key by sniffing network traffic.  Even if you're using HTTPS, the API key will be in your code somewhere and it'll be possible to discover it.

On the CACI side of things, as you've said, they don't support any of the LDB APIs.  I think NRDP was supposed to be able to issue an API key at one time, but I can't recall if that ever made it in to a production feature.  You also emailed CACI in the US, rather than CACI in the UK.  One of them makes their money from data, and the other makes their money from... well, check 'Controversies' on https://en.wikipedia.org/wiki/CACI.


Peter

Daniel Tonks

unread,
Aug 13, 2026, 5:45:21 PM (4 days ago) Aug 13
to A gathering place for the Open Rail Data community
Just wanted to chime in to say you aren't the only one to have this issue Mark. My app that has been using OpenLDBWS for years has been having the same issue since the same time yesterday. Often the first request fails with a 429 but subsequent ones go through fine. It's quite hit and miss. 

I'm not sure what's going on but I was already in the process of routing requests through my own backend rather than exposing the key as I have been doing for 7+ years. It seems unlikely to me that both of our keys have become compromised at the same time, but perhaps someone really wanted as many rail app keys as they could find.

Peter Hicks

unread,
Aug 16, 2026, 4:17:43 AM (yesterday) Aug 16
to openrail...@googlegroups.com

On Thursday, 13 August 2026 at 22:45, Daniel Tonks <dlt...@gmail.com> wrote:

Just wanted to chime in to say you aren't the only one to have this issue Mark. My app that has been using OpenLDBWS for years has been having the same issue since the same time yesterday. Often the first request fails with a 429 but subsequent ones go through fine. It's quite hit and miss.

If there's a pool of back-end servers, they might all have their own request rate checks rather than those being synchronised between members of the pool.  I'm not sure if the OpenLDBWS SOAP service sends back details of which backend server responded to a request - that would be useful to narrow down the problem if it were a particular host all the time.

I'm not sure what's going on but I was already in the process of routing requests through my own backend rather than exposing the key as I have been doing for 7+ years. It seems unlikely to me that both of our keys have become compromised at the same time, but perhaps someone really wanted as many rail app keys as they could find.

Never underestimate the lack of morals of those who want data for training their AI models.


Peter

Reply all
Reply to author
Forward
0 new messages