@Flying_Chinaman said: wa'z your daily routine, jus' fix the broken racks, close most of the tickets and call it a day?
I tried answering this a few times without being negative and it's not possible, the simplest way to say it is obviously most my day isn't a routine, it's whatever work ends up being created for me that day by a third party and then ... tickets.
Perhaps you need a new ticketing policy:
pay less than $20 annually => one active ticket
pay between $20 and $40 annually => two active tickets
...
this policy helps prevent low-paying ticket users from submitting excessive tickets and depleting ticket resources.
@Flying_Chinaman said: wa'z your daily routine, jus' fix the broken racks, close most of the tickets and call it a day?
I tried answering this a few times without being negative and it's not possible, the simplest way to say it is obviously most my day isn't a routine, it's whatever work ends up being created for me that day by a third party and then ... tickets.
Perhaps you need a new ticketing policy:
pay less than $20 annually => one active ticket
pay between $20 and $40 annually => two active tickets
...
this policy helps prevent low-paying ticket users from submitting excessive tickets and depleting ticket resources.
MJJ - 1 ticket per real human, regardless of clone accounts, resold logins, services etc.
others - NA
@Flying_Chinaman said: wa'z your daily routine, jus' fix the broken racks, close most of the tickets and call it a day?
I tried answering this a few times without being negative and it's not possible, the simplest way to say it is obviously most my day isn't a routine, it's whatever work ends up being created for me that day by a third party and then ... tickets.
Perhaps you need a new ticketing policy:
pay less than $20 annually => one active ticket
pay between $20 and $40 annually => two active tickets
...
this policy helps prevent low-paying ticket users from submitting excessive tickets and depleting ticket resources.
One active ticket at a time over and over won't solve the problem of people creating many tickets over the same issue that's not really covered under support. Anyway it's not a huge deal we'll get it all sorted out.
@rpollestad said:
Oof. Got a notice that my SJ dedicated server is going away. That sucks.
Are you just done offering dedicated servers or is it just that location and I can migrate?
It's been a decision we've considered for a while, I wish I would've done it sooner and provided a longer notice and it especially sucks that we're doing it to the people that stuck around for so long but I believe it'll be good for everyone. I don't feel comfortable having broken controls, no planned resolution for that to improve the controls, and it seems like everything is only going to regress from here so it's best to do something important and try to be proactive this time. And the way it works out it just ends up clashing with our workflow where we often have extreme delays on even providing support and we don't want that.
We would want to offer dedicated servers, no's not the time. It will be later when we can do servers ourselves, our own hardware, as originally intended. It's just not something that can be done right now. Most we can offer is a VPS/VDS replacement for anyone interested.
@VirMach said: It's been a decision we've considered for a while, I wish I would've done it sooner and provided a longer notice and it especially sucks that we're doing it to the people that stuck around for so long but I believe it'll be good for everyone. I don't feel comfortable having broken controls, no planned resolution for that to improve the controls, and it seems like everything is only going to regress from here so it's best to do something important and try to be proactive this time. And the way it works out it just ends up clashing with our workflow where we often have extreme delays on even providing support and we don't want that.
then can you provide compensation? I slide down into 2 years wait and multi-account drama and finally got nothing
and when can you process my coinbase deposit,its already 5 months,and still on-hold? #913893
@VirMach What's your situation with DediPath.....everything all good!?
Because after the last downtime where they didn't communicate anything, hosts are not happy and some of them are migrating away like EthernetServers. And I read, even on WHT their name is being scrubbed. I believe you have some nodes with them so just checking if all is well and they are not going down!?
@lesuser said: @VirMach What's your situation with DediPath.....everything all good!?
Because after the last downtime where they didn't communicate anything, hosts are not happy and some of them are migrating away like EthernetServers. And I read, even on WHT their name is being scrubbed. I believe you have some nodes with them so just checking if all is well and they are not going down!?
@rpollestad said:
Oof. Got a notice that my SJ dedicated server is going away. That sucks.
Are you just done offering dedicated servers or is it just that location and I can migrate?
We would want to offer dedicated servers, no's not the time. It will be later when we can do servers ourselves, our own hardware, as originally intended. It's just not something that can be done right now. Most we can offer is a VPS/VDS replacement for anyone interested.
Been a happy dedicated holder since 2016. Sad to see it go but thank you for the reply.
Sorry, don't mean to make trouble, but, would it make any sense for @Virmach to connect former dedi customers with whomever was @Virmach's dedi upstream provider? It seems a shame that there isn't some way to facilitate former dedi customers' ability to keep their dedi servers that they like.
@Not_Oles said:
Sorry, don't mean to make trouble, but, would it make any sense for @Virmach to connect former dedi customers with whomever was @Virmach's dedi upstream provider? It seems a shame that there isn't some way to facilitate former dedi customers' ability to keep their dedi servers that they like.
@Not_Oles said:
Sorry, don't mean to make trouble, but, would it make any sense for @Virmach to connect former dedi customers with whomever was @Virmach's dedi upstream provider? It seems a shame that there isn't some way to facilitate former dedi customers' ability to keep their dedi servers that they like.
We just don't feel like we can do it justice right now. Whatever we do would end up being sub-par and it's one of those situations that's "it's not you, it's me" and it's best we just end the relationship for now so we're the responsible party and end any future potential grief.
Read my comment below on why, but I don't think we'd be comfortable facilitating that.
@lesuser said: @VirMach What's your situation with DediPath.....everything all good!?
Because after the last downtime where they didn't communicate anything, hosts are not happy and some of them are migrating away like EthernetServers. And I read, even on WHT their name is being scrubbed. I believe you have some nodes with them so just checking if all is well and they are not going down!?
I'll have a more in-depth response for this soon hopefully. I've edited out my comment for now because it's too vague and may be taken the wrong way.
@Not_Oles said: Sorry, don't mean to make trouble, but, would it make any sense for @Virmach to connect former dedi customers with whomever was @Virmach's dedi upstream provider? It seems a shame that there isn't some way to facilitate former dedi customers' ability to keep their dedi servers that they like.
P.S. we tried doing this in the past, you should be able to read about our side of the story if you find a copy of the lawsuit against the provider that cut off dedicated servers we paid for and wouldn't even release them temporarily for customer data. We just wouldn't want to facilitate it only for the core problem to still be there for the customers (a third party.)
If a customer really wants to do that we're all ears so we'll help them out of course in their ticket.
Behavior like this is only going to ensure we don't give out IPv6 to anyone unless they purchase a plan that comes officially with IPv6. For reference this guy made two "urgent" tickets about needing IPv6 on some old specials.
@VirMach said:
Behavior like this is only going to ensure we don't give out IPv6 to anyone unless they purchase a plan that comes officially with IPv6. For reference this guy made two "urgent" tickets about needing IPv6 on some old specials.
Well, in his defense, he is not wrong. You should have a way to find tickets older then X days and prioritize them OR reply to them OR some way to let them know what to do.
Your service is very unreliable (at least as far as i can see from the people on this forum), but since you never said 100% uptime, no complains there, specially at that price. IP changes are not good, but if unavoidable, then so be it.
However, not replying to customer ticket IS a problem. So if you cannot hire more people to reply to tickets, get less customers OR charge them PER ticket opened/replied. Basically some way to reduce the number of tickets pending replies for over X days.
What is the "X" number of days? You can define that, but a good number is 5 working days.
I speak fluent sarcasm and broken logic. | I would agree with you, but thæn we’d both be wrong.
VirMach said: e able to read about our side of the story if you find a copy of the lawsuit against the provider that cut off dedicated servers we paid for and wouldn't even release them temporarily for customer data.
We need LowEndLawyer to find those.
Virtual Machine Solutions LLC should be one side, ColoCrossing should be the other. Or maybe Deluxe?
VirMach is based in LA, so I would assume it should be in LA courts? I have no idea how Murica system works.
Found this, have no idea how to get a copy
@tomsm said:
ny 022 is not work Offline PhysicalValuable-VM id：688689
Click on also can not be normal
This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.
I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.
Make script to automatically unmount ISO after 48 hours.
Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.
@somik said: Well, in his defense, he is not wrong. You should have a way to find tickets older then X days and prioritize them OR reply to them OR some way to let them know what to do.
His ticket was definitely in the queue, and skipped on purpose. He already knew he used the IPv6 button twice. We're not going to focus on prioritizing answering tickets that request urgent IPv6. Because once it's answered it's guaranteed to turn into an argument or another ticket being created if someone is already resorting to ignoring any procedure. In fact I'm pretty sure something like that already occurred so he was marked accordingly. This helps us get to the right tickets on time.
His ticket did also receive an AI response that correctly told him we don't officially offer IPv6, IIRC. If an AI can find this information because you didn't even type in "IPv6" into the knowledgebase then the ticket is not guaranteed to receive any further response, especially on a custom ticket.
@somik said: OR charge them PER ticket opened/replied. Basically some way to reduce the number of tickets pending replies for over X days.
Customers have the option to purchase the correct support level if they want responses to everything, even if it's in the knowledgebase and we'll go over everything with them. So your suggestion is already effectively implemented if that's the level of support someone requires.
Oh also I didn't really announce this but this is pretty cool, everyone should know it exists now. We hooked up our helpdesk chat bot on the website to GPT as well, and it will be extremely helpful in answering questions for you if you're just quickly trying to have a policy or content in a knowledgebase article or information our website presented to you. Even works pretty well for being able to quickly figure things out for your operating system although for that you can just use ChatGPT directly.
Some examples, these are from tickets I reviewed/answered today, which it answered correctly for those most common situations that the customers were facing.
@tomsm said:
ny 022 is not work Offline PhysicalValuable-VM id：688689
Click on also can not be normal
This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.
I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.
Make script to automatically unmount ISO after 48 hours.
Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.
Disallow opening tickets until 12 hours after (1) the reset button has been pressed and (2) VNC connection has been established and lasted at minimum of 300 seconds.
We accept Karma donations for the last flan. 🍮 affbrr
@tomsm said:
ny 022 is not work Offline PhysicalValuable-VM id：688689
Click on also can not be normal
This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.
I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.
Make script to automatically unmount ISO after 48 hours.
Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.
Disallow opening tickets until 12 hours after (1) the reset button has been pressed and (2) VNC connection has been established and lasted at minimum of 300 seconds.
That's just stupid. If a VPS isn't working, people will first try to reset it, followed by opening a support ticket. Since they already have bots replying to the tickets, it makes more sense to just feed the bot answers to "VPS not working" questions with unmount ISO and such.
I speak fluent sarcasm and broken logic. | I would agree with you, but thæn we’d both be wrong.
@tomsm said:
ny 022 is not work Offline PhysicalValuable-VM id：688689
Click on also can not be normal
This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.
I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.
Make script to automatically unmount ISO after 48 hours.
Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.
Wont that cause issues with people using Alpine linux which requires the ISO to boot if you use their minimal installation?
I speak fluent sarcasm and broken logic. | I would agree with you, but thæn we’d both be wrong.
@tomsm said:
ny 022 is not work Offline PhysicalValuable-VM id：688689
Click on also can not be normal
This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.
I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.
Make script to automatically unmount ISO after 48 hours.
Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.
Wont that cause issues with people using Alpine linux which requires the ISO to boot if you use their minimal installation?
Anybody running Alpine will have enough clues to figure it out on their own. That's not this crew.
Summary:
This document serves as the Reason for Outage (RFO) to provide a comprehensive explanation of the network interruption that occurred on July 28th, 2023. The purpose of this RFO is to outline the root cause, impact, actions taken for resolution, and preventative measures to avoid similar incidents in the future.
Incident Overview:
On July 28th, 2023, at approx. 6PM EST a network interruption was experienced in San Jose, Redondo Beach, and Secaucus. This interruption resulted in a partial or complete loss of network connectivity and services for affected services. The incident was resolved at on July 28th, 2023 approx. 8:25PM with the exception of customers that were affected by a switch failure in Secaucus.
Root Cause Analysis:
After a thorough investigation, the root cause of the network interruption has been identified as follows:
Issue with common upstream provider we have in all three locations.
An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.
Impact:
The network interruption had the following significant impact:
Downtime: Affected systems experienced a loss of connectivity, leading to disruptions in services.
Actions Taken:
Upon identifying the root cause, the following actions were taken to resolve the network interruption:
Immediate Notification to Upstream Provider: The network team promptly contacted upstream providers to resolve the upstream issue.
Testing and Verification: After the upstream provider implemented the fix, DediPath performed thorough testing and verification were performed to ensure the stability and functionality of the network.
Since the incident was resolved we have opened discussions with other providers to prevent this situation from occurring again.
Conclusion:
The network interruption experienced on July 28th was a significant incident that impacted the organization and its users. Through a comprehensive root cause analysis and implementation of preventative measures, we aim to strengthen the network's resilience and provide a more robust and reliable service to our customers. We apologize for any inconvenience caused and remain committed to continually improving our network infrastructure.
If you have any further questions or concerns, please do not hesitate to reach out to our support team at [email protected]
Just wanted to give a shout out to Virmach.
After almost 6 months, I have finally gotten my Stromonic Refugee VPS (NVMe 1G), that too in Tokyo.
Since my Stromonic VPS billing had expired in June, I was expecting just a price match at this point of time - but Virmach has included some free months in the plan!
@lesuser said:
Reason for Outage
Date: July 31, 2023
Summary:
This document serves as the Reason for Outage (RFO) to provide a comprehensive explanation of the network interruption that occurred on July 28th, 2023. The purpose of this RFO is to outline the root cause, impact, actions taken for resolution, and preventative measures to avoid similar incidents in the future.
Incident Overview:
On July 28th, 2023, at approx. 6PM EST a network interruption was experienced in San Jose, Redondo Beach, and Secaucus. This interruption resulted in a partial or complete loss of network connectivity and services for affected services. The incident was resolved at on July 28th, 2023 approx. 8:25PM with the exception of customers that were affected by a switch failure in Secaucus.
Root Cause Analysis:
After a thorough investigation, the root cause of the network interruption has been identified as follows:
Issue with common upstream provider we have in all three locations.
An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.
Impact:
The network interruption had the following significant impact:
Downtime: Affected systems experienced a loss of connectivity, leading to disruptions in services.
Actions Taken:
Upon identifying the root cause, the following actions were taken to resolve the network interruption:
Immediate Notification to Upstream Provider: The network team promptly contacted upstream providers to resolve the upstream issue.
Testing and Verification: After the upstream provider implemented the fix, DediPath performed thorough testing and verification were performed to ensure the stability and functionality of the network.
Since the incident was resolved we have opened discussions with other providers to prevent this situation from occurring again.
Conclusion:
The network interruption experienced on July 28th was a significant incident that impacted the organization and its users. Through a comprehensive root cause analysis and implementation of preventative measures, we aim to strengthen the network's resilience and provide a more robust and reliable service to our customers. We apologize for any inconvenience caused and remain committed to continually improving our network infrastructure.
If you have any further questions or concerns, please do not hesitate to reach out to our support team at [email protected]
Sincerely,
DediPath
I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
@Encoders said: I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'
They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?
@Encoders said: I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'
They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?
The reason for the outage, which the RFO doesn't really answer.
@lesuser said: [Quoting Dedipath] Issue with common upstream provider we have in all three locations.
An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.
(I recognise that the language may be hard for some and it isn't exactly brimming with information.)
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@Encoders said: I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'
They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?
Well they took a page and a half to say, "Our upstream messed up. We called them. They fixed it." but never what it was nor how they're going to try to make it not happen again only that they're having "discussions with other providers".
^ Agreed, regards the what but to be fair, they can't really elaborate, on [any?] discussions with other providers.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@AlwaysSkint said:
^ Agreed, regards the what but to be fair, they can't really elaborate, on [any?] discussions with other providers.
If they'd told us the "what" those discussions might not be as important to know since if it was a technical issue then they'd be able to discuss it.....
my NY vps is down AGAIN. I can't ssh. I can't open my service page in virmach dashboard. I can't reboot, I can't do a damn thing
what an agony it's been with you guys...
Comments
Perhaps you need a new ticketing policy:
pay less than $20 annually => one active ticket
pay between $20 and $40 annually => two active tickets
...
this policy helps prevent low-paying ticket users from submitting excessive tickets and depleting ticket resources.
MJJ - 1 ticket per real human, regardless of clone accounts, resold logins, services etc.
others - NA
I bench YABS 24/7/365 unless it's a leap year.
Oof. Got a notice that my SJ dedicated server is going away. That sucks.
Are you just done offering dedicated servers or is it just that location and I can migrate?
One active ticket at a time over and over won't solve the problem of people creating many tickets over the same issue that's not really covered under support. Anyway it's not a huge deal we'll get it all sorted out.
It's been a decision we've considered for a while, I wish I would've done it sooner and provided a longer notice and it especially sucks that we're doing it to the people that stuck around for so long but I believe it'll be good for everyone. I don't feel comfortable having broken controls, no planned resolution for that to improve the controls, and it seems like everything is only going to regress from here so it's best to do something important and try to be proactive this time. And the way it works out it just ends up clashing with our workflow where we often have extreme delays on even providing support and we don't want that.
We would want to offer dedicated servers, no's not the time. It will be later when we can do servers ourselves, our own hardware, as originally intended. It's just not something that can be done right now. Most we can offer is a VPS/VDS replacement for anyone interested.
then can you provide compensation? I slide down into 2 years wait and multi-account drama and finally got nothing
and when can you process my coinbase deposit,its already 5 months,and still on-hold? #913893
@VirMach What's your situation with DediPath.....everything all good!?
Because after the last downtime where they didn't communicate anything, hosts are not happy and some of them are migrating away like EthernetServers. And I read, even on WHT their name is being scrubbed. I believe you have some nodes with them so just checking if all is well and they are not going down!?
Powerful AMD Ryzen VPS (aff)
I admit I was kinda curious about that at well.
Been a happy dedicated holder since 2016. Sad to see it go but thank you for the reply.
Sorry, don't mean to make trouble, but, would it make any sense for @Virmach to connect former dedi customers with whomever was @Virmach's dedi upstream provider? It seems a shame that there isn't some way to facilitate former dedi customers' ability to keep their dedi servers that they like.
Is there any new progress in the Ulaanbaatar data center, I have prepared 40-25 knives for it
We accept Karma donations for the last flan. 🍮 affbrr
The issue is the upstream being terrible.
We just don't feel like we can do it justice right now. Whatever we do would end up being sub-par and it's one of those situations that's "it's not you, it's me" and it's best we just end the relationship for now so we're the responsible party and end any future potential grief.
Read my comment below on why, but I don't think we'd be comfortable facilitating that.
I'll have a more in-depth response for this soon hopefully. I've edited out my comment for now because it's too vague and may be taken the wrong way.
P.S. we tried doing this in the past, you should be able to read about our side of the story if you find a copy of the lawsuit against the provider that cut off dedicated servers we paid for and wouldn't even release them temporarily for customer data. We just wouldn't want to facilitate it only for the core problem to still be there for the customers (a third party.)
If a customer really wants to do that we're all ears so we'll help them out of course in their ticket.
Behavior like this is only going to ensure we don't give out IPv6 to anyone unless they purchase a plan that comes officially with IPv6. For reference this guy made two "urgent" tickets about needing IPv6 on some old specials.
I DEMAND IPV6!
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
I DEMAND IPV6!
I bench YABS 24/7/365 unless it's a leap year.
Well, in his defense, he is not wrong. You should have a way to find tickets older then X days and prioritize them OR reply to them OR some way to let them know what to do.
Your service is very unreliable (at least as far as i can see from the people on this forum), but since you never said 100% uptime, no complains there, specially at that price. IP changes are not good, but if unavoidable, then so be it.
However, not replying to customer ticket IS a problem. So if you cannot hire more people to reply to tickets, get less customers OR charge them PER ticket opened/replied. Basically some way to reduce the number of tickets pending replies for over X days.
What is the "X" number of days? You can define that, but a good number is 5 working days.
We need LowEndLawyer to find those.
Virtual Machine Solutions LLC should be one side, ColoCrossing should be the other. Or maybe Deluxe?
VirMach is based in LA, so I would assume it should be in LA courts? I have no idea how Murica system works.
Found this, have no idea how to get a copy
https://dockets.justia.com/docket/california/cacdce/2:2023cv01787/877808
https://www.law.com/radar/card/virtual-machine-solutions-llc-v-deluxe-corporation-et-al-48077854-r/
https://trellis.law/doc/155455152/civil-case-cover-sheet-filed-by-virtual-machine-solutions-llc-plaintiff-filed-by-virtual-machine-solutions-llc-plaintiff
Why is poor Jon Biloh getting sued? He claimed like 1757517157 times he has nothing to do with ColoCrossing!?
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
Don't give him those kind of ideas.
I demand BGP session.
I have my own LowEndASN and IPv6 subnets now, which are superior to provider's subnets.
We accept Karma donations for the last flan. 🍮 affbrr
Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.
His ticket was definitely in the queue, and skipped on purpose. He already knew he used the IPv6 button twice. We're not going to focus on prioritizing answering tickets that request urgent IPv6. Because once it's answered it's guaranteed to turn into an argument or another ticket being created if someone is already resorting to ignoring any procedure. In fact I'm pretty sure something like that already occurred so he was marked accordingly. This helps us get to the right tickets on time.
His ticket did also receive an AI response that correctly told him we don't officially offer IPv6, IIRC. If an AI can find this information because you didn't even type in "IPv6" into the knowledgebase then the ticket is not guaranteed to receive any further response, especially on a custom ticket.
Customers have the option to purchase the correct support level if they want responses to everything, even if it's in the knowledgebase and we'll go over everything with them. So your suggestion is already effectively implemented if that's the level of support someone requires.
Oh also I didn't really announce this but this is pretty cool, everyone should know it exists now. We hooked up our helpdesk chat bot on the website to GPT as well, and it will be extremely helpful in answering questions for you if you're just quickly trying to have a policy or content in a knowledgebase article or information our website presented to you. Even works pretty well for being able to quickly figure things out for your operating system although for that you can just use ChatGPT directly.
Some examples, these are from tickets I reviewed/answered today, which it answered correctly for those most common situations that the customers were facing.
Disallow opening tickets until 12 hours after (1) the reset button has been pressed and (2) VNC connection has been established and lasted at minimum of 300 seconds.
We accept Karma donations for the last flan. 🍮 affbrr
That's just stupid. If a VPS isn't working, people will first try to reset it, followed by opening a support ticket. Since they already have bots replying to the tickets, it makes more sense to just feed the bot answers to "VPS not working" questions with unmount ISO and such.
Wont that cause issues with people using Alpine linux which requires the ISO to boot if you use their minimal installation?
Anybody running Alpine will have enough clues to figure it out on their own. That's not this crew.
True. And they can just do the full installation and boot from disk, even though that will lower their disk space.
Reason for Outage
Date: July 31, 2023
Summary:
This document serves as the Reason for Outage (RFO) to provide a comprehensive explanation of the network interruption that occurred on July 28th, 2023. The purpose of this RFO is to outline the root cause, impact, actions taken for resolution, and preventative measures to avoid similar incidents in the future.
Incident Overview:
On July 28th, 2023, at approx. 6PM EST a network interruption was experienced in San Jose, Redondo Beach, and Secaucus. This interruption resulted in a partial or complete loss of network connectivity and services for affected services. The incident was resolved at on July 28th, 2023 approx. 8:25PM with the exception of customers that were affected by a switch failure in Secaucus.
Root Cause Analysis:
After a thorough investigation, the root cause of the network interruption has been identified as follows:
Issue with common upstream provider we have in all three locations.
An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.
Impact:
The network interruption had the following significant impact:
Downtime: Affected systems experienced a loss of connectivity, leading to disruptions in services.
Actions Taken:
Upon identifying the root cause, the following actions were taken to resolve the network interruption:
Immediate Notification to Upstream Provider: The network team promptly contacted upstream providers to resolve the upstream issue.
Testing and Verification: After the upstream provider implemented the fix, DediPath performed thorough testing and verification were performed to ensure the stability and functionality of the network.
Since the incident was resolved we have opened discussions with other providers to prevent this situation from occurring again.
Conclusion:
The network interruption experienced on July 28th was a significant incident that impacted the organization and its users. Through a comprehensive root cause analysis and implementation of preventative measures, we aim to strengthen the network's resilience and provide a more robust and reliable service to our customers. We apologize for any inconvenience caused and remain committed to continually improving our network infrastructure.
If you have any further questions or concerns, please do not hesitate to reach out to our support team at [email protected]
Sincerely,
DediPath
Powerful AMD Ryzen VPS (aff)
Just wanted to give a shout out to Virmach.
After almost 6 months, I have finally gotten my Stromonic Refugee VPS (NVMe 1G), that too in Tokyo.
Since my Stromonic VPS billing had expired in June, I was expecting just a price match at this point of time - but Virmach has included some free months in the plan!
Thanks again, @VirMach !
The Ultimate Speedtest Script | Get Instant Alerts on new LES/LET deals | Cheap VPS Deals | VirMach Flash Sales Notifier
FREE KVM VPS - FreeVPS.org | FREE LXC VPS - MicroLXC
I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?
The reason for the outage, which the RFO doesn't really answer.
I am a representative of Advin Servers
(I recognise that the language may be hard for some and it isn't exactly brimming with information.)
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Well they took a page and a half to say, "Our upstream messed up. We called them. They fixed it." but never what it was nor how they're going to try to make it not happen again only that they're having "discussions with other providers".
^ Agreed, regards the what but to be fair, they can't really elaborate, on [any?] discussions with other providers.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
If they'd told us the "what" those discussions might not be as important to know since if it was a technical issue then they'd be able to discuss it.....
Logged in, since I was on the hunt for an idle machine.
The new Panel, haaayaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
The CSS was bugging through the footer.
Free NAT KVM | Free NAT LXC
NYCB028 - Operation Timed Out After 90000 Milliseconds With 0 Bytes Received
NYCB028 is up for me. Last outage was reported in July 28.
Or that's just control panel issue not actual server outage report?
my NY vps is down AGAIN. I can't ssh. I can't open my service page in virmach dashboard. I can't reboot, I can't do a damn thing
what an agony it's been with you guys...
What node?
I don't have the node number. I can't access my service page...
@cyforex - NYCB043 is down, NYCB028 is overloading. Does ether of these sound familiar ?
yes it is NYCB028.
I was able to open my service page for a minute, it's down again though.
Should be better now.
NYCB027 has been unavailable for over 100 days. New record?
Dataplane.org's current server hosting provider list
↑↑↑↑↑↑
Wrong vehicle above, here it goes the correct one
Ontario Dildo Inspector
Yeah cannot access
NYCB043onhttps://billing.virmach.comalthough VPS is working fine.Powerful AMD Ryzen VPS (aff)