Information and Support

Hi, If you check now, it seems to be ok. Thanks to your post, we were able to find a problem with our load balancing that was causing some incoming data to be lost. This is fixed now. We appreciate your taking the time to bring this up. Our biggest challenge is members not bothering to report problems that we might not be aware of. No matter how much testing we do, there are things that simply don't show up while testing and we hope members will let us know so we can fix them. Should be fine now, please confirm. By the way, it's important to note that there is a difference between disconnections and IP outages. Short, non IP outages cannot be detected in terms of where the problem is because it's not IP based. It means it's a cable, signal levels, dying interface, ISP cable plant problems, countless possible things but not IP related.

I'm not sure what you mean by 'give us the ability to use our own mail server'? I don't see how that would be possible as it would require a lot of configurations between the application and our own mail services. We came up with the limit of three emails before a reset after many years of monitoring the results of changing those and it has to remain at 3 unless there is a very compelling reason to change it. The point of the service is to help solve Internet issues which implies that someone monitoring is going to be checking when they get emails therefore, there is no point in constantly sending more and more emails about the same problem.

@edmundo Looking at the historical pings I can see almost the same behavior in both agents, maybe around the time you were sending the image it appeared to be different but I can see a consistent issue at your site. The amount of outages you are experiencing is very high. One more note about alerts... Alerts need to be acknowledged before another one can be raised i.e. if you don't acknowledge, let's say, an outage alert, even if new outages are recorded you won't be seeing it in the alerts

Thank you, please close this and the below ticket I opened.

I have solved the issue. Thanks

I'll try now.

One thing that might help, can you use a 2amp power supply, just to be safe.

Keep in mind that when you install, you have to be logged in as administrator or a user that can allow network access. If the software gets installed without being allowed network access, it won't be able to monitor anything. I'm sure you knew this but want to point it out in case someone else is looking for help. Keep an eye on the summaries and please let us know if anything stops working etc. Thanks again for reporting it.

Thanks so much for fixing it! Everything is fully operational again and the subscription access is showing.

@SBK Yes. Connected to WeLink and working well! It also came back to working well state after enabling IPV6 in Eero router to check that (07 Feb 0814 CST, which caused router reboot). So, it seems like you have found a way to overcome whatever WeLink was doing differently than other ISPs (at least at this installation), or perhaps WeLink corrected something on their end (they did not tell me about any change, but they usually don't)

You're very welcome and thanks for bringing it up.

Yes, ping times are affected by which hops they flow through. We always wanted a more 'real world' result for pings so wanted those to go through many switches getting to our network. We just needed a reliable destination. It didn't matter where or what, so long as the agents algorithm was able to build up averages from which it would recognize latency changes. We've tested using closer (to the agent) destinations but it's never 'real world' like. We keep testing this to see how we can improve it. Thanks very much for bringing this up. We're looking into the other things too.

Kind of... I swapped it over to a switch that provides access to that same vlan subnet, and it was able to obtain an address that way. It doesn't seem to like being told what vlan to be a part of at the router interface. Still a mystery, but at least I've got a work around. Thanks again for your help in troubleshooting!

Did you find the email?

Hi, If there is personal information involved that you don't want to share in public, you can contact us using the 'Reach out to us form on www.outagesio.com. Otherwise, you're welcome to post in this forum which is for feedback. https://support.outagesio.com/category/11/feedback-about-outagesio

Great tip for others. Thanks for sharing. We do plan on adding SMS, it's in our long list of things to do :).

Hi Ed. Yes. I can see your messages now here.

Working now. Thank you!

Hi, Sorry for not responding. Every now and then, we don't get notifications for posts of they get lost in too many emails. So the first thing would be to understand what are outages and disconnections. Here are some links that can help. All can be found in this category; https://support.outagesio.com/category/7/articles-and-services-related-posts https://support.outagesio.com/topic/12/about-internet-outages-alerts-and-agent-statuses https://support.outagesio.com/topic/120/about-inactive-excessive-outages-and-notifications https://support.outagesio.com/topic/112/important-cable-and-wireless-internet-services There are two reasons that there could be down time, IP outages and/or disconnections. IP outages are the easiest one because there is always a report. If the agent cannot make a complete connection to a destination, it will instantly go into tracking mode. This means that there are two things that can happen. So long as the agent was not disrupted, it will send an outage report if there was in fact an IP outage and/or it will send an Inactive if MIA for at least 30 seconds and eventually a Disconnection notice if it is MIA for at least 30 minutes. Both of these can be disregarded if an IP outage comes in during that same time. On the OutagesIO side, Inactive/Disconnected notifications will be set if you have those enabled as well as an outage notification if you also have that enabled. This is why you would get multiple notifications that could be confusing unless you are aware of why those are sent. The agent will always log an IP outage since there is something to log but if it's just disconnections, there is nothing that can be logged, based on the articles above. Note also that like all IP monitoring, software alone cannot always be 100% sure, it takes human eyes to take a deeper look. Data from any monitoring tool is used along with other factors to determine what the problems might be. IP routes could change any moment so one ping to something remote might change routes while another might not. However, in the case of OutagesIO, the point is to get some idea of problems on the LaN but mainly it is to monitor the ISP/Provider. All data beyond the provider is for information only and cannot be used in any way since the only entity you could go after for problems is the local ISP. The upper tier carriers rarely if ever respond to complaints other than the ISPs they provide services to. It would be practically impossible to get in touch with someone that will care enough to look into it. The provider however can be motivated to do better, especially when there is correlating data from other nearby locations using OutagesIO for example that are all seeing similar problems. So again, the key is using OutagesIO as part of your tools. It automates as much as possible to help you find potential problems. A blip here and there does not always indicate a problem, it's just the nature of Internet connectivity. Let me know if this helps at all.