The Things Gateway shows status: "not connected"

I rebooted my “The Things Gateway” (original, backer edition) device, and now it’s listed as “not connected”.

However, it’s sitting right besides me, connected, with four LEDs on and the fifth flashing every ten or twenty seconds. What could be the problem?

I already fixed the device as it’s one of these that goes into a reboot loop when the LoRa module isn’t seated correctly in its slot. However, that doesn’t seem to be the problem now.

I have the same problem, Uplink, downlink problem (5th LED), Status shows “not connected”. I didn’t see anything FAQ or doc that helps here

Same problem here with our 2 gateways. Both are ‘last seen’ two days ago.

Our third gateway, a Laird, is online.

Assuming all of you actually see data coming in through, say, MQTT or the HTTP Integration: see Gateway is shown as "not connected" but works!?

No data coming through in the Gateway Traffic part in the console at least?

That’s also described in the linked topics in the topic I linked to above:

So when the engine warning light in my car is on, but the car still is running properly, it’s “operating as expected”? The issue seems to be that way for more than 4 days and the only reaction is “but it’s working, isn’t it?”. The connected/not connected indicator is especially important for people with multiple gateways in remote locations. Being able to monitor them without sending test data is essential.

  1. Have you checked if ttnctl provides the same status? I’ve been using it for years to monitor my 15+ gateways and it rarely is wrong about gateway status. Last weekend it showed all gateways using a certain connection off-line and ‘surprise’ there was an issue and it was resolved asap by TTN

  2. You sound like you feel you are entitled to something. If you feel that way, move to TTI, the network with SLAs. The community network is run on best effort base and costs TTN money to keep up and running while not generating any income. They decided not to invest time to resolve this particular issue and focus on getting the next generation software up to the point where we can all benefit from it. That version was designed with the experience of what does not work in the current generation in mind and should not suffer from these failures. (There will of course be other issues as no software is ever perfect)


I reported the console showing “offline” when gateways are in fact online. It doesn’t matter what other services show different results. That single component does not work. In fact, it would be far worse if other components were also failing and showing bad results. What kind of argument is that?

No, I reported an issue with the free service you are providing, to which arjanvanb was quoting that it’s working “as expected”, to which I disagreed.

Please keep your combative attitude to yourself. It’s not constructive. There’s an issue with the console not showing correct information, and the time spent on arguing about it is completely wasted. It’s currently broken and not working “as expected”.

Welp, I spent a bunch of money on a gateway by the same company, for a product that was defective right out of the box, but you don’t see me complaining about having to fix it myself, do you?

Overall, do you have a problem with your users reporting issues with your service? I reported an issue, and all I get is backtalk. A simple, “we are working on the issue, but it’s not our first priority” is all it would have needed.


The only service I provide to you is moderating this forum. I am not employed by TTN, don’t get any money for the many hours I spend trying to support forum users, just a lot of attitude by people that find they are entitled to things.

TTN is aware of the issue. As I explained they decided to spend their time on other things and not to work on resolving this known issue. I understand you don’t agree.


Have you checked if ttnctl provides the same status?

Okay, let’s try it:

$ ttnctl gateways info 19711137
INFO Found gateway                           

      Gateway ID: 19711137
  Frequency Plan: EU_863_870
          Router: ttn-router-eu
     Auto Update: on
           Owner: markruys
    Owner Public: yes
 Location Public: yes
   Status Public: yes

           Brand: MultiTech
           Model: Conduit mLinux
     Description: xxxx EU868
      Access Key: xxxx

   - Username: markruys
     Rights: gateway:settings, gateway:collaborators, gateway:status, gateway:delete, gateway:location, gateway:owner, gateway:messages

So this doesn’t show me whether the gateway is online. Or do you use another ttnctl command?

Although I don’t sympathize on how @milanoengineering makes his point, I do find it annoying that suddenly for some of our gateways the status is not updated anymore at the TTN console.

Off topic, a few days ago we also saw that US915 configured gateways with a EU router suddenly started to receive downlinks on EU868 channels from the NS. These gateways refused to process the downlink so now no join requests get an ack anymore.

You’ll need ttnctl gateways status.

ttnctl gateways status 19711137
  INFO Discovering Router...                   
  INFO Connecting with Router...               
  INFO Connected to Router                     
  INFO Received status                      GatewayID=19711137

           Last seen: 2020-05-15 17:17:50.685704614 +0200 CEST
           Timestamp: 0
       Reported time: 2020-05-15 17:17:50 +0200 CEST
      Frequency Plan: EU_863_870
              Bridge: gs.v3.
            Location: not available
                 Rtt: 46ns
                  Rx: (in: 29; ok: 6)
                  Tx: (in: 1; ok: 1)

Yes, perfect, this shows my gateways to be connected indeed. Thanks, Mark

What an interesting spin to give users who report issues, issues where they don’t even know if they’re at fault, or if the network is faulty. No one feels entitled by reporting an issue with a service. I understand you being frustrated when people complain about stuff you have no control over, but the users don’t have control over it either.

Please look at my first post. I asked what the problem is, and what comes back is “operating as expected”. If anything, that’s seems to be an entitlement to be a smartass to users. “Buy an SLA if you want proper service, you freeloader”. What an attitude to have.

What I saw in the first 3 posts was 3 users who didn’t even seem to bother to search for existing reports about this, nor provide much detailed information.

1 Like

After you reported a known issue that has gotten coverage a couple of times already on the forum and get quoted the official TTN statement regarding this (please visit the official status site to check for it yourself) you respond with a story regarding engine lights. Have you reread your own response and judged it not sounding like you feel entitled?

May-be we should conclude things are as they are. Neither the users nor the moderators can change the decisions made. If you don’t agree, this forum is not the place where you can challenge TTN on their decisions. Don’t ask me what the right place is, I haven’t found it yet…

1 Like

I was perplexed by something being broken, yet “working as expected”.

I checked the official status page, there was an entry from “Jan 27” (no year, on none of the entries). Not sure how relevant that is or can be.

Anyway, you explained the issue, basically the TTN people will work on it whenever they feel like it, as the issue seems to persist for months now, and besides the status and traffic console everything is working fine. Users (like me) just have to deal with it.

TTN is a free to use service, so solving issues like this is probably not a priority.

2 posts were merged into an existing topic: Can’t access TTN Console, ttnctl fails, TTN Node-RED library fails, and Kickstarter gateways get stuck after daily reboot