5 ms·
Sorry for the slow update, incident was triggered and analysis continues. You can follow at https://gitlab.com/gitlab-com/gl-infra/production/-/issues/5952 http
by dnsmichi 5y ago
Sorry for the slow update, incident was triggered and analysis continues. You can follow at https://gitlab.com/gitlab-com/gl-infra/production/-/issues/5952 https://gitlab.com/gitlab-com/gl-infra/production/-/issues/5...
> Where else do people go for confirmation of problems?
You are using it already :) https://status.gitlab.com/ https://status.gitlab.com/ or if you prefer tweets, the updates are also posted to https://twitter.com/gitlabstatus https://twitter.com/gitlabstatus
A more general approach I use - search on Twitter for the project name. If many users say that something does not work, it usually is not a "me" problem. Another strategy is to use websites which do connectivity tests from different locations (example: https://tools.keycdn.com/ping https://tools.keycdn.com/ping). You can use SSL scanning sites for that matter too.
- capableweb 5y ago> You are using it already :) https://status.gitlab.com https://status.gitlab.com Any reason why "Google Compute Engine" is highlighted in red on that page? Other entries seems fine that are also using it, but not the one where the service is currently broken. Makes it seem like the problem is Google Compute Engine is at fault, when that's obviously not true.
- dnsmichi 5y agoThanks, I have forwarded your question. The current selection for the affected component automatically selects the `locations` entry. The `website` component selects the Google Compute Engine in this case. Agreed that this can be confusing, we'll have to check whether the status page interface allows for more fine granular selections.
- sm4rk0 5y agoCan someone update the main URL with the first one above?