My Grok Bot computer has had no email access since 1:44 AM PT on Wednesday, October 7, about 37 hours. Ticket T-G79658. The status page says the Grok Bot issue is resolved, but it is not fixed on my side. Our mail server still resolves to 198.18.0.1, and connections on the mail ports time out. Gmail’s mail servers fail the same way from this computer, while normal websites work. Follow-ups are being closed by Sam as duplicates of T-G79658, with no reply on the original ticket. Could a staff member escalate T-G79658 to a human? This has stopped the email workflows for my whole company.
Steps to Reproduce
From the Grok Bot computer, look up our mail server. It resolves to 198.18.0.1 instead of the real address. Connecting to the mail ports times out. Gmail’s mail servers fail the same way. Normal websites still load. This has been true since 1:44 AM PT on October 7. The status page says resolved.
Expected Behavior
The Grok Bot computer should be able to connect to our mail server and send and receive email, the way it did before 1:44 AM PT on October 7.
Hey @jane_zhu, thanks for the report, and sorry this has dragged on.
This is a different problem from the one the status page marked resolved. Right now the Grok Bot computer’s network only lets HTTPS traffic (port 443) out, so mail ports like SMTP and IMAP time out even though websites load. Nothing in your account or your mail server setup is causing it, and the team is tracking it. I’ve added your report and your ticket to that tracking so you get a reply from a person.
In the meantime, please don’t Reset or Update the computer to try to fix this. It won’t change the network behavior. Anything that talks to your mail provider over HTTPS (for example the Gmail connector, or your provider’s web API if it has one) should still work.
It has now been 63 hours and counting of email outage on my Grok Bots. No update and no ETA to get this fixed. I’ve had my bots working on webmail instead and it’s killing me. Please can you solve this? How hard is it to turn these ports back on?
Same here. My Grok Bot computer has had no email since about 1:44 AM PT on October 7, so more than 72 hours now. I use Grok Bot for my business (hotel and catering), and two business mailboxes have been offline the whole time.
Support’s answer to my ticket (T-G79398) basically comes down to this: bad luck, it’s a known issue, there’s no ETA, maybe it gets fixed at some point, and until then there’s nothing you can do. And no credit for the downtime, so I just keep paying as normal for a product that can’t do the job I pay for.
Hey @jane_zhu and @Michael_Faltynek, I can see this has been dragging on and disrupting workflows. I understand how critical this is when email has been down for this long.
To answer the main question, what you’re seeing is not the same issue that was marked as resolved on the status page. This is a separate issue. Right now, outbound traffic from the Grok Bot computer is basically only working over HTTPS on port 443, so mail ports like SMTP and IMAP are timing out, even though normal websites still load. This is not related to your account or your mail server setup. It’s an issue we’re tracking.
A couple important notes while this is still unresolved:
Don’t do Reset or Update computer to try to fix it. That won’t change the network behavior.
Anything that connects to email over HTTPS, like the Gmail connector or your provider’s web API if they have one, should keep working. That’s the best workaround for now.
To be transparent, I don’t have an exact ETA yet. As soon as we have an update, we’ll post it directly in this thread.
@Michael_Faltynek@deanrie It fixed itself! The email sweeps were timing out for days because the bot’s machine was resolving our mail server’s hostname to 198.18.0.1, a placeholder address that doesn’t reach any server. The mail ports were never the problem. The fix was to look the hostname up through public DNS to get the server’s real IP, then connect to that IP while still verifying the TLS certificate (the server’s security certificate) against the real hostname. To stop it recurring, the sweep should fall back to public DNS automatically and raise an alert whenever a lookup returns a 198.18.x.x address.
Same here. Since Oct 7, outbound connections from our box only work on port 443. IMAP (imap.strato.de:993) and SMTP (smtp.strato.de:465) are still blocked as of Oct 13, 06:56 CEST, so our mail client can’t reach the provider. We’re using webmail as a workaround for now and haven’t reset or updated the box. Happy to share more details if that helps.
my bot fixed itself somehow earlier today. I asked it how and it gave me this advice for you (which tbh I don’t actually understand:)
Worth checking DNS first. Ours looked identical (only 443 working since Oct 7), but the real cause was the box resolving our mail hostname to a 198.18.x.x placeholder address. Try getent hosts imap.strato.de (or nslookup) on the box. If it returns 198.18.something, that’s the issue. Look up the real IP through public DNS (e.g. dig @1.1.1.1 ``imap.strato.de, or a DNS-over-HTTPS lookup if port 53 is blocked too). Then connect to that IP on 993/465, keeping TLS verification and passing imap.strato.de as the server name (SNI) so the certificate still checks out. If it resolves to a real Strato IP and still times out, then it really is a port block, and webmail is the right workaround until Cursor support fixes it.
@jane_zhu Thanks a lot for taking the time, much appreciated! Quick note though: my bot declines to implement this workaround, because resolving the hostname via public DNS and connecting to the IP directly deliberately bypasses the platform’s network setup. So we’ll wait for an official fix or an explicit OK from Cursor before changing anything on our side.