Skip to content
Products
/
/
/
Email error events
Last updated

Email Error Events Table

To help you monitor the success of your email campaigns and troubleshoot issues, Engage Studio automatically records various events related to your email tasks. While standard events like opens, clicks, and deliveries are captured in the "events" table, some critical errors can happen before an email is even successfully submitted to AWS SES within Engage Studio. This document explains the "error_events" table , a dedicated place where Engage Studio records these pre-email sending failure events.

The Error Events table is a specific table designed to record failure events for Engage tasks that occur before requests are successfully submitted to AWS SES within Engage Studio. The standard email event pipeline cannot capture errors that happen during internal processing like email rendering or queueing. This dedicated table ensures you have visibility into these types of failures.

What Types of Errors Are Recorded?

This table primarily stores two specific types of error events:

  1. Email Processing failures Error Events: These are "Runtime Errors" captured through a email processing associated with the immediate email processing queue.

  2. Rendering Error Events: These are "Rendering Errors" / "Validation Error" that happen during the process of generating the email content itself. (Note: "Rendering Failure" is reserved by AWS SES and is not used for these internal errors).

Where Can You Find This Data?

The error events are stored in your dedicated Treasure Data database.

  • The database is named delivery_email_{DOMAIN_NAME}.events, where {DOMAIN_NAME} is your specific email domain with certain symbols replaced by underscores.

  • Within this database, Email events are typically stored on the events table, while the failure events discussed here are specifically stored on the error_events table.

You are intended to be able to see these events.

What Information is Included in the Error Events Table?

The error_events table contains detailed information about each failed email task. The schema is designed to provide context for troubleshooting. Here are some key columns you will find in the error_events table:

  • timestamp (string): The time when the event happened. For email processing errors, this is the time the original request was made. For Rendering errors, this is the time the error occurred. This is in ISO8061 format with millisecond precision and a "Z" suffix for UTC (e.g., 2025-03-17T05:37:25.436Z).

  • time (bigint): The UNIX timestamp (in seconds) corresponding to the timestamp column.

  • email_domain (string) & email_domain_id (string UUID): Identifies the email domain associated with the task.

  • email_sender_id (string UUID): Identifies the specific sender used for the email.

  • email_template_id (string UUID): Identifies the specific email message or template used.

  • custom_event_id (string): Any custom ID you set in your email sending request.

  • to_plain_address (string): The recipient's email address in a simple format, even if a display name was originally included.

  • from (string): The sender's email address, potentially including a display name if set.

  • to (string): The recipient's email address, potentially including a display name if set.

  • subject (string): The subject line of the email.

  • error_type (string): Indicates the type of failure. This will be "Runtime Error" for email processing events or "Rendering Error" for rendering failures.

  • error_message (string): A textual description of the reason for the error in English.

  • error_timestamp (string): The timestamp when the email sending failed. For Rendering errors, this is usually the same as the timestamp column. This uses the same ISO8061 format as timestamp.

  • error_time (bigint): The UNIX timestamp (in seconds) corresponding to error_timestamp. For Rendering errors, this is usually the same as the time column.

How Are These Events Recorded?

The process for recording these events works automatically in the background. When a task fails before reaching AWS SES (either during rendering or queue processing), the failure event is captured by a dedicated system pipeline involving a Dead Letter Queue that eventually stream the data into the Error Events table in your database. Additional details like the specific error message and time are also captured and included in the data recorded in the table.

Previous page
Next page