Bitbucket's downtime is pretty much the same as Github's.
I use it at work and my team pushes to it approximately 40-50 times a day. In the last year the total amount of downtime I've experienced has been 4-8 hours. I pointed out the lack of downtime history to one of the guys when they asked if we could move to stash because we experienced 15 minutes down time twice in two days. (Also should point out we've experienced 10-24 hours downtime on our internal Jenkins so far this year)
It's just when you do experience downtime it feels really bad.
I used to use BB a lot, almost daily, last year. I would occasionally hit one of those "ssh issue" or "outage". The most problematic is BB cannot close issues automatically via commit message on some repositories. Some. It's rather annoying.
If you consider using BB or Github for real product, I advise you host yourself a server running either Gitlab or SCM-Manager (supports git, mercurial, svn) and when you push you should push to your "local" server and the remote server. This way you can still do some remote work during downtime without sending patches around. This is an option if you truly need a backup plan...
On the status page, click on “Month”, at the right of “System Metrics”. It gives the uptime for the current month only, unfortunately. So for April, it was 99.816%.
While I don't have anything smart to say about stuff like this, I'd love to see their postmortem on this one. Would be somewhat hilarious if it's another bad configuration push across their infrastructure. Github has had so many of them and especially with the recent article of the stock brokerage firm going bankrupt due to bad configuration/code push.
So how much does this affect work flow for Git? Doesn't seem like that much of a big deal for small downtime unless I'm hosting a public page or open source project. I, personally, use Bitbucket for the unlimited private repos, makes development easy for me so downtime doesn't affect my team that much since we can pull from each other still.
I just sent a push to BitBucket, and it seemed to be taking a while, so I figures I'd just grab a quick headline here, and the top story is BitBucket being down. So my timing is good?
Is it just slow for you? What connectivity are you using? For me it's not working at all. SSH says no suitable response from server. I had to merge a branch :(
[+] [-] gghh|12 years ago|reply
[+] [-] jroseattle|12 years ago|reply
Postmortem, please.....
[+] [-] rgvcorley|12 years ago|reply
I can't find a stat for BitBucket, does anyone know?
I'm considering switiching to GitHub for a private repo I'm currently hosting on BB, due to downtime.
[+] [-] johnnyfaehell|12 years ago|reply
I use it at work and my team pushes to it approximately 40-50 times a day. In the last year the total amount of downtime I've experienced has been 4-8 hours. I pointed out the lack of downtime history to one of the guys when they asked if we could move to stash because we experienced 15 minutes down time twice in two days. (Also should point out we've experienced 10-24 hours downtime on our internal Jenkins so far this year)
It's just when you do experience downtime it feels really bad.
[+] [-] korzun|12 years ago|reply
There are issues like hanging on pull requests/merges at random or not loading the diff.
Frustrating.
[+] [-] Achshar|12 years ago|reply
[+] [-] yeukhon|12 years ago|reply
I used to use BB a lot, almost daily, last year. I would occasionally hit one of those "ssh issue" or "outage". The most problematic is BB cannot close issues automatically via commit message on some repositories. Some. It's rather annoying.
If you consider using BB or Github for real product, I advise you host yourself a server running either Gitlab or SCM-Manager (supports git, mercurial, svn) and when you push you should push to your "local" server and the remote server. This way you can still do some remote work during downtime without sending patches around. This is an option if you truly need a backup plan...
[+] [-] fideloper|12 years ago|reply
It makes sense to choose one as your primary to meet your workflows, but having both means work can continue when one has an outage.
You can even automate pushing/updating commits to whichever you choose to be the secondary.
(Or of course you can setup your own git server for a third backup in case the internet explodes).
[+] [-] hk__2|12 years ago|reply
[+] [-] factorialboy|12 years ago|reply
??
[+] [-] keehun|12 years ago|reply
[+] [-] unistdh|12 years ago|reply
[+] [-] yeukhon|12 years ago|reply
[+] [-] kevinburke|12 years ago|reply
[+] [-] lighthazard|12 years ago|reply
[+] [-] Achshar|12 years ago|reply
[+] [-] pera|12 years ago|reply
[+] [-] bognition|12 years ago|reply
you forgot a very important word
[+] [-] why-el|12 years ago|reply
[+] [-] fmx|12 years ago|reply
[+] [-] klrr|12 years ago|reply
[+] [-] johnnyfaehell|12 years ago|reply
It would be rather silly to host your status page on your main production infrastructure since if it goes down so does your status page.
Personally unless you're a major player I think you should always outsource your status page.
[+] [-] anton_gogolev|12 years ago|reply
[1]: https://www.gitlab.com/ [2]: http://hglabhq.com/
[+] [-] nickstinemates|12 years ago|reply
There's usually a curve where it makes sense to invest in self-host, but the Bit bucket Slate has been really great.
[+] [-] rmthompson|12 years ago|reply
[+] [-] Achshar|12 years ago|reply