The State Machine Safety is guaranteed by a restriction on the election process. This rule is ensured by a simple restriction: a candidate can't win an election unless its log contains all committed entries. In order to be elected, a candidate has to contact a majority of the cluster, and given the rules for logs to be committed, it means that every committed entry is going to be present on at least one of the servers the candidates contact. Raft determines which of two logs (carried by two distinct servers) is more up-to-date by comparing the index term of the last entries in the logs. If the logs have a last entry with different terms, then the log with the later term is more up-to-date. If the logs end with the same term, then whichever log is longer is more up-to-date. In Raft, the request from a candidate to a voter includes information about the candidate's log. If its own log is more up-to-date than the candidate's log, the voter denies its vote to the candidate. This implementation ensures the State Machine Safety rule. If a follower crashes, "AppendEntries" and "vote" requests sent by other servers will fail. Such failures are handled by the servers trying indefinitely to reach the downed follower. If the follower restarts, the pending requests will complete. If the request has already been taken into account before the failure, the restarted follower will just ignore it. Timing is critical in Raft to elect and maintain a steady leader over time, in order to have a perfect availability of the cluster. Stability is ensured by respecting the "timing requirement" of the algorithm :"broadcastTime « electionTimeout « MTBF" Typical number for these values can be 0.5ms to 20ms for "broadcastTime", which implies that the programmer sets the "electionTimeout" somewhere between 10ms and 500ms. It can take several weeks or months between single server failures, which means the values are all right for a stable cluster to work.