EU-hosted error tracking, and why residency matters
An error event is not just a stack trace. It carries the request URL, query parameters, user context and fragments of the payload that broke — which is exactly why the country your error tracker stores it in belongs in your GDPR story. This guide explains what to look for and how MOJAQ keeps errors in the EU.
EU-hosted in Helsinki · GDPR-native · free during the private beta
Why stack traces are sensitive
When something throws in production, a good error tracker captures the context you need to fix it: the URL and method, the breadcrumbs leading up to the failure, the authenticated user, and often the request body or arguments involved. That context is what makes error tracking useful — and it is also why the data is rarely anonymous. A trace tied to a user ID, an email in a query string or an internal endpoint path is personal and infrastructure data at once.
Treat error events with the same residency thinking you apply to your database. If your application data lives in the EU but your errors stream to a US-hosted service, you have quietly created a transfer for some of your most detailed request data. Keeping errors in the EU closes that gap.
What to look for in EU error tracking
| Requirement | Why it matters |
|---|---|
| EU storage, not just an EU toggle | Events at rest should stay in the EU, with backups in the EU too — not routed through non-EU regions. |
| A signed DPA | You need a data-processing agreement to name the tool as a processor in your own compliance docs. |
| Keep your existing SDK | A migration that forces a code rewrite is a migration most teams never finish. Drop-in compatibility matters. |
| Scrubbing controls | You should be able to strip or mask fields before they leave the app, via standard before-send hooks. |
| Context with the rest of your stack | Errors are most useful next to the deploy that shipped them and the uptime and logs around them. |
How MOJAQ does it
MOJAQ error tracking uses a Sentry-SDK-compatible DSN, so the migration is small: keep your current error-reporting client for Node, Python, Go, PHP, Ruby or .NET, and point its DSN at MOJAQ. You get stack traces, breadcrumbs, request and user context, smart grouping and release correlation — the parts of error tracking you actually work with day to day.
// keep your existing Sentry-compatible SDK, change only the DSN
Sentry.init({
dsn: "https://YOUR_KEY@INGEST_HOST/YOUR_PROJECT_ID", // copy the exact DSN from your dashboard
beforeSend(event) { /* strip fields you do not want stored */ return event; }
});The events land on dedicated infrastructure in Helsinki with a DPA included and no US transfers in the storage path. And because errors sit in the same account as your uptime checks, logs and deploy tracking, a spike lines up with the release behind it instead of living in a separate silo.
Get started
Create a free account, add an error-tracking project and copy its DSN. Point your existing SDK at it, ship a test error, and confirm the trace, breadcrumbs and grouping look right. Configure your before-send scrubbing for anything you do not want captured, wire your deploy markers so errors correlate with releases, and you have EU-hosted error tracking without a rewrite.
Questions
Are stack traces personal data under GDPR?
They can be. Error events routinely include request URLs, query parameters, user IDs and request context, which can constitute personal data. That is why where your error tracker stores events is part of your data-protection posture, not just an ops detail.
Does moving to EU error tracking mean rewriting my app?
Not with MOJAQ. It exposes a Sentry-SDK-compatible DSN, so you keep your existing error-reporting client and point the DSN at MOJAQ. Your instrumentation stays the same.
Where does MOJAQ store error data?
On dedicated infrastructure in Helsinki, Finland, with no US transfers in the storage path and a GDPR DPA included. Data-scrubbing choices such as not sending certain fields remain yours to configure in the SDK.
Can I control what gets sent?
Yes. Because you keep a standard error-reporting SDK, you use its before-send and scrubbing hooks to strip or mask fields you do not want captured before events ever leave your app.
Move your errors to the EU without changing your code
A Sentry-compatible DSN, EU storage in Helsinki, and errors beside uptime, logs and deploys. Free while we are in beta.
Request beta access →