Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Quality vs Quantity - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Quality vs Quantity

2»

Comments

  • @GreenHostBox said:
    Did joodle just predict what Steven_F was going to say?

    :O All hail @joodle!

    @agoldenberg said:

    Aww, stop it you. Yeah, we're working on that! Only one thing is holding us back from moving from Buffalo to Choopa, and that's IP pricing. :(

  • zevuszevus Member

    @Steven_F said:
    Something I've been wondering about with DediCube is the question of quality vs quantity.

    Would you rather save $25 a month on a dedicated server, but get a lower quality network/support team or spend that extra money? To you, where is that perfect mix of quality vs pricing?

    w/ IPMI or some way to remote reboot/enable rescue mode (ala hetzner robot), only time I'd ever message support would be for a hardware failure. I'd rather save the $25/mo.

    I doubt anybody from here is going to buy dedi from dedicube. There are a lot of cheaper / better choices here and in WHT.

    I bought one!

  • @zevus said:
    I bought one!

    :D We're working on some things to help speed everything up and automate a lot more, plus 24x7 US based support. Look for the e-mail in a few weeks.

  • @Steven_F said:
    What are reasonable hardware replacement SLA times, do y'all think?

    24 hours at the most, under 12 hours would be fine really. You should probably try to aim for within a few hours though.

  • @WSCallum said:
    24 hours at the most, under 12 hours would be fine really. You should probably try to aim for within a few hours though.

    That's way too long

  • WSCallumWSCallum Member
    edited July 2014

    @Steven_F said:
    That's way too long

    Hence why I said 'at the most' and recommended you should aim within a few hours. Most DCs usually do it within 4 hours or so, depends on how quick their support is.

  • @WSCallum said:
    Hence why I said 'at the most' and recommended you should aim within a few hours. Most DCs usually do it within 4 hours or so, depends on how quick their support is.

    Hell, even 4 hours is a lot in my book.

  • @Steven_F said:
    Hell, even 4 hours is a lot in my book.

    Any amount of time is a lot for hardware failure, responding and replacing to those sort of incidents as quickly as possible is the main thing.

  • @WSCallum said:
    Any amount of time is a lot for hardware failure, responding and replacing to those sort of incidents as quickly as possible is the main thing.

    Well, I wouldn't go that far. It happens, it's part of the risk of running without HA. But I'd say 30 - 60 minutes is a reasonable time frame.

  • @Steven_F said:
    Well, I wouldn't go that far. It happens, it's part of the risk of running without HA. But I'd say 30 - 60 minutes is a reasonable time frame.

    Any amount of downtime isn't good really, but yes, the likes of hardware failure is unavoidable, it's about how quickly it's responded to and how transparent you are with your customers that counts. Too many companies are gaining a bad rep just for not keeping clients updated when things go wrong.

    If you can aim for that sort of timeframe for replacements, that's good enough for most!

  • @WSCallum said:

    The way I see it: if your business relies on this hardware to generate several-thousand dollars or more a day, you better have some sort of high availability.

    If not, a few hours of downtime won't kill you, BUT all hardware really should be replaced in 30 - 60 minutes.

  • ad0ad0 Member

    @vampireJ said:
    I doubt anybody from here is going to buy dedi from dedicube. There are a lot of cheaper / better choices here and in WHT.

    WTH has nice Infractions if you were posting there then you know or are taking our traffice from here?

Sign In or Register to comment.