I had a bunch of issues this evening, starting with any timer-based app failing, then slowly progressing into the whole system basically dying.
As of a few minutes ago it seems to have recovered in full. I had talked to support earlier this evening when I had the timer issue, and they confirmed it on their side and said it was a platform issue. So I would assume it is now fixed for everyone.
The one that was broken this afternoon is running fine tonight. 
Since my Sunset action failed, I had another three schedule based events that kicked in as expected. Waiting for my good night to kick in,40 mins to go.
Does anyone know if or when sunrise and sunset is going to execute locally from the hub for V2? Essentially , when will the scheduler be moved locally to the hub?
Yeah I had a bunch of motion sensor triggered lights not turning OFF, plus my outdoor lights didnāt turn on at sunset, so looks like some sort of timer function on the hub or in the cloud broke!
Never mind, just did it āmanuallyā in the app!
Just to add another data point to the mix, all my stuff stayed working throughout (and Iām not usually so luckyā¦ despite my screen name 
). FWIW, on v1 hub and 2.0.3 of the Android app.
my routines are not firing from hello home director (sunset / sunrise) also.
2 hours prior to this post - my wife arrived home and home day routine did not run
I spoke too soon. My wifeās SmartThings presence sensor (< 10ā from the hub) decided to leave for 1 minute and then came home again. 
This triggered the Iām Back! routine, which turned on lights because it was after sunset, Doh!
This is why I set it with a 3 minute delay. Never had any issues with a false routine fire due to a presence sensor temporarily believing it has popped to the shops
I had forgotten about that setting. It was set to 1.5 minutes; just bumped it to 2 minutes. 
I believe that my Goodbye! is set to 10 minutes, but I donāt have any locks or other vital things attached to the action. Also having much better luck with life360 presence detection on my nexus 5 than I did with the built in ST one!
Hereās what I see on my graph.api from last night. Sunset trigger never actually ran last night:
Scheduled Jobs
Handler Next Run Time Prev Run Time Status Schedule
sunset_triggerHandler **2015-10-22 6:18:00 PM EDT WAITING** Daily
Job History
Handler Scheduled Time Actual Time Delay (msec) Execution (msec)
sunset_triggerHandler 2015-10-21 6:20:01 PM EDT 2015-10-21 6:20:03.293 PM EDT 2158 1727
sunset_triggerHandler 2015-10-20 6:21:00 PM EDT 2015-10-20 6:21:00.365 PM EDT 8 4301
sunset_triggerHandler 2015-10-19 6:23:00 PM EDT 2015-10-19 6:23:00.405 PM EDT 2My timed events are running fine as of this morning. I hope the problems were only confined to yesterday, and that ST is addressing any root cause. I know there is a lot going on there right now, but Iād rather have a reliable system than multi user functionality coming back early, despite the hot mess that the users thread isā¦
Just learned of another time-based failure. My wife informed me this morning that the last two nights she was awakened by the EcoNet vent opening (itās pretty quiet, but sheās a light sleeper). It seems that SmartThingsā IFTTT integration is ignoring modes. I have IFTTT set to open the vent when temp drop below a set point (using Nest as a sensor)ā¦ but only when in Home or Away mode. Night mode is set between 10 pm and 5:30 am weekdays, and the IDE log confirmed the mode was set at 9:59:03 (9:59:04 the night before). Yet, the vent was triggered open by IFTTT at 2:07 am (2:48 am the night before).
I have opened a support ticket (#149221), but hope this doesnāt turn into a finger pointing match between ST and IF. I wonder how many of the other time-based failures reported here might also be related to modes?
No events scheduled with runIn or runOnce is firing for me today.
I observed the same major issue with the RunIn() function yesterday afternoon in my various SmartApps. I immediately started a ST Chat in which ST Support never answered after I stayed by the PC for 2 hours. I ended up emailing ST Support to inquire. THIS IS VERY FRUSTRATING to have this issue happen as my door locks depend on this function to lock after the door after it closes. I verified this bug in the simulator as the RunIn function would not call back the stated handler.
As of this morning, ST Support has not responded to my requests and they have not issued any operational issues on their status page. 
I have tried to stay online for over 2 hours with CHAT and NEVER got a response.
Me: Can you please help with this issue.
Me: I have noticed that one of my SmartAPPS that has been running perfectly for months, but now does not function tonight (It worked this morning as usual). It appears that when the SmartAPP submits a runIn( 5, unlockDoor ) the unLockDoor() routine never gets called back for the routine to lock the door. This also happens in there simulator when I tried to see what was going on.
Is there a problem with the ST cloud that has not been reported for the RunIn() scheduled jobs?
Me: I have checked the logs for the SmartAPP and everything is running as it should except for the submission of the runIn() routine not being honored. Please check operational status, as this is a critical function for my Home Security
Me: The routine to lock the door does not get called back after the runIn() function is sucessfully submited
Me: Anyone home? (Waited 30 mins)
SmartThings Support: Weāre sorry - all our agents are busy assisting other customers. You are visitor #5 in the queue. (Waited 30 mins)
SmartThings Support: Weāre sorry - all our agents are busy assisting other customers. You are visitor #5 in the queue. (Waited 30 mins)
SmartThings Support: Weāre sorry - all our agents are busy assisting other customers. You are visitor #5 in the queue. (Waited 30 mins)
SmartThings Support: Weāre sorry - all our agents are busy assisting other customers. You are visitor #5 in the queue. (Waited 30 mins)
Here is ST Response to my email: Note the āWarm Regardsā 
Hi Kurt,
This email is to notify you that we have created a support ticket for your request. Weāre very sorry but we may be a bit slower than usual getting back to you. We have a number of new and old users alike that have contacted us with questions. Between our new Hub, new mobile experience, and the tremendous excitement around what SmartThings is doing, we have a sizable backlog of requests. Our support team will do our best to get back to you as soon as possible but we humbly ask for your patience. If you have anything else youād like to tell us, you can reply to this email. Otherwise, weāll be in touch as soon as weāre able.
Warm regards,
The SmartThings Team
I also had a problem on Wed with the SmartLights SmartApp. In the past Iāve seen that once a time-based app stops working it never starts working again until you change the trigger time. My guess is the change causes the app to be reloaded in the SmartThings cloud scheduler, but just a a guess. In any event after making a small change to the trigger time it ran last nite.
Then there are home monitoring systems which donāt reach the same level
of reliability, just give you some peace of mind. Canary, for example.
Personally, I would put SmartThings into the second category. It will
give you some good information much of the time. At quite a low cost
with no monthly contract. Many people find that valuable.
This is my point of view as well. I view the system as something helpful to me but I would never put anything that had to work on it. So no door locks for fear of them unlocking at inappropriate times, same with garage door openers, nor would I put anything that could be very expensive if it malfunctioned like a thermostat that might try to cool my house to 60F if it got the command wrong.
So if time based events are failing and my presence events (location) also donāt work. What good is this thing?
I feel I need to explain my āLike 
ā of your post. I donāt like the situation, but am expressing empathy and glad you are sharing.
The canned excuse above is 
!
SmartThingsās Customers didnāt force them to release Hub V2 (early) and App V2 on the same date, and the ātremendous excitementā is also the product of SmartThingsās own āutopianā marketing campaigns. All of these could have been staggered in phases as conscientious and proactive risk management.
In other words, just factually, no malicious intentā¦ SmartThings: you deliberately created this customer service crisis, so own it, please.
Stop asking for āpatienceā from your Customers. Who buys a product or service for the pleasure of having their patience stretched? (Perhaps Comcast customersā¦ 
ā¦ or masochists.).
But, honestly, huge kudos to the SmartThings support team members for their warm approach and grace and professionalism under pressure. That is always appreciated (no sarcasm intended).
