You've got forty minutes until the bid portal closes, and Procore just spun its loading wheel for the third time. Your takeoff file is sitting at 60% uploaded, frozen. Before you call IT, reboot your laptop, or start typing a panicked email to the GC's assistant, there's a tool already built into Chrome that can help you figure out what's wrong — it's called net internals, and most estimators have never opened it.
Chrome's net internals tool lives at chrome://net-internals and gives you direct control over Chrome's DNS cache and network connections. It's not flashy. There's no dashboard, no charts, just a few plain buttons. But paired with Chrome's built-in DevTools, when your bid software won't load and the clock is running, it's the fastest way to figure out if the problem is your Wi-Fi, your DNS cache, or the software vendor's servers.
When Your Estimating Software Won't Load, Net Internals Is Your Diagnostic Tool
Most estimators troubleshoot connection issues the same way: refresh the page, restart the browser, restart the laptop, and if none of that works, call someone. That works maybe half the time. The other half, you're burning 20 minutes on guesses instead of 3 minutes on a diagnosis.
Chrome net internals gives you a fast reset instead of a guess, and Chrome's DevTools gives you the actual data. Both are built in, with no extension and no download. When STACK won't sync your takeoff or Struvia's upload bar stalls, this is where you find out why.
What Chrome Net Internals Actually Shows You
Current versions of Chrome have trimmed net internals down to a few tabs, and two matter on bid day: DNS and Sockets. The old Events tab, which used to show a live request log, is gone. Chrome now points you to chrome://net-export to record a log file instead, and for live request data you use DevTools (more on that below).
The DNS tab lets you look up how Chrome resolves a hostname and clear Chrome's host cache, the shortcut list Chrome uses so it doesn't have to look up a website's address from scratch every time. When this cache goes stale, Chrome tries to reach an old, sometimes dead server address instead of the current one.
The Sockets tab has two buttons: "Close idle sockets" and "Flush socket pools." If an upload connection died mid-transfer and Chrome keeps reusing a bad connection, flushing the socket pools forces it to open fresh ones.
DNS Errors vs. Server Errors: Why the Difference Matters on Bid Day
A DNS error is your problem, and a 5xx server error is theirs.
If Chrome fails with a DNS error (codes like DNS_PROBE_FINISHED_NXDOMAIN), that's fixable in under two minutes — clear the cache, reload, done. If DevTools shows the request completing with a 500 or 503 status code, the software's servers are the bottleneck, and no amount of local troubleshooting fixes that.
Which one you're looking at determines your next move. One is a 90-second fix; the other means you switch to a phone call, a backup device, or an email to the GC explaining a 15-minute delay. Chrome network diagnostics exist precisely to stop you from guessing between the two.
How to Flush DNS Cache in Chrome (Step-by-Step)
A stale DNS cache is the single most common cause of "this site can't be reached" errors on software that was working fine an hour ago. Your network changed — a new office Wi-Fi, a VPN connection, a router reboot — and Chrome is still holding onto the old address. Flushing DNS in Chrome fixes this in three steps.
Step 1: Open the DNS Tab
Type chrome://net-internals/#dns directly into your address bar. This drops you straight into the DNS tab of Chrome net internals, skipping the general landing page.
You'll see a hostname lookup box and a "Clear host cache" button. The button is the one you want.
Step 2: Clear the Host Cache
Click the "Clear host cache" button. That's it — one click.
This flushes DNS in Chrome specifically, wiping every cached domain lookup and forcing Chrome to ask for fresh server addresses the next time you load a page. It doesn't touch your Windows-level DNS cache, which is a separate system layer — more on that below.
Step 3: Confirm the Fix
Reload the estimating platform you were trying to reach. If the DNS cache was the culprit, the page should resolve within a few seconds.
If it still hangs, the problem isn't DNS — open DevTools and check for a server error code instead. Don't assume the fix worked just because you clicked the button; confirm it before you move on or tell your PM the issue's resolved.
Clear the Windows or Mac DNS Cache Too
If clearing Chrome's host cache doesn't fix it, open Command Prompt and run `ipconfig /flushdns` to clear the Windows-level cache too. On a Mac, run `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` in Terminal. Estimators on shared office networks run into this more than they'd expect, because IT-managed DNS settings sometimes override what Chrome thinks it's resolved.
Diagnosing Slow Uploads When Submitting Large Takeoff Files
This is the scenario most Chrome troubleshooting guides skip entirely, and it's the one that actually costs GCs bid submissions. A 40MB Revit export or a stacked PDF takeoff doesn't fail to load — it fails to *upload*, stalling at 70% with no error message, just a spinning progress bar that never finishes.
Every estimator knows the feeling: the takeoff software says "uploading" for ten minutes straight, and you have no idea if it's actually working or dead. You just sit there watching a progress bar like it owes you money.
That uncertainty is exactly what a couple of minutes in Chrome's diagnostics eliminates.
Reading DevTools for Timeouts and Stalled Uploads
Press F12 (Cmd+Option+I on a Mac) to open DevTools, click the Network tab, and start the upload again. You're looking for one of two patterns: a request that sits at "(pending)" indefinitely with no response, or a request that fails partway through with an error like net::ERR_CONNECTION_RESET.
A connection reset means the connection dropped mid-transfer — often due to an unstable Wi-Fi signal, a VPN interrupting the session, or a firewall throttling large file transfers. A request stuck at "(pending)" with no reset usually points to the server, not your machine.
If you see repeated connection attempts to the same address with no successful completion, that's your signal to stop retrying and switch approach — a wired connection instead of Wi-Fi, or a different browser tab without ten other things running in the background. If the vendor's support team asks for logs, record one at chrome://net-export and attach the file.
When the Problem Isn't Your Network — It's the Platform
Sometimes DevTools shows a clean, fast connection with no resets — and the upload still stalls. That's a server-side bottleneck, not a local one, and no amount of DNS flushing or cache clearing fixes it.
This distinction matters because every minute spent flushing caches on a server-side problem is a minute not spent on your backup plan.
If DevTools shows your connection is clean but the platform still won't accept the file, check the vendor's status page before assuming it's you. Most established construction software companies — Procore included — publish live status pages during major outages.
Chrome Net Internals vs. Basic Troubleshooting: When to Escalate to IT
Net internals is a five-minute diagnostic, not a universal fix. Knowing when to stop poking at it yourself and escalate is its own skill — one most estimating teams learn the hard way, usually during a live deadline.
Here's the time-cost framing that works: if you haven't identified a clear DNS or server error within 5 minutes of opening net internals, stop. Call IT or the software's support line immediately. Bid deadlines don't pause for troubleshooting, and every extra minute spent guessing is a minute you don't get back.
Picture a team losing 40 minutes on bid day because the estimator kept trying to fix it alone instead of calling support, only to learn it was an outage on the vendor's end that nobody on their side could have fixed. That's the exact scenario a 5-minute rule prevents.
The threshold works like this: DNS cache issues, obvious Wi-Fi drops, and single-device problems are fair game for self-troubleshooting. Anything involving a server error code, a platform-wide outage, or a problem that persists across multiple devices on your network needs an escalation call — not more time in net internals.
Building a Network Troubleshooting Checklist for Estimating Teams
The best fix for bid-day network chaos is preventing it before the deadline, not diagnosing it during. A five-minute network check before every major submission window catches most "can't connect" problems before they turn into final-hour panics.
Run this before every bid deadline, not just when something's already broken:
Confirm your internet connection speed with a quick speed test — anything under 10 Mbps upload is a red flag for large file submissions. Clear your Chrome DNS cache and Windows DNS cache preemptively if you've switched networks or used a VPN in the last 24 hours. Close unused browser tabs and background apps that compete for bandwidth during upload. Test-upload a small file to your bidding platform 30 minutes before deadline to confirm the connection is live, not just to load the page but to actually transfer data.
Keep IT's direct line and the software vendor's support number saved somewhere faster than a Google search — under deadline pressure, you don't want to be searching for a phone number while a timer counts down. And if your team submits from a shared office network, ask IT ahead of bid season whether DNS settings are centrally managed — that single conversation prevents a lot of the mystery errors that show up during crunch weeks.
If your estimating workflow depends on juggling PDFs, spreadsheets, and multiple browser tabs to assemble a bid, that complexity itself is part of the network risk — more open connections, more competing bandwidth, more points of failure. That's the problem Struvia was built to shrink: you upload the plan set once, and the takeoff, sub invitations, follow-up, and bid leveling all live in one place instead of a dozen tabs fighting for bandwidth an hour before the deadline. If you're weighing options, our roundup of construction takeoff software compares the main tools.
Frequently Asked Questions
What is chrome://net-internals and is it safe to use?
Chrome net internals is a built-in diagnostic page in Google Chrome with tools for DNS, sockets, proxy settings, and domain security policies. It's safe to use: its buttons only clear Chrome's own caches and connections, which Chrome rebuilds automatically, so nothing on your computer is permanently changed.
How do I flush DNS cache in Chrome specifically, not just Windows?
Type chrome://net-internals/#dns into your Chrome address bar, then click "Clear host cache." This flushes DNS in Chrome only — it doesn't touch the separate DNS cache Windows manages at the operating system level. If clearing Chrome's cache doesn't fix your connection issue, open Command Prompt and run `ipconfig /flushdns` to clear the Windows-level cache too.
Why does my construction software work on one browser but not Chrome?
This usually points to a Chrome-specific DNS cache issue or a corrupted browser profile rather than a problem with the software itself. Clear your DNS cache in Chrome first using the steps above; if the issue persists across a fresh Chrome profile or incognito window, the problem is more likely on the platform's server side.
How do I know if a slow upload is my internet or the software's servers?
Open DevTools (F12) and watch the Network tab while the upload is running. A request that fails with a connection reset again and again points to your local network; a request that sits at "(pending)" with no reset, especially when your connection otherwise tests fast, points to a server-side bottleneck on the vendor's end.
Should estimators troubleshoot Chrome network issues themselves or call IT right away?
Give yourself a firm 5-minute limit. If clearing the cache at chrome://net-internals/#dns doesn't fix it and DevTools doesn't point to a clear local problem, escalate to IT or the software vendor's support line immediately — bid deadlines don't leave room for extended solo troubleshooting.
Can a VPN cause DNS errors in Chrome when accessing construction software?
Yes. VPNs frequently route DNS requests through different servers than your regular connection, which can leave Chrome holding a cached address that no longer matches where your VPN is pointing you. If you've connected or disconnected a VPN recently and then hit a "can't reach this site" error, clear DNS cache in Chrome first before assuming it's a bigger problem.
Bid-day network failures are rarely about bad luck — they're about a stale DNS cache, a stalled socket, or a server hiccup that a 5-minute check in net internals could've caught before the deadline started closing in. Building that habit into your team's pre-bid routine costs almost nothing and saves the exact kind of hour you can't get back on submission day.
If bid day still means juggling PDFs, spreadsheets, and a dozen browser tabs, see how Struvia works: one plan upload covers takeoff, sub invitations, and bid leveling in one place. New accounts get 600 free credits with no card, so you can upload a plan set free or book a demo and see what bid day looks like with fewer moving parts.
*Reviewed by Baylor Jeppsen, Construction Estimating Expert and Founder of Struvia.*
