What is the login lockout duration

I was misreading my personal password hint for GitHub while attempting a push from the command line, but even after catching and fixing the issue, I got authentication errors. I tried logging into my account through the website but got the message “There have been several failed attempts to sign in from this account or IP address. Please wait a while and try again later.”, so I apparently exceeded the allowed number of failed logins (whatever that number is). My question is, how long is “a while” before I can login again? Is it a fixed length of time? Does it vary based on the number of failed login attempts or the number of times lockout has happened or something else? Clarification would be very helpful!

Note that a search for that error message in the forums returned 3 results, but none were useful. Most responses were along the lines of ‘contact help to resolve this.’ Is that always necessary, or do only the really problematic cases end up on the forums?

:wave: Welcome!

First, I do understand your frustration. Not getting a straight answer when you just want to get to work is annoying.

That said, it’s a combination of “It’s complicated” (because it is!) and also that lockouts of many different varieties are part of how we keep GitHub accounts safe from an ever evolving variety of attacks. Obfuscation and frequent change are important security measures.

In general, however, I can say it is designed to not be overly punitive on normal human error patterns like what you describe. It’ll stop you for a bit, but if you go off for a cup of tea and come back, you’ll probably be fine.

In some lockout cases, you will be able to get in by resetting your password. Obviously this can be a pain if you have your tokens and credentials stored for tasks and it may not be worth rolling your credentials to get in a few minutes faster.

If it lasts a long time (more than a couple hours for instance) and especially if you don’t know why you’re locked out, it might be worth contacting support privately, but in general that would happen when say, someone else is trying to log into your account repeatedly with the wrong password, or if someone at your IP address is up to no good.

I would expect you’re able to login again by now.

Thank you for the answer! I didn’t try again until ~5 hours later, partly because I wasn’t sure if continued attempts would extend the lockout (and also, I was asleep), but it worked when I did try. I understand the tradeoff between usability and security. I personally think that the duration for what is likely the simplest form of lockout could be given, since a sophisticated attacker could find it easily through trial-and-error, which leaves only regular users and unsophisticated attackers in the dark, but it isn’t my choice to make. :slight_smile:

On the other hand, I DO think it’s important for users to know - how many failed logins in a row will lock an account? This is generally information that is given to users, so that they know, for example, ‘I just botched my password twice. I have to be very careful this next time, or I’m going to get locked out for some time period.’

To the best of my knowledge, it’s not based on the number of failed logins in isolation of other factors. If you check your security log, you may be able to see how many failed logins you had today before your account locked.

If it’s not in your logs, you can open a ticket and ask. We’re more than happy to give you the details of your own account logs - but not in public :slight_smile:

Why there are too much text in the answers and not answering the question? Is it 5 min or 5 years ?? too easy to answer.


After around seven minutes of no progress using my computer to sign in, I decided to use my mobile phone to log in. That worked.

I then turned on “Mobile hotspot” on my phone and connected my computer to that wifi network, in order to get a different IP address. That worked too.

I then reconnected my computer to the regular corporate network, and I was still logged in to github. So back to work.

Some or all of these steps may not have been necessary. Perhaps the timeout period is ten minutes, or perhaps it is not. But at least I was up and running again in around ten minutes.