IT Outages Communication Plan
This page outlines norms for communication to all staff by Library IT Managers during service outages.
What constitutes an outage that warrants a message being sent to staff?
An outage is defined here as a disruption that results in users' inability to use the service for its basic functions; this could also be planned maintenance work that may realistically result in such downtime
An outage that lasts 10 minutes or longer, from the point when the outage is known
When should a message be sent out?
Once the service has been down for 10 minutes
When relevant new information is available (example: progress is made or additional issues arise) after an outage has been announced, during that outage while the service is still unavailable
When the outage has been resolved
How should we send the message?
Post an update to the #incident_reports channel.
If appropriate, post an update to Slack in the #general channel for incidents with broad impact or in the relevant Slack channel for the service (the one most non-IT staff may check for updates, such as #dspace for Dataspace or OAR outages, #catalog for Library Catalog outages, or #digital_library for Figgy/DPUL outages).
If appropriate and the outage impacts a large number of Library staff and/or our users, send an email to PULUpdates@princeton.edu.
If appropriate and the outage impacts users other than Library staff, we can have it listed on the OIT Outages & Alerts page
Contact the OIT Service Desk in order to post an outage on the OIT outage site
Call 609-258-HELP (4357) M-F 8 am to 8 pm, Sa/Su 8 am to 4 pm. All times are Eastern.
Identify yourself as a Library IT staff member. Ask the agent to post an outage on the OIT Outages & Alerts page for the Library
If an outage is expected to take several hours or longer to resolve, consider adding a banner to the Library website, Catalog, or other sites users are likely to visit.
How should I gauge impact?
Time of year: during term, and particularly during finals (see the University academic calendar for Dean’s Date through Final Term Final Assessments), more faculty and students will be impacted
Time of day: most faculty, students, and staff will be impacted more during the Eastern time workday and evening
Scope of users: how many users are impacted by the outage?
Role of the application: how important is the application to the impacted users, and how central to the University’s teaching and research mission is the application?
Who should send the message?
One of the following IT Managers:
Stephanie Ayers
Esmé Cowles
Alicia Cozine
Kate Lynch
Trey Pendragon
Kevin Reiss
Whoever initiates contact with staff should be the point of contact (aka the Incident Communicator) throughout the outage.
If the Incident Communicator needs to step away from the situation before it is resolved, they should hand off communication to a designated backup person.
To claim Incident Communicator responsibility: once an incident is reported in the #incident_reports channel on Slack, one of the IT Managers (potentially including the one reporting the issue) should explicitly reply on Slack that they are taking responsibility for communication on this incident.
If someone is working to resolve the incident, they should not also be the Incident Communicator
What about planned outages/maintenance?
Outages that meet the above criteria (7 days a week, 8:00am and 6:00pm EST, expected to result in more than 10 minutes of downtime for a production service) should be communicated to staff within a reasonable timeframe on a case-by-case basis before the planned outage takes place.
Planned outages with a significant and/or extended user impact should be communicated to users in advance by email and/or banners on related or prominent websites (Library website home page, Catalog, Finding Aids, etc.). Coordinate with public services staff on the best way to reach impacted users.
See the Service Catalog Data for acceptable outage times/windows (work-in-progress)