Status page

Admin › Tickets › Status Page sets up a status page for your district: one place where families, students and staff see whether the products your schools rely on are working, before they call the help desk. Signed in to schoolOS, it's at /status, with your avatar and Back to schoolOS at the top. With Public page on, anyone can open it at your district's own address too, for example olympia.theschoolos.com/status, with your logo and colors. It shows nothing until you turn it on and add products here.

schoolOS staff select an Account at the top of this admin page first. The Now, Products, and Settings tabs then show that account's status page, including its outages and subscribers. Changes to products, incidents, outage responders, and spike detection save to the selected account. Staff can open that account's page from Settings when it has a vanity URL.

Once the page is on, staff see the district's status at a glance. While something isn't working, a banner runs across the top of every page of schoolOS, in the same orange as theschoolos.com: a small label says Degraded, Outage or Maintenance, and the banner names what's affected, such as Securly is down, Wi-Fi at Lincoln is having issues or PowerSchool is under maintenance, with a link to the status page. It sits above the navigation and the page rather than over them, so nothing is covered. There's no banner while everything is operational. Select × to close it; it stays closed for that message and comes back when the status changes. Staff see outages kept inside the helpdesk there too, before they're posted publicly.

The page shows:

• A large icon and one line at the top: All systems operational, Some systems are having problems, or Maintenance in progress.
• Right now: only what isn't working, with your team's notes and the vendor's. This includes problems your team posts about your own services, like the Wi-Fi at one school. When everything works, it isn't shown.
• Products: every product in two columns, under its category. Each shows a green check, or the word Degraded, Outage or Maintenance. A product with parts opens to list them.
• Past incidents: problems resolved in the last 30 days and how long each lasted, folded until opened.
• Get updates by email: anyone who can see the page can subscribe. Get updates at the top jumps there.

schoolOS administrators choose Account before managing a status page. Settings, products, incidents, and updates belong to that selected account. Switching accounts clears open forms; save your changes first. Account administrators continue working in their own account.

Turn it on#

1. Open Admin › Tickets › Status Page and choose the Products tab.
2. Select Add from the catalog, check the products your schools use, and select Add.
3. On the Settings tab, turn on Status page, decide on Public page, check the Title, and select Save.
4. Select Open the page to see it.

On the Settings tab, The page starts open. Outage responders, Spike detection and Subscribers start closed and show what they're set to, like On · 5 tickets in 20 minutes; select a section's name to open it. The page remembers what you left open.

The public page needs a vanity URL for your account. If you don't have one, ask your schoolOS contact to set one; the page still works at /status for people signed in.

Products#

Each product has up to two layers of status.

• Automatic: for products whose vendor publishes a status feed, schoolOS reads it every few minutes and shows what the vendor says, with the vendor's own words and a link to their status page.
• Your team's note: any product can take one (see Report a problem). When both exist, your team's note shows first and decides the product's status; the vendor's status shows underneath.

When the vendor's own status changes, the page follows the vendor, so a note can't keep a product Degraded after the vendor has moved on. Your team's note closes and moves to History. An open outage on the product takes the vendor's new status but stays open, because resolving it also solves its tickets and tells their requesters; when the vendor says it's fixed, the outage's owner is asked to resolve it. Either way, the note's History says "Securly's own status changed to Operational." Post a new update to set the product's status again.

Add from the catalog lists products K-12 districts use, with where each one publishes its status. schoolOS keeps it up to date. Search finds a product by its parts too: searching Schoology finds PowerSchool.

Parts#

Many vendors run several products under one status page: Securly has Filter, Classroom and Aware; PowerSchool has its SIS, Schoology and Naviance. In the catalog these are one product with parts. When you check one in Add from the catalog, pick the parts your schools use.

• Each part you pick shows its own status under the product, so a Classroom problem doesn't make it look like Filter is down.
• The product shows the worst of the parts you picked, and only those parts count.
• Pick no parts to show the product as one thing, the way its vendor reports it.

To change them later, select Parts (the list icon) on the product. A custom product with a feed can have parts too: Parts lists the services its status page names.

When a vendor moves its status page, schoolOS updates the catalog and every district's page follows. The name, category and icon you gave a product stay yours. A product schoolOS retires leaves the catalog but stays on pages that already have it.

Some products have no public status feed (IXL, Infinite Campus, Quizlet). They're in the catalog anyway: they show Operational until your team posts a note.

Microsoft 365, Teams and Intune publish their health only to each district's own Microsoft admin connection, which schoolOS doesn't read yet. Add them to post team notes.

Add custom adds a product that isn't in the catalog. Give it a name, company, category, website and status page. Find feed looks for a machine-readable feed behind the status page (Atlassian Statuspage, Instatus, Better Stack, Status.io, RSS or Atom). With no feed the product takes team notes only. Upload an icon, or leave it empty and one is copied from the website.

Use the arrows to change the order; the page groups products by category and keeps your order within each. Remove takes a product off the page; its past problems stay in History.

Which should I choose?#

| Option | What it does | Choose it when | | --- | --- | --- | | A catalog product with a feed | Status updates on its own; your team can add a note | The product is in the catalog (most are) | | A catalog product without a feed | Shows Operational until your team posts a note | The vendor publishes nothing schoolOS can read | | A custom product | Your own name, icon and feed | It isn't in the catalog, like a regional service |

Can't find a product in the catalog? Select Can't find a product? Request it at the bottom of Add from the catalog, and give its name and website. schoolOS finds its status page and adds it to the catalog for every district, usually without waiting for an app update. Until then, add it as a custom product.

Other names#

Every new ticket is checked for the products on your page it mentions, whatever its topic or department, so a burst of reports about one product shows up as a possible outage. schoolOS already knows each product's name, the names in its parentheses, its parts and the names people commonly use (Gmail for Google Workspace). Add the names your district uses with Other names (the @ icon) on a product: for PowerSchool, maybe PS, SIS and Power School. The dialog lists the names schoolOS already recognizes. A product's other names show under it in the list.

• Case and punctuation don't matter: Power School also finds "PowerSchool", "power-school" and "POWER SCHOOL".
• A name always stands as its own word: PS doesn't find "GPS".
• Names of three letters or fewer count only as you write them, so PS finds "PS" but not the "ps" at the end of an email.
• Topics used to pick the product their tickets were about. That's gone: each topic that picked one had its name added to the product's other names (and its tickets from the week before were counted), so nothing it caught is lost. Remove any you don't want.

Saving shows Undo. Other names need a one-time update to your schoolOS server; until it's done, the dialog says so and tickets are still matched by the names schoolOS knows.

Report a problem#

Select Report a problem at the top of the page, or Report a problem beside a product. Choose A product or A district system, how bad it is, where the work is, and say what's happening. For example: a product IXL, Degraded, Investigating, "Increased reports of IXL not loading", with the update "A message is in to their support. More here when there's news." From here it's on the public page by default.

Every problem is an outage, so tickets can join it and everyone on them hears each update and the fix together. See Outages.

• Your team can mark a product Degraded while the vendor still says Operational, because reports reach you first.
• Update beside a product opens its problem. Notes posted before problems became outages stay under Earlier notes from your team until you resolve them.

Outages#

The Now tab lists every open problem under Outages: what's affected, how bad, where the work is (Investigating, Identified or Monitoring), whether schoolAgent has a district message for it, where, and how many linked tickets are still open. Open one to change where the work is, write its district message, choose who follows it, post an update or resolve it. Agents usually report problems from tickets (see Outages on tickets).

• District message: what schoolAgent tells anyone who asks about the problem, in chat and in the first email reply to a new ticket about it, word for word. Without one, schoolAgent only says the team knows and is working on it. The website widget gives the district message even for a problem that isn't on the public page.
• When a vendor reports a problem, schoolOS opens an outage for it, marked Reported by its vendor, so you can link tickets and write a district message. It stays inside the helpdesk (the page already shows the vendor's words), its status follows the vendor's, and it resolves itself when the vendor says it's fixed and no tickets are open on it. Post an update or report a problem on the product to take it over.
• An outage about a product becomes that product's team note, so the page never shows two.
• Show on the public status page: on, the outage shows on the page with where the work is, and its subscribers get an email. Off, it stays inside the helpdesk and with the people affected. Turning it on needs Manage the status page.
• Resolve solves its open tickets and tells each requester (on by default), then moves the outage to History.

Outage responders#

On the Settings tab, Outage responders are the people told in the bell whenever an outage starts, whether your team reported it or a vendor did. They're added to follow it, so they hear every update after, and they're asked to write its district message. They also hear about every possible outage. Only people who can manage outages can be responders. Anyone else can be added to follow one outage from inside it.

Spike detection#

Outages are found by system, not by topic. Every new ticket, including one schoolAgent hands off from a chat, is checked for the products on your page it names, by name or one of its other names. When enough of them mention the same product at once, from any department and under any topic, your outage responders and the agents who can manage outages in those departments hear it in the bell: "Possible PowerSchool outage: 7 reports in 12 minutes". The minutes are from the first report to the latest.

Selecting it opens Report a problem for that product, with the reports ready to link and Show on the public status page on (for people who can manage the status page). When an outage for the product is already open, Link reports adds them to it instead, with Undo. When the product's vendor reports a problem too, the notice says so.

Within one department, a burst of tickets with the same topic or location, for problems that aren't on your page, gets a notice too: "7 Wi-Fi tickets in 20 minutes. Report a problem?"

On the Settings tab, Spike detection decides when:

| Setting | What it does | Default | | --- | --- | --- | | Detect spikes | On or off for the whole account | On | | Tickets | How many new tickets mentioning the same product (or, in one department, with the same topic or location) make a spike | 5 | | Within | In how many minutes | 20 |

Tickets already linked to an outage don't count. Each spike is announced once; a new one about the same thing is announced again after two hours, or as soon as the outage reported from the last one is resolved.

Who can see it#

People signed in to your account always see the page at /status. Public page decides whether anyone else can:

| Public page | What it does | Choose it when | | --- | --- | --- | | On (the default) | Anyone with your district's address can read it and subscribe | It's for families and the community | | Off | Visitors to the address sign in with their schoolOS sign-in first | It's for staff only |

With Public page off, schoolAgent's public website widget doesn't mention outages either.

Email updates#

Anyone who can see the page can subscribe to everything on it, or to the products they choose. They get one email with a link to confirm; nothing else is sent until they select it. Every email carries your district's logo and colors and an unsubscribe link. District system problems go to people subscribed to everything.

The Settings tab's Subscribers section shows how many people are subscribed and how many haven't confirmed yet, even while it's closed. Emails go out only while the page is on.

Who hears about changes#

• People whose role has View the status page settings see each status change in the notification bell, whether your team posted it or a vendor reported it.
• schoolAgent mentions a problem when someone asks about that product, using only what the page says. For example, asked "IXL won't load", it starts with "IXL is having problems right now, and the IT team is on it."
• schoolAgent also knows your open outages. When someone describes one, it says the helpdesk knows, gives the district message word for word, and offers to add them to the people affected instead of opening a separate request. The website widget mentions outages shown on the public page and any with a district message.
• Outage responders hear about every new outage; an outage's owner and the people following it hear each update.
• When a vendor says a product is fixed and an outage for it still has open tickets, its owner and the people following it are asked in the bell whether to resolve it.

Permissions#

View the status page settings opens this page to read it and brings status changes to the bell. Manage the status page changes it: products, notes and settings, and putting an outage on the public page. Declare and manage outages reports problems, links tickets to them, posts their updates, writes their district messages, chooses who follows them and resolves them; it's also what makes someone eligible to be an outage responder. Roles that manage helpdesk settings get all three; helpdesk staff get the first and the last. Change who has them in Admin › People › Roles.