A visitor on Safari hits a TypeError on your signup form. The button does nothing, they leave, and you have no idea it happened because you never installed Sentry. At $26/month for the team plan, it always felt like the wrong tool to add before you had a single paying customer.
OperatorStack's script tag already listens for uncaught exceptions and unhandled promise rejections on your page. Errors are deduplicated, PII-scrubbed, and tagged by source before they land in a triage dashboard where you can mark them active, ignored, or fixed. No separate install, no per-seat pricing.
How error capture works
If you already added the OperatorStack script tag for analytics, a waitlist, or forms, error tracking is already running. There is nothing extra to install.
Two listeners attach automatically. window.addEventListener("error", ...) catches uncaught exceptions with their message, source file, line, and column. window.addEventListener("unhandledrejection", ...) catches promise rejections that never got a .catch(). Both fire before your own code can react, so nothing slips through.
Errors that happen before the script finishes loading aren't lost. An early listener buffers up to 10 errors (message, source, line, column, stack) the instant the page starts executing, before OperatorStack's config has even loaded. Once config resolves, the buffer drains into full error capture, so a crash in the first 100ms of page load still shows up.
Every error is fingerprinted for dedup. OperatorStack hashes the message, source file, and line number into a short fingerprint. Repeats of the same fingerprint within a 5-second window get dropped, and total captures are capped at 50 per rolling 60-second window. A broken setInterval throwing the same error 1,000 times a minute cannot flood your dashboard.
Stack traces and messages are scrubbed before they leave the browser. Email addresses become [EMAIL], JWT-shaped tokens become [TOKEN], and any token=, key=, secret=, password=, or auth= query parameter becomes [REDACTED]. Stack traces are also truncated to 2,000 characters.
Reading the dashboard
Every captured error shows up under the project's Errors tab, tagged error_source: site or error_source: operatorstack depending on whether the stack trace points into your own code or into os.js. That split matters: a bug in your landing page's JavaScript should never get mistaken for a platform issue, and vice versa.
From there you can filter by status (active, ignored, fixed, regressed) and sort by count, recent, or first_seen. Sorting by count first is the fastest way to find the one error hitting 40% of your visitors versus the one that fired once on a bot's user agent string.
Mark noisy but harmless errors (a third-party ad script throwing on an ad blocker, for example) as ignored. They stay out of your active count without deleting the history, and if the same fingerprint reappears after a deploy, OperatorStack flags it regressed instead of silently re-opening it as new.
What you lose versus Sentry
Be honest about the tradeoff before you cut Sentry entirely.
OperatorStack does not unminify stack traces with source maps, does not track deploys/releases to correlate an error spike with a specific commit, and has no Slack/PagerDuty alerting yet. If you are shipping multiple releases a day with a team, Sentry's release tooling still earns its price. For a pre-launch solo founder watching one or two deploys a week, the built-in tracking covers what actually matters: knowing an error exists, how often it fires, and whether it is your bug or a third-party script's.
Testing it end to end
Confirm capture is working before you trust it. Open your browser console on a page running the OperatorStack script tag and run:
throw new Error("test-error-tracking");
Refresh the Errors tab in your OperatorStack dashboard a few seconds later. You should see test-error-tracking listed with error_source: site, a fingerprint, and a first-seen timestamp. Mark it fixed once you have confirmed it, so it does not skew your active error count.
Frequently Asked Questions
Does OperatorStack replace Sentry completely?
For a solo founder's pre-launch site, yes. You get automatic capture of uncaught exceptions and unhandled promise rejections, deduplication, and a triage dashboard. Sentry's release tracking, source map unminifying, and team alerting are built for larger engineering teams shipping multiple times a day.
Do I need to add any code to start tracking errors?
No. The moment the OperatorStack script tag loads, it attaches a window error listener and an unhandledrejection listener. Every uncaught exception or rejected promise on the page gets captured automatically.
Will this track errors from other scripts on my page, or just OperatorStack's own code?
Both, and the dashboard tells them apart. Each captured error is tagged error_source: site or error_source: operatorstack based on whether the stack trace points into os.js, so a bug in your own code never gets misread as a platform issue.
What happens if my page throws the same error 200 times in a minute?
It gets deduplicated. OperatorStack fingerprints each error from its message, source file, and line number, then suppresses repeats of the same fingerprint for 5 seconds and caps total captures at 50 per rolling 60-second window, so a broken loop cannot flood your dashboard or your event quota.
Does error tracking send any personal data?
No. Before an error is sent, OperatorStack strips email addresses, JWT-style tokens, and any token/key/secret/password/auth query parameter from the message and stack trace, replacing them with placeholders like EMAIL and REDACTED.