Meteor Error Tracking without the noise
Server throws, client crashes, failed method calls - all captured with Meteor-native context, grouped into real issues and routed to the team that can fix them.
Meteor-native context
Generic error trackers miss the Meteor parts
A Meteor error is not a plain HTTP 500. It is a method that threw, a publication that crashed, a DDP disconnect that ate a promise, or a client component that blew up trying to render subscription data. SkySignal was built to capture all of those with the framework context attached - the publication name, the method arguments, the user id, even the DDP session - so you can reproduce and fix without another round of questions.
Four pillars of error tracking
Every issue arrives triaged, grouped and enriched with the context you need to fix it.
Full stack traces with source maps
Minified client bundles become readable traces. Server stacks resolve all the way through Meteor internals so you see your code, not the framework.
User and session context
Every error carries the user id, session id, method or route in flight, browser, OS and Meteor version so you are never guessing at the repro.
Grouping and dedupe
Fingerprinting collapses thousands of identical traces into a single issue. Spot a regression the first time it shows up, not after the inbox fills up.
Alerts that notice trends
Get pinged on new issues, reopened regressions and sudden spikes in rate - routed to Slack, email or your on-call channel.
How it works
Server capture, client capture, one inbox
01
Server-side hooks
The agent taps into uncaughtException, unhandledRejection and Meteor method error paths to capture errors with live trace context.
02
Client-side capture with screenshots
A small browser SDK listens for window.onerror, unhandled promise rejections, React error boundaries and failed Meteor.callAsync invocations - and grabs a screenshot of the viewport so you see exactly what the user saw.
03
Group, enrich, route
Errors are fingerprinted, grouped and tagged with release and environment, then sent to Slack, email or your incident tool.
Method-specific error payloads
When a Meteor method throws, the captured event includes the method name, sanitized arguments, the user id and the DDP connection id. For Meteor.Error instances the error code and reason travel along, so client-side handling logic stays accurate.
Screenshot-on-error repro
The browser SDK captures a screenshot of the user's viewport the moment an error fires and attaches it to the issue. No more "works on my machine" - you see the exact UI state, modal, dropdown or half-loaded list the user was looking at when it broke. Sensitive selectors you flag are masked before upload.
Sensitive data stays out
Argument capture runs through a configurable scrubber so passwords, tokens and PII never leave the host. You choose the keys to redact and everything else is whitelisted.
Catch errors before users do
Free 14-day trial. Unlimited errors during evaluation.