# 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.