Worth mentioning that both 
uchiwa.monitoring.rdoproject.org and
status.rdoproject.org are not HTTPS (yet).
Because of this, if you've ever visited 
https://trunk.rdoproject.org,
trunk.rdoproject.org provides a HSTS [1] configuration (persistent SSL
configuration for the 
rdoproject.org domain), your browser will
redirect status.rdo and uchiwa.monitoring.rdo to https and this will
not work.
You can either clear your HSTS configuration for 
rdoproject.org in
your browser or use another browser to look at the interfaces for the
time being.
I've opened an issue to make the 
trunk.rdoproject.org HSTS config
scoped correctly [2].
[1]: 
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
[2]: 
https://github.com/rdo-infra/puppet-dlrn/issues/40
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Tue, Jul 26, 2016 at 8:57 AM, David Moreau Simard <dms(a)redhat.com> wrote:
 Hello,
 We've discussed several times that we need a public place to
 centralize relevant status information for the community in an
 user-friendly way.
 The status information we have right now are available either from the
 dashboard [1] or the monitoring [2].
 Ultimately, the dashboard is monitoring things that is either already
 monitored by our Sensu instance or could be.
 I'm working on 
status.rdoproject.org [3] right now (not yet fed with live data).
 The software for it, Cachet [4], is an open source version of statuspage.io.
 It's meant to be driven automatically through it's API but there is
 also an administrative interface to manually create/edit/resolve
 events if need be.
 So, for example, if Sensu detects a problem, it coud create an event
 on status.rdoproject -- and resolve it when it's resolved.
 The existing scripts for dashboards could be adapted to work with
 status.rdoproject.
 We could even have jenkins jobs post updates on status.rdoproject if we wanted.
 It also supports displaying basic metrics, like shown in the demo [5].
 There will clearly be an overlap between status.rdo and
 dashboards.rdo. Are we okay with this ?
 I'm not looking to create yet another standard to rule them all (cue
 XKCD) but to use the right tool for the right job.
 Thoughts ?
 [1]: 
https://dashboards.rdoproject.org/rdo-dev
 [2]: 
http://uchiwa.monitoring.rdoproject.org/ (creds: rdo/rdo)
 [3]: 
http://status.rdoproject.org/
 [4]: 
https://cachethq.io/
 [5]: 
https://demo.cachethq.io/
 David Moreau Simard
 Senior Software Engineer | Openstack RDO
 dmsimard = [irc, github, twitter]