Dev.to WebDev 🛠 Dev 👁 1 📖 2 min read

Why we built Groundhog after hitting Dev Tunnels’ bandwidth limit

We built Groundhog after running out of Microsoft Dev Tunnels bandwidth in the middle of a working week. Before switching tools, though, it helps to check which limit you've actually hit: a 429 does not always mean the m

We built Groundhog after running out of Microsoft Dev Tunnels bandwidth in the middle of a working week. Before switching tools, though, it helps to check which limit you've actually hit: a 429 does not always mean the monthly bandwidth is gone.

First, separate the limits

Microsoft documents several limits, including:

  • 5 GB of bandwidth per user, with a monthly reset.
  • 10 tunnels per user.
  • 1,500 HTTP requests per minute per port.

Those need different responses. Slowing down a burst can help with request throttling. It cannot replenish a monthly bandwidth allocation.

If creating or hosting a tunnel fails

List your existing tunnels:

devtunnel list

Old tunnels can count toward the ten-tunnel limit even after you've stopped hosting them. In this hosting-429 report, a developer found that they already had ten tunnels and resolved the error by cleaning them up.

Delete only tunnels you no longer need. Deleting a tunnel can break callbacks registered against its address, so clearing everything is a poor first diagnostic step.

If the monthly bandwidth really is exhausted

Check polling, retry loops and repeated downloads to reduce unnecessary transfers in future. Creating another tunnel under the same account does not give you a fresh per-user allocation.

Can you buy more? In this March 2026 reply, Microsoft said it did not offer that option.

Why we built Groundhog

Disclosure: I build Groundhog. It's a free service for local HTTP apps, including WebSockets, with a named HTTPS address you can reuse. There's no monthly data or request cap, and the dashboard shows usage by day and by tunnel.

It still has limits: each workspace can start 6,000 requests per minute and have 200 in progress at once, alongside shared service limits. It's best effort. Those tradeoffs matter if you are deciding where to put a development workflow.

If you change providers, update webhook destinations and exact OAuth redirect URIs, then test a harmless request and a sign-in. Your old Dev Tunnels hostname doesn't move with you. If your workflow needs raw TCP or Microsoft's identity-based tunnel sharing, assess those requirements before switching.

The Dev Tunnels bandwidth troubleshooting guide explains the limits and tradeoffs of moving a local HTTP app.

This article was drafted by an AI agent using the product's published origin story and documentation, with the linked Microsoft documentation and issue replies checked during preparation.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.