Understood! I didn't know how much overlap there was between the two areas. I'll focus on the feedback for now, and will only update here with any final answers that could be helpful for posterity.

I must have expressed myself poorly then. My observation about the time zone was meant to raise a hypothesis for why the system delayed the alert for 5 hours and 4 minutes. But, it's clear that the alert was delayed. – The user reported an approximately 5 hour delay in the alert delivery from the observed event. – Our logs also reported the 5 hour delay. Recall that our logging output code is "Fall detected at (event.date) with status (event.resolution.rawValue) at (Date())". The resulting output prints the dates in UTC time, as shown in the fragments in my original post. The gap between the event.date value and the value returned by the Date() function (both printed in UTC) in this instance was 5 hours and 4 minutes. So to be crystal clear and to reiterate, we did see a 5 hour 4 minute delay for a user, and while the 4 minute component seems to be accounted for by this explanation, the 5 hour component remains a mystery.

I got followup from the submitted feedback, which I'm posting here: "Please know that our engineering team has determined that this issue behaves as intended based on the information provided. The API won't get notified until the first party flow and SOS resolution is complete. For example if an emergency call is placed, the API wont get notified until the call ends and emergency contacts have been notified (if setup). This could explain the 3-5 minute delay observed by the developer between the time of the fall and the API getting notified." While the feedback response explains the 3-5 minute delay, it does not explain the 5 hour delay we witnessed. I answered the feedback to emphasize that the core issue remains unaddressed, but the FB is already marked as "closed" so I don't expect any further action. Is there any way to get further guidance here?

I should add that the user was located in Central time which is -5 hours from UTC. Since the observed delay was 5 hours and 4 minutes, I wonder if there is an issue with time zones and message delivery to our app. If you remove the 5 hours component we end up with a 4-minute delay which is still not ideal but in line with what we've seen on those other events. Also, the watch was running watchOS 10.2. To be clear, though, the vast majority of our users are located in the continental U.S. and we haven’t seen similar multi-hour delays from their devices. I have updated the feedback with this information as well.

Thank YOU for being responsive to all of this! The team can feel free to send us either flowers or a lump of coal, depending on how they feel about getting these :) FB13788575 submitted.

Reporting back from the feedback so others can note, this appears to be fixed for an upcoming watchOS release. Thanks to the Watch system team to being attentive to this issue.

Confirmed, this appears to be fixed now. I appreciate the follow-up and follow-through. Definitely a step in the right direction for developer relations.

A note to anybody still following this: as of 2 days ago, Apple is now signing 17.3.1 again, making downgrading iPhones possible. This is a partially effective temporary fix for this issue. Unfortunately, I don't know if the IPSW for 10.3.1 is available for download and being signed, or how to go about applying it to a watch. 15 minutes of Googling wasn't helpful. Anybody have ideas?

Confirmed that this is still an issue on iOS 17.4.1, released today.

Thanks again for the quick followup. Feedback FB13692821 submitted with a sysdiagnose attached.

Thank you!!

We also want to know this. The new interface doesn't seem to be making the same logs available. This is especially problematic for watch apps and extensions which don't have robust 3rd party tooling options for crash reporting while in development.

It sure does! Xcode beta team take note: your built-in documentation needs to be updated!