Event Payloads and Context

Errova SDKs and direct clients use the same general event contract. You do not need every field on every event, but you should know which fields create useful triage signal and which ones create noise.

Common Event Types

• error: unexpected failures, exceptions, and broken code paths
• message: meaningful application messages such as state transitions or warnings
• log: structured operational logs when you want them searchable inside Errova

Fields Worth Setting on Most Events

• eventType, level, and message for the basic signal
• environment and release for filtering and deploy correlation
• platform and serverName when multiple runtimes or hosts are involved
• timestamp when the event time matters and should not default to transport time
• fingerprint only when you intentionally want to override grouping behavior

Context, Tags, and User

• Use context for structured debugging data such as IDs, feature flags, or request metadata.
• Use tags for low-cardinality filters such as service name, feature area, or region.
• Use user for affected-user triage. Set it after login and clear it on logout.
• Avoid high-cardinality tag values such as random IDs, timestamps, or full URLs with query strings.

Example Payload

{
  "eventType": "error",
  "level": "error",
  "message": "Checkout failed",
  "title": "Error: Checkout failed",
  "environment": "production",
  "release": "web@2026.03.31",
  "platform": "nextjs",
  "fingerprint": "checkout-timeout",
  "serverName": "web-1",
  "timestamp": "2026-03-31T12:00:00.000Z",
  "tags": {
    "service": "web",
    "feature": "checkout"
  },
  "user": {
    "id": "user_123",
    "email": "customer@example.com"
  },
  "context": {
    "cartId": "cart_42",
    "paymentProvider": "stripe"
  }
}

Grouping Guidance

• Use stable, consistent messages for the same failure class.
• Leave fingerprints alone unless the default grouping is clearly wrong for your use case.
• Prefer structured context over encoding details into the top-level message.