System status
How we tell you when something is wrong, and what monitoring exists today.
What we monitor and report on
When incident reporting is in place, these are the components it will cover — they are the parts that can fail independently:
| Component | What it covers |
|---|---|
| School portals | Signing in and everything inside a school's portal. |
| API | The interface every screen reads and writes through. |
| Database | Primary record store, hosted in Western Europe. |
| File storage | Pupil photographs and school logos. |
| Transactional email | Invitations, password resets and notifications. |
| Payments | Subscription billing and checkout. |
| This website | Marketing pages, served separately from the product. |
The marketing site and the product run as separate services, so this page can be up while the product is down. Do not read this page loading as evidence the product is working.
How we classify and how fast we tell you
| Severity | What it means | First update |
|---|---|---|
| Major outage | Schools cannot sign in or use the product at all. | Within 30 minutes, then hourly until resolved. |
| Partial outage | A specific area is unavailable — for example attendance saves but marks do not. | Within 1 hour, then every 4 hours. |
| Degraded performance | Everything works but is slow, or a background job is delayed. | Within 4 hours, then daily. |
| Planned maintenance | Work we schedule, ideally outside the school day in your region. | At least 5 working days' notice. |
We will send an initial notice before we understand the cause. A slow, complete explanation is less useful to a school deciding whether to take a paper register than a fast, incomplete one.
What an update will tell you
- What is affected, in terms of what you cannot do right now.
- Who is affected — all schools, one region, or one campus.
- What to do meanwhile, if there is a workaround.
- When the next update will come.
After a major incident we publish a summary: what happened, what we got wrong, and what changes as a result. No individual is named.
Incidents that involve data
If an incident involves a personal data breach, it stops being a status matter and follows the notification process in the data processing agreement — notice to affected schools within 48 hours of us becoming aware, so the school can meet its own 72-hour regulatory deadline. That commitment holds whether or not this page exists.
Planned maintenance
The service is designed to be updated without downtime, and most releases need none. Where maintenance requires an interruption we give at least 5 working days’ notice and schedule it outside the school day in the affected region where we can. Schools spanning several time zones will always be an imperfect compromise.
Being told
Incident notices go to the administrative contacts on each school account by default. To add another address — an IT team, or a duty phone — email info@axurs.com.
What is coming
Automated uptime monitoring with a public history, and per-component status on this page. Until both exist, Classbell publishes no uptime figure and offers no contractual uptime guarantee — see the terms of service.