Blackboard Downtime Schedule

There's never a good time to have a major service like Blackboard down for necessary maintenance. We try our best to juggle competing needs and pick times that minimize disruption for the entire UO community. Check this page for our official Blackboard downtime schedule. We update the schedule approximately quarterly, and attempt to list all scheduled downtime for the next six to twelve months.

Blackboard at UO is unavailable every Friday evening, 10pm - midnight, for system backup. The application servers are restarted every morning at 4:14 am, resulting in a very brief (typically under 5 minutes) service interruption at that time.

The Blackboard system also depends on various other systems that may themselves have scheduled downtime. For example, Information Services reserves 4 am - 7 am each Monday morning for network downtime. Although this downtime is rarely actually used, Blackboard would be unavailable whenever the network was down. Similarly, Information Services reserves Tuesday 6:30 am - 8 am for occasional shell.uoregon.edu and mail system downtime, which could delay mail delivery.

In addition to this daily and weekly downtime, we reserve one Saturday each month for preventive maintenance and upgrades, and usually schedule additional downtime during winter and spring breaks. If we need to actually use this reserved downtime, we will announce detailed plans as much in advance as possible on the Blackboard news blog. The date each month is chosen when possible to correspond to the Information Services system maintenance weekend.

2008 Calendar

Date	Note	Planned downtime schedule
Jan. 12, 2008	week 1 of winter term	reserved for emergency upgrades only -- not used in 2008
Feb. 9, 2008	middle of winter term	scheduled for database hardware upgrade; no major user-visible changes
Mar. 8, 2008	before last week of classes winter term	reserved for emergency upgrades only
Mar. 26-28, 2008 (Wed-Fri) [date tentative]	during spring break	Major upgrade: alternate date for database upgrades install Bb 7.3 service pack possible additional changes
Apr. 12, 2008	during spring term	reserved for emergency upgrades only
May 10, 2008	middle of spring term	tentatively scheduled; no user visible changes
June 14, 2008	after spring term final exams	reserved for emergency upgrades only
July 12, 2008	after week 3	tentatively scheduled; no user visible changes
Aug. 16, 2008	after 8 week term	major upgrade: upgrade to Blackboard 8.0 other major updates very likely
Sept. 13, 2008	during Sept exp'ce, Law fall	Tentatively scheduled, no major user visible changes. Possible 8.0 hotfix or service pack. Note: old 2004-05 coursesites removed during week of Sept. 8-13
Oct 11, 2008	early fall term	Tentative-emergency updates only
Nov. 8, 2008	middle of fall term	Tentative-emergency updates only
Dec 18-19, 2008 (Thu-Fri)	winter break, after Law fall finals	Tentative-Alternate date for Bb 8.0, possible Bb service pack or App Pack

2009 Calendar

Check back in September for the rest of 2009.

Date	Note	Planned downtime schedule
Jan. 10, 2009	early winter term	possible date for emergency upgrades only
Feb. 14, 2009	middle of winter term	tentatively scheduled; no major user-visible changes
Mar. 25-27, 2009 (Wed-Fri)	spring break	possible Bb Service Pack or App Pack upgrade. Minimal user visible changes.
	additional dates TBA

Planning for downtime

As we put together the downtime schedule, we consult with the Blackboard Advisory Committee, the staff in Information Services, and a wide variety of other interested parties. Some principles governing our plans include:

minimize overall downtime.
avoid downtime during peak usage periods, including the first week of the term, and last week of a term through the day grades are due.
avoid downtime during the busiest times of a typical week, which approximately include 10am-midnight Sun-Thur, 10am-5pm Fri, and 1pm-midnight Sat. Weekdays 8-10am and midnight-2am are moderate usage.
avoid user-visible functionality or interface changes during a term.
maintain the core blackboard system at near-current version. When major versions are released, we generally try to wait until the first patch release, but attempt to stay no more than 9 months behind current major version.
announce scheduled downtime as much in advance as possible, typically at least one full term and preferably 2 terms in advance.

Maintained by: JQ Johnson, jqj@uoregon.edu
Last Modified: 04/29/2008