11 ms·

Tell HN: Read up on your GitHub Support SLA

193 points by zamalek 4y ago

A few weeks ago we experienced an outage for a few hours, we got 500's from both NPM and Nuget private GitHub feeds. This essentially halted progress in our CI pipeline, so trunk progress ceased for a few hours. Downtime happens. What's alarming is that as an enterprise customer ($250/user/year) we only got a response 11 days later containing, essentially, these things: * "Check again." If the turnaround on a support ticket is truly 11 days, we would have been facing a 22 day outage (as we'd expect yet another 11 days after responding "it's still happening"). * "You have no SLA." * "If you want support, I can direct you to our sales team." If, god forbid, Git access (or everything) had been down, we would have been scrambling to continue business, we wouldn't have had a number to call, and we likely would have had to pony up the cash. I strongly recommend you take a good look you fall here: https://github.com/premium-support. Note that "< 8 hours" under "Enterprise" mean absolutely nothing, as they aren't guaranteed (per your contract). A more honest value in the column would be "N/A." You have to get hold of sales to learn about premium support pricing, it isn't publicly disclosed. This is likely to prevent you from budgeting for premium support only in the event that you need it. If your business continuity depends on GitHub Enterprise, and you don't have Premium support, you need to pay, plan, or change.

alaricus 4y ago
It's time to move away from GitHub. There are better alternatives such as Codeberg or Gitlab.
- vorpalhex 4y ago
  Gitea is very pleasant to self host...
  - alaricus 4y ago
    True, I forgot Gitea!
  - yonixw 4y ago
    I always see Gitea recommended, but is it as mature as gitlab self hosted? From authentication methods (SAML, Cognito) to code review, issues, wiki?
  - bityard 4y ago
    Gitea has CI now?
    - mrelectric 4y ago
      Not built-in, but it's documented and supported by the community somewhat. Take a look at the docs and previous hn threads
    - rglullis 4y ago
      Gitea and Drone CI work really well together and are so much ligher, easier to deploy and manage compared to Gitlab that is not even funny.
      - vorpalhex 4y ago
        There is also Woodpecker CI if you want a lightweight Drone fork.
      - bogwog 4y ago
        Does "lighter" really matter in this case? From first-hand experience with Gitea, I can tell you that it most certainly is not more reliable than Gitlab. I've gotten 500 internal server errors from just clicking around the UI too fast while it was running locally on my machine. Constant errors and bugs after running it for about 4 months were ultimately what pushed me to Gitlab. Don't know anything about Drone CI, but it seems to me like a lot more work to manage two separate systems than it is to manage a single Gitlab instance, where everything is already nicely integrated. I'm not a sysadmin by any stretch of the imagination, but I was still able to set up Gitlab, Gitlab CI with a bunch of runners, Gitlab Pages, and offsite backups with very little effort on my self-hosted instance. All I had to do was edit one config file to enable the various services (backups were with borg and systemd via the "gitlab-ctl" CLI) Been running that setup for probably 2 years no with the only outages being external internet/power outages. I'm the only user, so my usage isn't at all going to reflect OP's needs, but it's still more reliability than I ever got from Gitea.
  - grepfru_it 4y ago
    Lacks search functionality (among other features)
- zamalek 4y ago
  I'm pushing for Gitlab (who have an SLA built into their similarly priced offering), but obviously the stakeholders need to decide how we eat this risk.
  - jnsaff2 4y ago
    See my comment here: https://news.ycombinator.com/item?id=31411169 https://news.ycombinator.com/item?id=31411169 I don't think GitLab is better in this front.
    - alaricus 4y ago
      I use both GitHub and Gitlab for contributing to various open source projects. In my experience Gitlab is far superior. Github is too sluggish and buggy compared to Gitlab.
- rsstack 4y ago
  I think you're comparing free GitHub to Codeberg. GitHub is a lot more than code hosting for open source.
treis 4y ago
It says right there: Guaranteed SLA? No
- mjw1007 4y ago
  Yes, it says so on the page zamalek helpfully linked. But it doesn't say so on the page you get to if you select "Pricing" from github's homepage. Nor, as far as I can tell, does it say so on any page linked to from that page.
  - basisword 4y ago
    Why would they need to list things that _aren't_ included? Where would that list stop?
    - mjw1007 4y ago
      Generally, it would list the things that aren't included in that tier but are in higher tiers. Like they do for most of their features.
      - basisword 4y ago
        That makes sense.
  - treis 4y ago
    On the pricing page I see that Enterprise includes: Standard Support - GitHub Support can help you troubleshoot issues you run into while using GitHub. Get support via the web. Premium support is listed as "available" (so not included): With Premium, get a 30-minute SLA and 24/7 web and phone support. With Premium Plus, get everything in Premium plus your own Support Account Manager and more.
    - mjw1007 4y ago
      Right, from which you can infer that you don't get a 30-minute SLA. But not that you get no SLA at all.
ralph84 4y ago
11 days is a very long response time, but do you really think a quicker response would have changed the end result? GitHub is a massively multi-tenant SaaS. When they have an outage there’s really not much customers or GitHub’s support team can do other than wait for the outage to be resolved.
- zamalek 4y ago
  Amazon and Azure have much larger multi-tenant concerns and are able to pull of an SLA.
  - deathanatos 4y ago
    Really? I've been ignored on Azure tickets for longer than their stated SLA. During outages, too.
    - zamalek 4y ago
      Anecdata: we haven't seen that with Azure. At least you have an SLA, so they'll refund/discount you.
      - deathanatos 4y ago
        That's incredible to me. Their support is completely and utterly inept, AFAICT. Just today, I've been asked for what availability for a meeting I have between the hours of 9pm and 6am (and no, that's not a typo!). You can't paste errors into the ticket. Their support system doesn't even support all of printable ASCII. The reps don't read the ticket before responding. If you can't replicate the error in front of their eyes, it doesn't exist, and even if you can, they won't believe you. I've literally had them defend 56 kpbs as being "good enough throughput", I've had "What is your ISP?" on "we get 500 Internal Server Error from $service" (and … our ISP is you, Azure…) … yeah. The list of idiocy we've seen just goes on and on and on. Their support team wants to talk about "how can we architect a cloud system that'll blah blah enterprise blah", I just want valid API calls to succeed. I'm an eng, I can do the building, I just need APIs that aren't hot garbage. (The outage I allude to in the above comment is actually mentioned in passing in [1]. I had to link to that blog post in the support ticket! (So thank you, Scott Helme, for writing it.)) [1]: https://scotthelme.co.uk/lets-encrypt-root-expiration-post-mortem/ https://scotthelme.co.uk/lets-encrypt-root-expiration-post-m...
hatware 4y ago
I'm not sure what service GitHub thinks it is providing these days. It's like they're trying to lose customers.
- count 4y ago
  I spent 2 months trying to get someone at GitHub to add another user. If you have GitHub Enterprise, and are paying them, you have to go through sales to add users. Good fucking luck getting them to call you back or respond if you aren't adding 1000+ seats. It's unbelievable.
midislack 4y ago
This is why you need to have somebody learn Unix and figure out how to run things locally. Or just kick back and relax when the systems you elected to depend on, but do NOT control, go tits up. It’s really on you.
- zamalek 4y ago
  Our contract is up for renewal in a few days, so we'd likely struggle to pull off self-hosted in that time. Self-hosting has been the watercooler talk, but we're currently migrating away from Circle CI (to GitHub <facepalm>), so it was on the cards for next year.
  - midislack 4y ago
    It takes like fifteen minutes to set things up. Every startup needs a competent Unix sysadmin. EDIT: a Threadripper will do for CI. Quick as you like.
    - deleted 4y ago
      [deleted]
    - anonymousab 4y ago
      GitHub is far, far more than just a git repo. Issue tracking, project boards, commit status systems/check systems, deployment tracking and monitoring, fully fledged CI and deployment pipelines (actions/workflows) written in their own flavor, etc. All sorts of webhooks, complex arrangements of teams and access controls, cross repo, cross,-org and cross enterprise account linkages. Large object storages, container registries, and package repositories. And of course, the existing context of all this stuff; setting up an alternative != completely migrating and validating everything from the original. Replacing all that with something as scalable, flexible and agreeable with potentially thousands of global developers is far more than '15 minutes' of work. Several orders of magnitude more. Even on the git repo question alone, if you're an enterprise of some size, you'll have hundreds or maybe thousands of repos that could be potentially gigabytes in size (for any one repo) for code alone. Moving to a self hosted solution requires far more than just throwing some threadrippers and enterprise drives at the problem. And that's assuming the best outcomes. A competent UNIX sysadmin would be the one yelling not to throw the baby out with the bathwater here, because they would know just how hard this stuff is at scale.
rsstack 4y ago
As Enterprise-plan customers we also had a support ticket recently ignored for 8 days (not hours) until I pinged on it. That's super unusual for paid SaaS. I can't think of any other vendor that ignored my support tickets for that long (not even "we're looking into it"), including the dreaded Google.
- larrik 4y ago
  I had a paid support AWS bug ticket sit for 6 weeks before I found someone high enough on the chain to get it looked at.
  - rsstack 4y ago
    > before I found someone high enough on the chain Many orgs have difficulties with escalating issues outside of the support organization. AWS never _ignored_ a ticket I opened.
    - larrik 4y ago
      This ticket had zero replies or movement until I went nuclear.
      - pojzon 4y ago
        What was the ticket about ?
rglullis 4y ago
Really? $250/user/year, for how many users? There was recently a thread about someone asking about password management solutions for an organization of 10k employees, and someone recommended 1Password, which I already find hard to believe it could ever make financial and operational sense. [0] Now, these prices from GH can make sense if you are a team of 10-50, but I wonder what would be the point where it wouldn't take a bean-counter to say "can't we just hire someone else do that in-house, part-time? It would cost as much or less, but at least we would have a lot more control over the system and we wouldn't be at the mercy of a company that treats us as cattle." I see on your profile page you are on Matrix. Would you mind if I add you there to chat (or add me @raphael:communick.com)? Seems like your company could have so many different cheaper and better solutions for their needs, I've been thinking for a while whether there could be a market in "open source strategy consulting". [0]: https://news.ycombinator.com/item?id=31582161 https://news.ycombinator.com/item?id=31582161
- throwaway787544 4y ago
  Bean-counting enterprises do all kinds of annoying shit to deal with the GitHub cost, like automatically disabling user accounts after 30 days if unused, or multiple orgs.
  - hanifbbz 4y ago
    How does multiple orgs reduce costs?
    - makeitdouble 4y ago
      I suppose it’s about setting different tiers depending on the orgs. For instance a higher tier for the org with your main dev repos and deployment/CI system, and more basic tier for orgs with your translators’ and QA team’s repos, etc.
    - throwaway787544 4y ago
      Limiting number of licenses and requiring business justification, so one part of the org can't on-board 50 users that probably never need to commit anything. I imagine at some point GH might get variable pricing like NewRelic where you pay less for a read-only user.
throwaway787544 4y ago
Redundant Git access and repo access can be dealt with by using Artifactory. But then you have to hope Artifactory works. The SaaS offering isn't very stable and self-hosting is a huge pain in the butt. You could also architect your business not to go down when an upstream vendor goes offline, but maybe I'm crazy.
- giancarlostoro 4y ago
  > You could also architect your business not to go down when an upstream vendor goes offline, but maybe I'm crazy. This is what I'm wondering the most about honestly. With Azure DevOps we have slots, so if a deployment fails, there is no switch that happens and the current available online version stays online. Something about putting all your eggs in one basket, but if you're going to do it anyway, make sure you handle a pipeline failure cleanly. A failure to build should not take down production, ever.
- busterarm 4y ago
  Can confirm Artifactory is a PITA. Used to use Rietveld and now using Gerrit. You have to buy in to that code review methodology and you lose a lot of the other things (issue tracking, CI), but those can be handled elsewhere by better/more-specific tools.
meibo 4y ago
This is pretty surprising to me, as even as a free GitHub user that probably has an above average amount of contact with GitHub support, I've never had to wait more than 30 minutes to an hour for a reply to a ticket. If they really give you worse service than free customers if you don't have a good SLA, that's a little troubling and they should maybe rethink their support strategy - but I also imagine that helping with outages is a little more complex than regular support tasks(account recovery, sponsors, etc).
- junon 4y ago
  I've struggled with their support for a few years now. One of my repositories, a very popular one, is used as an example in some of GitHub's own educational resources, which causes loads of spam issues, PRs and comments on said repository. Support has refused to so much as acknowledge the problem for two years now, if not longer. It got so bad I stopped paying for GitHub entirely and will never give another cent.
hanifbbz 4y ago
Reading SLA can be complicated but it definitely pays back both in terms of money and reduced risk. Here's a dissection of S3 SLA as an example: https://alexewerlof.medium.com/dissecting-the-s3-sla-26421dda2d56 https://alexewerlof.medium.com/dissecting-the-s3-sla-26421dd... and Amazon is quite good.
GitHub_Support 4y ago
GitHub Support here. This does not live up to the level of service we strive to offer our customers. We would love to follow up directly to learn more about this incident as it appears we have opportunities to learn and improve from this experience. I understand the irony of asking to open another Support ticket, however, @zamalek please do open another Support ticket with subject “Hacker News follow up” and a Support Manager will reach out.
- sascha_sl 4y ago
  We have plenty of tickets like this too - in the Enterprise Premium tier. One about SLA, about 10 for Actions misbehaving... you should really just have look at your own metrics and not give someone complaining to the internet white glove treatment. For the amount of money you take for Enterprise Premium you really ought to offer it to everyone without complaining.
  - SenHeng 4y ago
    Applying good faith interpretation. It's possible that there is a bottle neck in the system that is invisible, possibly intentionally by someone in the middle, to people higher up in the chain. This is a way for them to break that blockage, and put some spot light on it. What this does now is create a specific marker 'Hacker News follow up' that cannot be swept under the rug. There will be eyes on this particular issue, both inside and outside the company.
- deathanatos 4y ago
  What a boilerplate PR response. Today it's Github, but tomorrow it'll be the same story, different managed service. OP's problem isn't even specific to Github, the entire "aaS" industry seems rife with over-promise, under-deliver. Yeah, you want to "take this offline" and handle OP's case individually, and perhaps OP gets their demands met, some sort of service credit, or something. But what the rest of us want is real systemic change, to where managed services like this actually give us real value, and not "marginal value, but nothing works like it ought to and you're going to spend a lot of time working around the bugs and gluing the parts together", where every bug report (which has to be filed as a support ticket) is met with "you're holding it wrong", or where the service goes down and the status page gaslights us, or … Buying managed services instead of letting engineers do their jobs is today's "nobody got fired for buying IBM".
deleted 4y ago
[deleted]
dkasper 4y ago
Technically git is distributed version control and should be workable even if GitHub is down. You could fetch from your coworkers directly even for instance. We’ve really fallen a long way if GitHub is a single point of failure.
- ComradePhil 4y ago
  They sell CI/CD pipeline service, which one can build their infra around. This is supposed to work "in the cloud" with availability/reliability of the cloud... and this is one of their selling points.

193 points by zamalek 4y ago

alaricus 4y ago

It's time to move away from GitHub. There are better alternatives such as Codeberg or Gitlab.

vorpalhex 4y ago
Gitea is very pleasant to self host...
- alaricus 4y ago
  True, I forgot Gitea!
- yonixw 4y ago
  I always see Gitea recommended, but is it as mature as gitlab self hosted? From authentication methods (SAML, Cognito) to code review, issues, wiki?
- bityard 4y ago
  Gitea has CI now?
  - mrelectric 4y ago
    Not built-in, but it's documented and supported by the community somewhat. Take a look at the docs and previous hn threads
  - rglullis 4y ago
    Gitea and Drone CI work really well together and are so much ligher, easier to deploy and manage compared to Gitlab that is not even funny.
    - vorpalhex 4y ago
      There is also Woodpecker CI if you want a lightweight Drone fork.
    - bogwog 4y ago
      Does "lighter" really matter in this case? From first-hand experience with Gitea, I can tell you that it most certainly is not more reliable than Gitlab. I've gotten 500 internal server errors from just clicking around the UI too fast while it was running locally on my machine. Constant errors and bugs after running it for about 4 months were ultimately what pushed me to Gitlab. Don't know anything about Drone CI, but it seems to me like a lot more work to manage two separate systems than it is to manage a single Gitlab instance, where everything is already nicely integrated. I'm not a sysadmin by any stretch of the imagination, but I was still able to set up Gitlab, Gitlab CI with a bunch of runners, Gitlab Pages, and offsite backups with very little effort on my self-hosted instance. All I had to do was edit one config file to enable the various services (backups were with borg and systemd via the "gitlab-ctl" CLI) Been running that setup for probably 2 years no with the only outages being external internet/power outages. I'm the only user, so my usage isn't at all going to reflect OP's needs, but it's still more reliability than I ever got from Gitea.
- grepfru_it 4y ago
  Lacks search functionality (among other features)
zamalek 4y ago
I'm pushing for Gitlab (who have an SLA built into their similarly priced offering), but obviously the stakeholders need to decide how we eat this risk.
- jnsaff2 4y ago
  See my comment here: https://news.ycombinator.com/item?id=31411169 https://news.ycombinator.com/item?id=31411169 I don't think GitLab is better in this front.
  - alaricus 4y ago
    I use both GitHub and Gitlab for contributing to various open source projects. In my experience Gitlab is far superior. Github is too sluggish and buggy compared to Gitlab.
rsstack 4y ago
I think you're comparing free GitHub to Codeberg. GitHub is a lot more than code hosting for open source.

treis 4y ago

It says right there: Guaranteed SLA? No

mjw1007 4y ago
Yes, it says so on the page zamalek helpfully linked. But it doesn't say so on the page you get to if you select "Pricing" from github's homepage. Nor, as far as I can tell, does it say so on any page linked to from that page.
- basisword 4y ago
  Why would they need to list things that _aren't_ included? Where would that list stop?
  - mjw1007 4y ago
    Generally, it would list the things that aren't included in that tier but are in higher tiers. Like they do for most of their features.
    - basisword 4y ago
      That makes sense.
- treis 4y ago
  On the pricing page I see that Enterprise includes: Standard Support - GitHub Support can help you troubleshoot issues you run into while using GitHub. Get support via the web. Premium support is listed as "available" (so not included): With Premium, get a 30-minute SLA and 24/7 web and phone support. With Premium Plus, get everything in Premium plus your own Support Account Manager and more.
  - mjw1007 4y ago
    Right, from which you can infer that you don't get a 30-minute SLA. But not that you get no SLA at all.

ralph84 4y ago

11 days is a very long response time, but do you really think a quicker response would have changed the end result? GitHub is a massively multi-tenant SaaS. When they have an outage there’s really not much customers or GitHub’s support team can do other than wait for the outage to be resolved.

zamalek 4y ago
Amazon and Azure have much larger multi-tenant concerns and are able to pull of an SLA.
- deathanatos 4y ago
  Really? I've been ignored on Azure tickets for longer than their stated SLA. During outages, too.
  - zamalek 4y ago
    Anecdata: we haven't seen that with Azure. At least you have an SLA, so they'll refund/discount you.
    - deathanatos 4y ago
      That's incredible to me. Their support is completely and utterly inept, AFAICT. Just today, I've been asked for what availability for a meeting I have between the hours of 9pm and 6am (and no, that's not a typo!). You can't paste errors into the ticket. Their support system doesn't even support all of printable ASCII. The reps don't read the ticket before responding. If you can't replicate the error in front of their eyes, it doesn't exist, and even if you can, they won't believe you. I've literally had them defend 56 kpbs as being "good enough throughput", I've had "What is your ISP?" on "we get 500 Internal Server Error from $service" (and … our ISP is you, Azure…) … yeah. The list of idiocy we've seen just goes on and on and on. Their support team wants to talk about "how can we architect a cloud system that'll blah blah enterprise blah", I just want valid API calls to succeed. I'm an eng, I can do the building, I just need APIs that aren't hot garbage. (The outage I allude to in the above comment is actually mentioned in passing in [1]. I had to link to that blog post in the support ticket! (So thank you, Scott Helme, for writing it.)) [1]: https://scotthelme.co.uk/lets-encrypt-root-expiration-post-mortem/ https://scotthelme.co.uk/lets-encrypt-root-expiration-post-m...

hatware 4y ago

I'm not sure what service GitHub thinks it is providing these days. It's like they're trying to lose customers.

count 4y ago
I spent 2 months trying to get someone at GitHub to add another user. If you have GitHub Enterprise, and are paying them, you have to go through sales to add users. Good fucking luck getting them to call you back or respond if you aren't adding 1000+ seats. It's unbelievable.

midislack 4y ago

This is why you need to have somebody learn Unix and figure out how to run things locally. Or just kick back and relax when the systems you elected to depend on, but do NOT control, go tits up. It’s really on you.

zamalek 4y ago
Our contract is up for renewal in a few days, so we'd likely struggle to pull off self-hosted in that time. Self-hosting has been the watercooler talk, but we're currently migrating away from Circle CI (to GitHub <facepalm>), so it was on the cards for next year.
- midislack 4y ago
  It takes like fifteen minutes to set things up. Every startup needs a competent Unix sysadmin. EDIT: a Threadripper will do for CI. Quick as you like.
  - deleted 4y ago
    [deleted]
  - anonymousab 4y ago
    GitHub is far, far more than just a git repo. Issue tracking, project boards, commit status systems/check systems, deployment tracking and monitoring, fully fledged CI and deployment pipelines (actions/workflows) written in their own flavor, etc. All sorts of webhooks, complex arrangements of teams and access controls, cross repo, cross,-org and cross enterprise account linkages. Large object storages, container registries, and package repositories. And of course, the existing context of all this stuff; setting up an alternative != completely migrating and validating everything from the original. Replacing all that with something as scalable, flexible and agreeable with potentially thousands of global developers is far more than '15 minutes' of work. Several orders of magnitude more. Even on the git repo question alone, if you're an enterprise of some size, you'll have hundreds or maybe thousands of repos that could be potentially gigabytes in size (for any one repo) for code alone. Moving to a self hosted solution requires far more than just throwing some threadrippers and enterprise drives at the problem. And that's assuming the best outcomes. A competent UNIX sysadmin would be the one yelling not to throw the baby out with the bathwater here, because they would know just how hard this stuff is at scale.

rsstack 4y ago

As Enterprise-plan customers we also had a support ticket recently ignored for 8 days (not hours) until I pinged on it. That's super unusual for paid SaaS. I can't think of any other vendor that ignored my support tickets for that long (not even "we're looking into it"), including the dreaded Google.

larrik 4y ago
I had a paid support AWS bug ticket sit for 6 weeks before I found someone high enough on the chain to get it looked at.
- rsstack 4y ago
  > before I found someone high enough on the chain Many orgs have difficulties with escalating issues outside of the support organization. AWS never _ignored_ a ticket I opened.
  - larrik 4y ago
    This ticket had zero replies or movement until I went nuclear.
    - pojzon 4y ago
      What was the ticket about ?

rglullis 4y ago

Really? $250/user/year, for how many users? There was recently a thread about someone asking about password management solutions for an organization of 10k employees, and someone recommended 1Password, which I already find hard to believe it could ever make financial and operational sense. [0] Now, these prices from GH can make sense if you are a team of 10-50, but I wonder what would be the point where it wouldn't take a bean-counter to say "can't we just hire someone else do that in-house, part-time? It would cost as much or less, but at least we would have a lot more control over the system and we wouldn't be at the mercy of a company that treats us as cattle." I see on your profile page you are on Matrix. Would you mind if I add you there to chat (or add me @raphael:communick.com)? Seems like your company could have so many different cheaper and better solutions for their needs, I've been thinking for a while whether there could be a market in "open source strategy consulting". [0]: https://news.ycombinator.com/item?id=31582161 https://news.ycombinator.com/item?id=31582161

throwaway787544 4y ago
Bean-counting enterprises do all kinds of annoying shit to deal with the GitHub cost, like automatically disabling user accounts after 30 days if unused, or multiple orgs.
- hanifbbz 4y ago
  How does multiple orgs reduce costs?
  - makeitdouble 4y ago
    I suppose it’s about setting different tiers depending on the orgs. For instance a higher tier for the org with your main dev repos and deployment/CI system, and more basic tier for orgs with your translators’ and QA team’s repos, etc.
  - throwaway787544 4y ago
    Limiting number of licenses and requiring business justification, so one part of the org can't on-board 50 users that probably never need to commit anything. I imagine at some point GH might get variable pricing like NewRelic where you pay less for a read-only user.

throwaway787544 4y ago

Redundant Git access and repo access can be dealt with by using Artifactory. But then you have to hope Artifactory works. The SaaS offering isn't very stable and self-hosting is a huge pain in the butt. You could also architect your business not to go down when an upstream vendor goes offline, but maybe I'm crazy.

giancarlostoro 4y ago
> You could also architect your business not to go down when an upstream vendor goes offline, but maybe I'm crazy. This is what I'm wondering the most about honestly. With Azure DevOps we have slots, so if a deployment fails, there is no switch that happens and the current available online version stays online. Something about putting all your eggs in one basket, but if you're going to do it anyway, make sure you handle a pipeline failure cleanly. A failure to build should not take down production, ever.
busterarm 4y ago
Can confirm Artifactory is a PITA. Used to use Rietveld and now using Gerrit. You have to buy in to that code review methodology and you lose a lot of the other things (issue tracking, CI), but those can be handled elsewhere by better/more-specific tools.

meibo 4y ago

This is pretty surprising to me, as even as a free GitHub user that probably has an above average amount of contact with GitHub support, I've never had to wait more than 30 minutes to an hour for a reply to a ticket. If they really give you worse service than free customers if you don't have a good SLA, that's a little troubling and they should maybe rethink their support strategy - but I also imagine that helping with outages is a little more complex than regular support tasks(account recovery, sponsors, etc).

junon 4y ago
I've struggled with their support for a few years now. One of my repositories, a very popular one, is used as an example in some of GitHub's own educational resources, which causes loads of spam issues, PRs and comments on said repository. Support has refused to so much as acknowledge the problem for two years now, if not longer. It got so bad I stopped paying for GitHub entirely and will never give another cent.

hanifbbz 4y ago

Reading SLA can be complicated but it definitely pays back both in terms of money and reduced risk. Here's a dissection of S3 SLA as an example: https://alexewerlof.medium.com/dissecting-the-s3-sla-26421dda2d56 https://alexewerlof.medium.com/dissecting-the-s3-sla-26421dd... and Amazon is quite good.

GitHub_Support 4y ago

GitHub Support here. This does not live up to the level of service we strive to offer our customers. We would love to follow up directly to learn more about this incident as it appears we have opportunities to learn and improve from this experience. I understand the irony of asking to open another Support ticket, however, @zamalek please do open another Support ticket with subject “Hacker News follow up” and a Support Manager will reach out.

sascha_sl 4y ago
We have plenty of tickets like this too - in the Enterprise Premium tier. One about SLA, about 10 for Actions misbehaving... you should really just have look at your own metrics and not give someone complaining to the internet white glove treatment. For the amount of money you take for Enterprise Premium you really ought to offer it to everyone without complaining.
- SenHeng 4y ago
  Applying good faith interpretation. It's possible that there is a bottle neck in the system that is invisible, possibly intentionally by someone in the middle, to people higher up in the chain. This is a way for them to break that blockage, and put some spot light on it. What this does now is create a specific marker 'Hacker News follow up' that cannot be swept under the rug. There will be eyes on this particular issue, both inside and outside the company.
deathanatos 4y ago
What a boilerplate PR response. Today it's Github, but tomorrow it'll be the same story, different managed service. OP's problem isn't even specific to Github, the entire "aaS" industry seems rife with over-promise, under-deliver. Yeah, you want to "take this offline" and handle OP's case individually, and perhaps OP gets their demands met, some sort of service credit, or something. But what the rest of us want is real systemic change, to where managed services like this actually give us real value, and not "marginal value, but nothing works like it ought to and you're going to spend a lot of time working around the bugs and gluing the parts together", where every bug report (which has to be filed as a support ticket) is met with "you're holding it wrong", or where the service goes down and the status page gaslights us, or … Buying managed services instead of letting engineers do their jobs is today's "nobody got fired for buying IBM".

deleted 4y ago

[deleted]

dkasper 4y ago

Technically git is distributed version control and should be workable even if GitHub is down. You could fetch from your coworkers directly even for instance. We’ve really fallen a long way if GitHub is a single point of failure.

ComradePhil 4y ago
They sell CI/CD pipeline service, which one can build their infra around. This is supposed to work "in the cloud" with availability/reliability of the cloud... and this is one of their selling points.