Error Monitoring

Capture, group, and analyze errors from connected telemetry sources.

How it works

Moneat turns error telemetry into issues your team can triage. When an error arrives, Moneat normalizes the payload, extracts exception and runtime context, generates a fingerprint, and stores the event history for analysis.

Error monitoring is source-neutral in the dashboard. Source-specific details only matter when you are configuring ingestion or troubleshooting a payload.

Ingestion sources

Sentry-compatible SDKs are currently the richest source for full exception events and client replay correlation. OpenTelemetry and Datadog-compatible telemetry still contribute error context to traces, logs, service health, and related issue workflows as supported by the incoming signal.

Sentry-compatible envelope endpoint

When you use a Sentry-compatible SDK, the SDK sends events to the envelope endpoint automatically:

POST /api/{projectId}/envelope/
Content-Type: application/x-sentry-envelope
X-Sentry-Auth: Sentry sentry_key=<public_key>,sentry_version=7

The endpoint supports gzip compression. Events are processed asynchronously and typically appear in the dashboard within seconds.

Event data

Error events can include:

• Exception details - Type, message, and stack trace
• Breadcrumbs - Trail of events leading up to the error
• Tags - Key-value pairs for filtering, such as environment and release
• User context - User ID, email, and IP address when provided
• Device/OS info - Platform, browser, and OS version
• Request data - URL, method, and request metadata for web applications
• Custom context - Additional fields attached by the source SDK or exporter

Error grouping

Automatic fingerprinting

For Sentry-compatible events, Moneat uses the main thrown exception's type and the innermost application frame's module or class plus function. A frame without an in_app flag is eligible; frames explicitly marked outside the application are used only when no eligible frame exists. When a module is present, filenames and line numbers do not affect grouping. Without a module, the function and filename provide a fallback; generic SourceFile and Unknown Source filenames are ignored. An exception without frames groups by its type.

For obfuscated Android builds, upload each build's ProGuard/R8 mapping before sending events. Moneat retraces the exception and frames before grouping, so different obfuscated names can resolve to the same issue across releases. Events received without their mapping retain their raw symbols.

Custom fingerprinting

Sentry-compatible SDKs can override default grouping with a custom fingerprint:

Sentry.captureException(error, {
  fingerprint: ["custom-group-key"],
});

To refine automatic grouping, include the exact {{ default }} placeholder:

Sentry.captureException(error, {
  fingerprint: ["{{ default }}", "checkout"],
});

Moneat replaces each placeholder with the automatic fingerprint components. A fingerprint containing only {{ default }} groups exactly like automatic grouping. Other values, including their whitespace and order, are used as supplied; a fingerprint without the placeholder overrides automatic grouping.

Existing issue history

The stable class-and-function grouping update applies when new events are ingested. Previously stored events retain their issue IDs, history, statuses, and comments; Moneat does not backfill or automatically merge them. A recurring error whose fingerprint changes starts a new issue after the update, while its older history remains accessible in the previous issue. New-issue alerts and release new-issue counts can therefore show a one-time new issue at this cut-over. Type-only fingerprints and custom fingerprints without {{ default }} retain their grouping when their inputs are unchanged.

Uploading a missing mapping later likewise does not regroup stored events. Upload mappings before ingestion to keep subsequent releases together.

Usage & rate limiting

Moneat meters ingestion by plan and billable usage rather than by source-specific event quotas. If an organization reaches a configured budget cap or ingestion limit, Moneat can reject or drop new events to protect the account.

Supported platforms

Any platform that can emit OpenTelemetry errors, Sentry-compatible envelopes, or compatible agent telemetry can contribute error context to Moneat.

For full exception capture through Sentry-compatible SDKs, popular platforms include JavaScript, TypeScript, Python, Java, Kotlin, Swift, Go, Ruby, PHP, .NET, Rust, Elixir, React, Vue, Angular, Next.js, Django, Flask, Spring, Android, iOS, React Native, Flutter, and Node.js.