Production error tracking
Production error tracking: collect, group and work through the exceptions your apps throw.
Uptime monitoring answers whether a service is reachable. Error tracking answers the far more uncomfortable question of what is going wrong inside a service that is reachable. A server can return 200 and still throw an exception for every tenth user — none of which shows up in an uptime chart. With the error tracking add-on your applications send error events straight to UptimeAlien, so alongside availability you also see the failures that actually hit your users — in one place, without running a second tool for it.
How it works
Your application reports errors with an HTTP POST to the ingest endpoint, authenticated with a project API key. An event carries a level (error, warning, info or fatal), the message, optionally a stack trace, plus tags and context of your choosing. Every event gets a fingerprint built from the service, the normalised message and the first stack frame. The overview collapses events sharing a fingerprint into one row with a counter — a thousand occurrences of the same error are one entry, not a thousand rows. One click on “Resolve” closes the entire group.
Your benefits
- Track errors from several apps and services in one place
- Identical errors collapse into one entry with a counter
- Sort by frequency and tackle the loudest errors first
- Ship stack traces with the error and read them right in the dashboard
- Separate open from resolved errors and see the progress
- Filter by service, environment or release using tags
- Uptime and errors in the same tool, without a second subscription
What you get
An overview of your errors, each with its occurrence count, last occurrence, level and message. The detail view adds the stack trace, tags, context and the list of individual occurrences.
Availability
Available as a paid add-on; included on plans with error monitoring. Not part of the free tier.
Why uptime monitoring alone isn't enough
An uptime check looks at your application from the outside, usually along a single path. It reliably tells you the homepage responds — but not that checkout has been failing with a null reference exception since the last deploy, that a background job is quietly dying, or that a third-party API call is timing out in batches. These failures happen inside an application that looks perfectly healthy from outside. Production error tracking closes that gap by letting the application report what is happening within it.
How errors get grouped
Without grouping, error tracking is just another log file — a warning firing every 30 seconds produces close to three thousand rows in a day and buries everything else. UptimeAlien therefore builds a fingerprint for every event from the service, the normalised message and the first stack frame, and collapses events sharing a fingerprint into a single row in the overview, with the occurrence count next to it. The list sorts by last occurrence or by frequency — so you prioritise by what is shouting loudest rather than by chance. One thing matters here: the collapsing happens at display time, not on receipt. Every individual occurrence is kept with its exact timestamp, tags and context, and stays visible in the detail view — so you lose none of the data, only the noise.
Connecting your application
Integration is deliberately a plain HTTP endpoint rather than an SDK you would have to maintain per language. You create an API key for your project in the dashboard and post a JSON object to the ingest endpoint from your application's exception handler. That works from any language or framework that can speak HTTP — Node, PHP, Python, Go, Rust, .NET, or a shell script in a cron job. Use the “service” tag to separate several applications within the same project.
Frequently asked questions
What is error tracking?
Error tracking software collects the errors and exceptions your running applications throw into one place, groups similar occurrences and shows which problems happen how often. Unlike uptime monitoring it isn't about reachability, but about the failures inside a reachable application.
Are identical errors grouped together?
Yes. Errors sharing a fingerprint — built from the service, the normalised message and the first stack frame — appear as one row with a counter instead of many identical entries. Resolving that row closes every open occurrence in the group at once. If the error happens again afterwards, the group reappears under “Open”, so a regression doesn't slip past.
How is error tracking different from exception tracking?
The terms are mostly used interchangeably. Exception tracking emphasises the exceptions thrown by the language runtime along with their stack trace, while error tracking is drawn a little wider and includes things like warnings and self-reported error states. UptimeAlien covers both through the same events: the level distinguishes error, warning, info and fatal.
How do I send errors from my app?
With an HTTP POST to the ingest endpoint, authenticated with a project API key. The body carries the level and message, plus optional stack trace, tags and context. No SDK is needed — any language that can make HTTP requests will do.
Are stack traces stored?
Yes. You can send a stack trace with every event; it is stored and shown with the error group in the dashboard. The stack trace is optional — events without one are accepted too.
Is error tracking included in the free tier?
No. Error monitoring is a paid add-on and is included on plans with error monitoring. If a project without that entitlement sends events, the ingest endpoint rejects them. Uptime monitoring itself stays free on the free tier.
Can I separate errors from several applications?
Yes. Either create one project per application, or use the “service” tag within a project to mark where an event came from and filter by it later.