The ONGOING_UPCOMING lifecycle in Alert model

22 views

Skip to first unread message

Peter Murphy

unread,

Jun 1, 2026, 9:05:45 AM (12 days ago) Jun 1

to MBTA Developers

Hello,

The documentation for the /alerts endpoint says this about the "lifecycle" in the alert payload:

/data/{index}/attributes/lifecycle
Enumerated, machine-readable description of /data/{index}/attributes/active_period

And in the Models > Alert section, there's another definition:

Identifies whether alert is a new or old, in effect or upcoming.

Value: "NEW" "ONGOING" "ONGOING_UPCOMING" "UPCOMING"

I have not yet seen an alert that has a lifecycle of ONGOING_UPCOMING, and I am wondering if this is a possible bug: I have seen alerts that are ONGOING with periodic active_period values, and the lifecycle remains ONGOING regardless of whether the alert is currently in an active_period or not at the time of the request. Should ONGOING alerts that are not currently "in effect" be distinguished as ONGOING_UPCOMING?

For example: https://api-v3.mbta.com/alerts/1001875 ("SL2 is detoured until further notice on weekdays from 6:00 PM until end of service. ..."). This always seems to have lifecycle == ONGOING, even when making the request on weekends when no active_period is in effect. https://api-v3.mbta.com/alerts/1001867 is another example ( "The bus stop at Massachusetts Ave @ Wendell St (outbound) has moved about 100 feet south, from 7:00 AM - 4:00 PM on weekdays only...") .

Thanks in advance,

Pete

Developer at MBTA

unread,

Jun 2, 2026, 10:37:14 AM (11 days ago) Jun 2

to MBTA Developers

Hi Pete,

You're correct, we're not outputting "ONGOING_UPCOMING", as was originally devised. We have it in our backlog to adjust the behavior of lifecycle , however we cannot provide an estimated date at this point. If you have a particular use case you want to share with us, please let us know, as we can take that into considering when doing ongoing prioritization.

Reply all

Reply to author

Forward

0 new messages