Sentry-class error tracking, white-labeled for your own stack

Your website is up. Your uptime dashboard is green. Your users are still hitting a JavaScript error that freezes the checkout button on iPhones.

That's the gap between monitoring and error tracking — and it's the one your users notice first. A site that loads but crashes on interaction is more frustrating than a site that's briefly down.

Vergate Error Tracking closes that gap with something most small teams and agencies never get to use: Sentry-class error monitoring, white-labeled under your own name.

#What it does

Create an error-tracking site on a project and you get a one-line embed:

<script async defer src="https://api.vergate.dev/errors/tracker.js"
        data-site-token="vg-et-xxxxxxxx"></script>

This tracker captures JavaScript errors in the browser and sends them to a collection endpoint on the same host. In the dashboard you get:

• Grouped issues — identical errors are aggregated into one issue with a count, first-seen and last-seen timestamps, and a severity level. No 4,000 identical "TypeError: Cannot read properties of undefined" rows.
• Stack traces — file, function and line context for every captured error, with the browser and OS it happened on.
• Resolve workflow — mark issues resolved from the dashboard; new occurrences of a resolved issue surface as regressions.

It's built on an open-source, Sentry-compatible engine (GlitchTip) and speaks the Sentry v7 ingest protocol — battle-tested technology with decades of production hardening, exposed through a fully white-labeled surface.

#White-labeling done properly

This is the part that matters if you're an agency, a platform, or a freelancer shipping products under your own brand: the client never sees the vendor.

• The tracker script is served from api.vergate.dev/errors/tracker.js and carries no brand in its source.
• The collection endpoint is your Vergate host, not a third-party SaaS domain.
• The dashboard is Vergate's UI — no GlitchTip or Sentry logo.
• The embed code contains a site token, not a DSN with a vendor hostname.

A client who opens view-source, checks the network tab, or clicks through to the dashboard sees your stack. Which is exactly how reselling should feel: the product is indistinguishable from your own.

#Why error tracking belongs in every project

Uptime monitoring tells you the server responded. Performance checks tell you how fast. Error tracking tells you what actually breaks for real users — and that's frequently the thing neither of the first two catches.

A typical profile of errors Vergate Error Tracking will surface:

• A React hydration mismatch that crashes a client-side price calculator.
• A third-party widget throwing inside an embedded iframe.
• A ResizeObserver loop that pegs the main thread on one browser.
• A failed fetch to an API endpoint that only fails for users with a certain network config.

Each one is invisible to curl, invisible to uptime checks, and visible only when real browsers run your code. That's the data error tracking exists to collect.

#Plan limits

Unlimited events per site. Pause, resume, or delete a site any time — a churned client's tracker stops collecting the moment you pause it.

#Your stack, your name

Vergate's philosophy is consistent across every product line: you shouldn't have to choose between powerful tooling and your own brand. Analytics and error tracking are both white-labeled, both included with paid plans, and both live on your projects alongside security, performance, SEO and uptime.

Clients don't care what's under the hood. They care that the dashboard works, that the data is private, and that nothing on their site advertises a competitor. Spin up your first error-tracking site and see how quickly "do you have monitoring?" turns into "we have error tracking, too."