Public status page
/status. Public, no login. Needs module.statusPage.
Shows the monitors you have marked public, with their current health.
Why have one
Section titled “Why have one”So you can tell students and staff “yes, the Wi-Fi is down, we are on it” without fielding forty individual reports of the same outage.
The value is highest at exactly the moment your desk is busiest, which is during an outage.
Setting it up
Section titled “Setting it up”- Enable
module.statusPage. - Create monitors for the services your community cares about.
- Mark those monitors public on the Monitors page.
- Tell people the address.
Only public monitors appear. Everything else stays internal.
What to publish
Section titled “What to publish”Publish the things people ask about:
- Wi-Fi
- The intranet or learning platform
- Printing
- Email, if you run anything local
- The library system
Do not publish internal infrastructure. A monitor called DC01 or
10.0.4.19:8080 means nothing to a student and something useful to anybody
scanning your network.
Name public monitors in the words your community uses. “Wi-Fi”, not “Wireless controller HA pair”.
Telling people about it
Section titled “Telling people about it”A status page nobody knows about reduces nothing.
- Link it from the help centre.
- Put it on the ICT page of your intranet.
- Put the address in the automatic reply on your ICT mailbox during an outage.
- Mention it in the start-of-year ICT letter.
During a real outage
Section titled “During a real outage”The page reflects what your monitors see, which is not always the whole story. A monitor that is up while the service is unusable has a weak check; see the keyword assertion advice.
Worth knowing: if the outage is Plugboard itself, so is the status page. That is
the argument for an external uptime check on /api/health/ready as well. See
keeping an eye on it.
Branding
Section titled “Branding”Carries your branding, so it looks like your school rather than a third-party product.