---
updatedAt: 2025-10-02T13:19:47.000Z
agentTools:
  projectIndex: https://developer.alloy.com/public/llms.txt
---

# Event Status & Lifecycles

When monitoring ongoing account activity, it's often important to track events at multiple statuses throughout the lifecycle of the activity that's occurring. For example, `login` Events might be monitored at the time when they're an *attempted* login, and then ultimately will move to *successful* if the user is able to log in, or*failed*. Transactions might be sent to Alloy when they're first *acknowledged*, and then again once they're *completed* for reconciling the data.

You can use Alloy's **Event Status** and **Event Lifecycle** features to track different ongoing Events more granularly and control what kind of monitoring is done, if any, at each point in the lifecycle for that Event.

# Event Status

The `event_status` field is an optional field you can include on your Event request to inform Alloy at what point in the lifecycle your Event is in. Each Event Type has a set of default enum values that Alloy allows for the Event Status out of the box. However, you can also add additional custom status values to support your specific use case as needed.

> 📘 Event Status vs. Other Status Fields
>
> Certain event types, including **Transaction** and **Login** events, have an underlying `status` field that's specific to that event type's schema. This field is **not** the same as `event_status` and must be mapped separately, even if you plan on using the same value for both fields.
>
> **Note**: If you don't specify an `event_status` in your payload, but you do include `status` for `transaction` or `login` event types, the `status` value will be referenced as the `event_status` value.

### Using Event Status to Control Entity Data Storage

In addition to mapping which Workflows will execute at Event Status level, you can also control whether the data submitted in that Event should be persisted to the Entity profile. This feature is most helpful for flows where you may *reject* the data submitted in the Event and thus need to control whether it's persisted in Alloy, in order to keep the Entity profile in sync across systems.

***

# Event Lifecycle ID

The `event_lifecycle_id` field is another optional field you can include to tie together multiple sub-Events across different `event_status` values together under a unified Event record. This allows you to orchestrate more complex end-to-end monitoring flows in Alloy across different statuses, all in the same ongoing Journey.

On Transaction and Login events, Alloy recommends passing in the same value to the `event_lifecycle_id` field that you pass in to `external_transaction_id` and `external_login_id` fields, and treating them as equivalent.