Your problem is that you're relying on a method of communication that was never guaranteed to be instantaneous. Maybe you should investigate other forms of communication within your team besides (or in conjunction) with email.
Exactly what I was thinking. SMTP is generally store and forward. Your message gets thrown in a bin and the MTA gets to it when it can. I can't find anything in the actual SMTP RFC [1] indicating that there are limits to how long an email can stay in queue.
Google processes a lot of email. The primary constraint limiting how long their MTA backlogs can be is customer satisfaction. Most SMTP servers I've worked on are happy to retry for 72 hours or more.
I try to treat email as any other letter I recieve(1). Meaning that the sender can only expect an instant reply if I know beforehand the mail is coming and urgent.
The same way one would rapidly reply to an urgent letter one is expecting, but easily take a day or more to reply to, or even open, a non urgent letter.
If you need to get a hold of someone directly you should use your phone (to call them).
If they don't pick up their phone, leave a voicemail or send an sms.
(1) Registration confirmations / new password emails are an obvious exception here.
Exactly my thoughts. Not to down play the problem because it definitely is one Google should at very least address but even if Gmail was up 100% of the time with no problems there should always be communication redundancy. Instant messaging, file hosting services, other email providers.
Doesn't change the fact that this preferred form of communication by no means guarantees delivery in a certain timeframe. It's not a google problem. The email can be "stuck" in every place between you and the recipients mailbox.
to highlight this, I can think of an emails that got delivered YEARS after I hit send. This happened once in almost 20 years of emailing, yet in still happened. This probably occurred about 6 years ago.