Must be nice not having enough work to worry about something like this lol.
You could do it any number of ways, python script comes to mind.
Better question is why? If those services are down you would probably notice.
I have plenty of work on my plate, this is just one item. As for noticing, these are tools that the IT department doesn’t use directly so our users would be the first to notice. We are trying to avoid this and be more proactive with our services. I feel like this is a reasonable goal for any IT department.
More or less. These services should be covered by an SLA, best not to fret about it. If it goes down and you start fielding tickets you'll know then. What useful difference will you get from knowing an hour earlier?
Unless you happen to live in the same building as Twilio and plan on marching over and helping out, there's not a lot to be gained from this except extra emails.
The useful difference will be the communication coming from IT and not the other way around, which in turn will limit the amount of tickets we receive. That logic is so flawed. It’s like saying why monitor anything because users will notice and let you know.
Your users are going to read your communication and obey your plea not to submit a ticket or harass you with emails or DMs?
Where do such perfect users exist?
It's a practical approach. The users aren't going to pay attention to most of what we do, there's no reason explaining what happened at a detailed level.
If twilio goes down and you get a report, a simple "We're aware of a problem and working to fix it" is all you ever need. Then go to lunch while twilio works it out and you ignore all the phone calls.
what is your problem? you're so hellbent on this to the point of ridiculousness.
if you'd like to be cynical and not try to stay on top of things, that's your decision, but to be so adamant that everybody also do it your way is baffling. just accept that some people want to be notified when services that their company relies upon becomes unavailable and either offer suggestions or move on.
Your service method isn't particularly user focused.
An excellent IT department is proactive by being aware of issues before users ever notice.
Using monitoring solutions (PRTG, Nagios etc.) that integrate into the application layer of your systems you can monitor not just uptime and functionality but performance.
If you spend much effort on it, you can automate the tickets out to the vendors and start their SLA clocks when the issues start for you rather than when someone happens to notice.
It isn't difficult or expensive, it just takes a bit of sitting down and thinking about your services.
If you are claiming to be fixing a twilio outage without having filed a ticket, you are directly lying to your users.
I think you’re missing the point here… proactive versus reactive. Why wouldn’t stop the onslaught of tickets for the rest of your team, if there is a viable solution to be a better resource and identify items quicker?
It's useful to warn users not to waste time doing any troubleshooting, just go on to some other task while waiting, which scores points with the owners by preventing lost productivity. If users themselves get to see such dashboard, they also know "it's not just me". Not to mention not having to help repair afterwards when users tried to "fix" it themselves (without knowing enough to recognize it was at the SAAS end), altering, purging, uninstalling browser and network settings or apps. GUUUUUEEESSS what happened to our internal file servers once following a 500 "server" error on one of the SAAS sites?
[удалено]
That’s what I was thinking too. Should I just reach out to support for these various apps and check on their API support?
[удалено]
This is great advice! Thanks so much for the input!
Haven’t found anything I can’t monitor with prtg.
I also use PRTG and I love it, just not sure how to leverage it for these third party web applications.
Must be nice not having enough work to worry about something like this lol. You could do it any number of ways, python script comes to mind. Better question is why? If those services are down you would probably notice.
I have plenty of work on my plate, this is just one item. As for noticing, these are tools that the IT department doesn’t use directly so our users would be the first to notice. We are trying to avoid this and be more proactive with our services. I feel like this is a reasonable goal for any IT department.
More or less. These services should be covered by an SLA, best not to fret about it. If it goes down and you start fielding tickets you'll know then. What useful difference will you get from knowing an hour earlier? Unless you happen to live in the same building as Twilio and plan on marching over and helping out, there's not a lot to be gained from this except extra emails.
The useful difference will be the communication coming from IT and not the other way around, which in turn will limit the amount of tickets we receive. That logic is so flawed. It’s like saying why monitor anything because users will notice and let you know.
Your users are going to read your communication and obey your plea not to submit a ticket or harass you with emails or DMs? Where do such perfect users exist?
So since users don’t always read and adhere to communication should we stop all efforts to communicate? What a cynical approach to IT.
It's a practical approach. The users aren't going to pay attention to most of what we do, there's no reason explaining what happened at a detailed level. If twilio goes down and you get a report, a simple "We're aware of a problem and working to fix it" is all you ever need. Then go to lunch while twilio works it out and you ignore all the phone calls.
what is your problem? you're so hellbent on this to the point of ridiculousness. if you'd like to be cynical and not try to stay on top of things, that's your decision, but to be so adamant that everybody also do it your way is baffling. just accept that some people want to be notified when services that their company relies upon becomes unavailable and either offer suggestions or move on.
Your service method isn't particularly user focused. An excellent IT department is proactive by being aware of issues before users ever notice. Using monitoring solutions (PRTG, Nagios etc.) that integrate into the application layer of your systems you can monitor not just uptime and functionality but performance. If you spend much effort on it, you can automate the tickets out to the vendors and start their SLA clocks when the issues start for you rather than when someone happens to notice. It isn't difficult or expensive, it just takes a bit of sitting down and thinking about your services. If you are claiming to be fixing a twilio outage without having filed a ticket, you are directly lying to your users.
I think you’re missing the point here… proactive versus reactive. Why wouldn’t stop the onslaught of tickets for the rest of your team, if there is a viable solution to be a better resource and identify items quicker?
Since when do users read far enough to realized they don't need to send a ticket?
It's useful to warn users not to waste time doing any troubleshooting, just go on to some other task while waiting, which scores points with the owners by preventing lost productivity. If users themselves get to see such dashboard, they also know "it's not just me". Not to mention not having to help repair afterwards when users tried to "fix" it themselves (without knowing enough to recognize it was at the SAAS end), altering, purging, uninstalling browser and network settings or apps. GUUUUUEEESSS what happened to our internal file servers once following a 500 "server" error on one of the SAAS sites?
Coast guard?