Below is a simple tile based on the highest level status of Smartthings from an API that is the basis for status.smartthings.com. The documentation can be found at http://mf6lzdpt63q3.statuspage.io/api/v2/#javascript-library
There is an extra variable - statusDescr - that is not necessary but was put in place for debugging. It can be removed and the value directly from the API can be used in the tile.
This would be great to set a global variable to see if Smartthings is up or down and used in conditions for piston execution.
Unfortunately pistons are saved and run entirely in the ST cloud, so if the cloud is down your tile won’t update and notification pistons won’t run 
Hell, if the ST cloud is down, you won’t even be able to load the WC dashboard as it needs to pull its data from ST.
True, I could add some assumptions based on the return code of the API call.
Maybe a little crude but a quick way to check status before jumping to conclusions about Webcore not working…
This tile has worked twice for me, including right now. 
Here is another example where I wish we could code something like ‘on click’ open a URL (open status.smartthings.com). Then we can go get the details.
I tend to agree with @Robin though…
I suspect the moment the ST server is down, your webCoRE dashboard will not load, so you will never see the tile change…
In other words, your piston will likely only work if the ST server is up and running.
One loophole might be to have the piston send a notification (or SMS) to you if the server was down. I noticed this last time around, all my pistons on a timer continued to run, even though I could not access my dashboard for seven hours.
While I can not argue with the logic of if ST server is down… the fact is, this tile is still useful in most situations, as now - where it is a battery reporting issue, not the main server.
Maybe but I don’t think so. The API seems to be hosted completely independent of the hosts for the actual production platforms. In my experience that is an Operations best practice.
Something changed recently and this status tile has stopped updating. Can anyone with a better handle on this web request stuff say why?
If I look at the api_URL in a browser, I see the status description “All Systems Operational” at the end (like this “status”:{“indicator”:“none”,“description”:“All Systems Operational”})) but statusDescr seems to be “not set”.
Just imported the original piston and it appears to be working for me. However this is not a piston that I regularly use.
Are you using the original piston? If not, can you post a green snapshot. Also logs would be helpful.
If you are interested in a more robust piston, I actually use this
It does not create a tile, but will provide alerts of outages and scheduled maintenace. Also updates piston state so you get a summary on your dashboard.
Currently:
I use a modified version but I, of course, fell back to this one to verify the issue. It’s definitely not working (for me) and always shows a thumbs down. here’s the full logging for the first pass (It should show Thumbs Up for All Systems Operational)
4/20/2021, 12:00:06 PM +663ms
+1ms ╔Received event [Home 109 2nd Ave].wc_async_reply = httpRequest with a delay of 0ms
+62ms ║RunTime Analysis CS > 27ms > PS > 9ms > PE > 25ms > CE
+64ms ║Runtime (41028 bytes) successfully initialized in 9ms (v0.3.113.20210203) (63ms)
+65ms ║╔Execution stage started
+76ms ║║null
+77ms ║║Executed virtual command log (1ms)
+83ms ║║Executed virtual command log (1ms)
+89ms ║║Executed virtual command setVariable (3ms)
+94ms ║║Executed virtual command log (1ms)
+102ms ║║Calculating (dynamic) == (dynamic) All Systems Operational >> (boolean) false
+110ms ║║Calculating (dynamic) == (dynamic) All Systems Operational >> (boolean) false
+116ms ║║Calculating (dynamic) == (dynamic) Major Service Outage >> (boolean) false
+142ms ║║Executed virtual command setTile (21ms)
+144ms ║╚Execution stage complete. (80ms)
+145ms ║Setting up scheduled job for Tue, Apr 20 2021 @ 1:00:00 PM EDT (in 3593s)
+154ms ╚Event processed successfully (154ms)
4/20/2021, 12:00:06 PM +442ms
+0ms ╔Received event [Home].time = 1618934400000 with a delay of 6442ms
+84ms ║RunTime Analysis CS > 64ms > PS > 7ms > PE > 12ms > CE
+86ms ║Runtime (41023 bytes) successfully initialized in 7ms (v0.3.113.20210203) (85ms)
+87ms ║╔Execution stage started
+95ms ║║Cancelling statement #29's schedules...
+102ms ║║Sending external web request to: mf6lzdpt63q3.statuspage.io/api/v2/summary.json
+123ms ║║Executed virtual command httpRequest (22ms)
+124ms ║║Requesting a wake up for Tue, Apr 20 2021 @ 12:00:30 PM EDT (in 24.0s)
+129ms ║╚Execution stage complete. (41ms)
+130ms ║Setting up scheduled job for Tue, Apr 20 2021 @ 12:00:30 PM EDT (in 23s), with 1 more job pending
+139ms ╚Event processed successfully (139ms)
4/20/2021, 11:10:12 AM +668ms
+1ms ╔Starting piston... (v0.3.113.20210203)
+491ms ║╔Subscribing to devices...
+664ms ║╚Finished subscribing (176ms)
+714ms ║Setting up scheduled job for Tue, Apr 20 2021 @ 12:00:00 PM EDT (in 2986s)
That said, I’ll take a look at the one you posted but there seems to be a number of pistons posted in that thread. The one you published I expect?
Thanks for commenting.
Definitely not setting the variable also odd that it isn’t even showing the log info data. I’m wondering if the issue is related to async httpRequests (new to the most recent version of webCore).
Try adding a log info line after the GET request to see what response you are getting
Also wondering if it could be a redirect issue as well, might be worth trying https://status.smartthings.com/api/v2/status.json as the endpoint.
Here is my log, the only difference is that I pulled all tasks out of the EVERY timer so I could execute via TEST and I am using a older version of webCore to avoid to web request issues.
4/21/2021, 8:40:48 AM +894ms
+1ms ╔Received event [Home].test = 1619008848894 with a delay of 0ms
+43ms ║RunTime Analysis CS > 19ms > PS > 11ms > PE > 13ms > CE
+46ms ║Runtime (42525 bytes) successfully initialized in 11ms (v0.3.110.20191009) (43ms)
+47ms ║╔Execution stage started
+51ms ║║Cancelling statement #29's schedules...
+59ms ║║Sending external web request to: mf6lzdpt63q3.statuspage.io/api/v2/summary.json
+344ms ║║Executed virtual command httpRequest (285ms)
+351ms ║║[description:All Systems Operational, indicator:none]
+352ms ║║Executed virtual command log (1ms)
+357ms ║║All Systems Operational
+359ms ║║Executed virtual command log (1ms)
+364ms ║║Executed virtual command setVariable (3ms)
+369ms ║║All Systems Operational
+370ms ║║Executed virtual command log (1ms)
+379ms ║║Calculating (dynamic) All Systems Operational == (dynamic) All Systems Operational >> (boolean) true
+388ms ║║Calculating (dynamic) All Systems Operational == (dynamic) All Systems Operational >> (boolean) true
+400ms ║║Executed virtual command setTile (8ms)
+447ms ║╚Execution stage complete. (401ms)
+451ms ║Setting up scheduled job for Wed, Apr 21 2021 @ 9:00:00 AM EDT (in 1150.656s)
+462ms ╚Event processed successfully (462ms)
I rolled back to the previous version as it was causing probelms with several of my pistons, including the status piston I posted above. (That is my most recent version, not sure if I made any modification since I posted in that thread.)
If you are interested, lots of discussion on the issue here:
The problem definitely started recently so may be related to the change. It was working fine for years but stopped within the last week or two.
As soon as I saw the different URL, I tried changing to the one you used but with no change.
I’ll take a look at logging the httpStatusCode and see what’s returned but I’m guessing that the older version of Webcore would explain why it works for you. Your piston, posted at the top of the thread you directed me to, seems to be working fine so I can just work with that.
Thanks again for your time.