A red line in the developer console: TypeError: Failed to fetch. If you build screens that call an API as an indie developer, you meet this message again and again.
The server should be up, yet the screen stays empty. You suspect the code, then the cache, and an hour disappears. The trouble with this error is that it rarely points at a single cause.
"Failed to fetch" is a catch-all. It is what a browser-based client says when the request never completed. Others are running into the same wording in Antigravity, too — there is a thread on the official forum (Failed to Fetch error in Antigravity).
A caveat first: I have not been able to reproduce that exact message in Antigravity myself, so I cannot tell you what causes it. What I can share is the order in which I check three places whenever I see this wording, and how to check each one.
The thing I most want to say: decide the order before touching settings
When an error appears, the urge is to open Settings and start changing things. But network failures often live somewhere other than settings.
Before fixing anything, find out whether the request can arrive at all. That is the line I draw.
My order:
- Can this machine reach the destination at all?
- If it can, has your sign-in expired?
- If it still fails, is a proxy or VPN sitting in between?
Place 1: can your machine reach the destination?
Start outside Antigravity, from a terminal. If this fails, the cause is not Antigravity.
# What this solves: separates "the network is down" from "only one destination fails"
curl -sS -o /dev/null -w "status=%{http_code} time=%{time_total}s\n" https://www.google.com
curl -sS -o /dev/null -w "status=%{http_code} time=%{time_total}s\n" https://discuss.ai.google.devIf you get status=200, your network can at least get out. Could not resolve host means name resolution (DNS) is failing; Operation timed out means traffic is stalling somewhere along the route.
Two destinations are used so that a one-sided failure reads as "this particular site is blocked."
| curl result | How to read it | Next step |
|---|---|---|
| Both return 200 | Your network can reach the outside | Go to place 2 (sign-in) |
| Could not resolve host | DNS failure | Switch Wi-Fi, review DNS settings |
| Operation timed out | Stalling along the route | Suspect VPN, corporate network, or router |
| Only one fails | A specific destination may be blocked | Go to place 3 (proxy) |
Place 2: has your sign-in expired?
If traffic gets through but the request still fails, look at your sign-in state next. An expired session can look like a failed fetch on the client even when the server answered.
I change no settings here. I sign out, then sign in again — nothing is lighter to try. If that fixes it, the cause was authentication. If not, move on.
Screen names and labels change between versions, so it is safer to remember the action ("disconnect and come back in") than a menu path.
Place 3: is a proxy or VPN in the middle?
On a company or school network, or behind a VPN, traffic passes through a proxy. The classic symptom: the browser works but one particular app fails.
# What this solves: check whether a proxy is configured through environment variables
env | grep -i proxy
# macOS: inspect the system proxy settings
scutil --proxy | head -20If nothing prints, there is no environment-variable proxy. If something does, try the destination through it with curl -x.
Antigravity is a VS Code–style editor, so I expect a proxy setting such as http.proxy in its settings. I have not built a proxy environment to confirm the exact name, though. Searching "proxy" in the settings screen and checking what actually appears is the safe route.
One table for reading the results
| Situation | Likely cause | What to do |
|---|---|---|
| curl fails | Network, DNS, or route | Leave Antigravity settings alone; fix the connection |
| curl works, re-sign-in fixes it | Expired authentication | Sign back in and watch |
| curl works, re-sign-in does not help | Proxy, VPN, or firewall | Check proxy values; retry with the VPN off |
| Everything checks out, error remains | Possibly a temporary problem on the service side | Wait, and look for matching reports on the forum |
The last row is, honestly, the state of having found nothing on your side. I have had the error clear after waiting, too. Having finished the checks is what lets you wait with a reason.
Your next step
Run the two curl lines above. That alone tells you whether the cause sits inside or outside Antigravity.
In my own indie development the message stayed the same while the cause kept changing. That is why I have settled on fixing the order, not the wording. I hope it saves someone standing in the same spot a little time.