Cheryl emailed me overnight to mention that GWIstat was reporting an incorrect status for LLO -- it was reporting "Not OK" (red) while LLO was actually observing (OK+Intent).

I investigated and found that this was due to additional bits that became active recently in the GDS-CALIB_STATE_BITMASK and are being (correctly) summarized by Chad Hanna's gstlal processes, which my gwistat_collector process polls.  When I wrote the gwistat_collector parsing code during ER7, I had assumed that only 9 bits of GDS-CALIB_STATE_BITMASK were going to be used.  Maddie announced upcoming changes to the h(t) calibration channels and expansion of the bitmask on August 24, but it didn't register with me that it would affect GWIstat.  Scanning the hoft frame files, I see that the extra bits were turned on starting on August 28 at both sites.

So, the GWIstat status display has been generally incorrect since August 28, but is fixed now.  I apologize for the confusion.

For reference, here's how I checked to see when the extra bits first appeared:
pshawhan@> hostname -f
ldas-pcdev1.ligo.caltech.edu
pshawhan@> cd /archive/frames/ER8/hoft/L1
pshawhan@> /home/pshawhan/hwinj/monitor/FrBitmaskTransitions -c L1:GDS-CALIB_STATE_VECTOR -m fe00 L-L1_HOFT_C00-1124[89]/*.gwf 
1124802560.000000  0x00000000  Data starts ( )
   *** *** ***                 Data gap from 1124833796 to 1124833820
1124833820.000000  0x00003e00  9 on, 10 on, 11 on, 12 on, 13 on
1125003264.000000  0x00003e00  Data ends ( 9 10 11 12 13 )