Trust and procurement
Uptime on a self-hosted deployment is mostly determined by the server you run it on, so a vendor percentage would be meaningless. This page states what monitoring ships - a health endpoint, an operations dashboard, job heartbeats and alert evaluation - which scheduled jobs install automatically and which do not, and what a school still has to arrange.
A useful trust answer explains controls, responsibilities, and boundaries plainly.
At a glance
What the product gives you for monitoring and scheduled jobs, which of those jobs you must wire up yourself, and why there is no uptime figure on this page.
Use the linked product and documentation pages to validate the workflow against your school’s data, roles, policies, and deployment.
Read the supporting materialHow it works
A clear sequence makes ownership, exceptions, and the next system action visible.
The application runs on your server. Its availability is mostly a function of that host, its provider, and whoever maintains it. That is why this page describes monitoring rather than promising a percentage.
Examination jobs install with a timer automatically. The daily school operations job - autopay, fee dunning, homework reminders, notices, admissions expiry, retention, alert evaluation - does not. Somebody must schedule it, and until they do, those things quietly do not happen.
Alert evaluation runs as part of that same daily job and writes alerts into the product. Delivery outside the product needs a webhook URL configured. Without both, nobody is notified when a job stops running.
Fee due dates, admissions deadlines, exam release, and year rollover are when a missed job hurts most. Check the operations dashboard before each of them rather than after.
Stated facts
Checked against the health route, observability code, systemd units, and cron scripts in the product repository. Rows marked as your deployment are capabilities that exist but do nothing until someone configures them.
Verified against the product code on .
| Question | Answer | Basis |
|---|---|---|
| Is there a health check? | Yes. A public endpoint returns a status based on a database ping, and a detailed variant for authorised staff also reports email and payment configuration. | In the product |
| Is there an operations dashboard? | Yes, inside the product for leadership and platform administrators: database status, failed payment and email queues, service objectives, and the last run of each scheduled job. | In the product |
| Are scheduled jobs monitored? | Yes. Each run records a success or failure heartbeat, and a required daily job that has not reported for around a day and a half raises an alert. | In the product |
| Which scheduled jobs install automatically? | The examination jobs, on a daily timer created during deployment. | In the product |
| Which do not? | The daily school operations job covering autopay, fee dunning, homework reminders, notices, admissions expiry, data retention, and alert evaluation. It is documented but must be scheduled by whoever runs the server. | Your deployment |
| Do alerts reach anyone outside the product? | Only if you set an error webhook URL. Otherwise alerts are visible in the operations dashboard and errors go to the server log. | Your deployment |
| Is there automatic retry on a failed job? | No. A failure is logged and surfaced; the next scheduled run is the retry. | Not available |
| Where do logs go? | The system journal on your server, for the application, the web server, and the scheduled jobs. Log retention is your host configuration. | Your deployment |
| Is there a public status page or external uptime monitoring? | No. Neither is included. Point your own monitoring at the health endpoint. | Not available |
| Is there a published uptime target? | No. We do not measure one across deployments we do not host, so publishing a figure would not mean anything. | Not available |
| Is there a documented incident response or on-call process? | Not in the product. Service objectives name the internal role each issue escalates to, which is a starting point rather than an on-call rotation. | Not available |
| Can we get a support response commitment? | Ask for it in the agreement. Nothing here should be read as one. | Agree in writing |
Product truth
Good school software copy should answer who owns the work, what the handoff produces, and which parts still depend on deployment decisions.
This page describes the supported workflow boundary. Confirm configuration, integrations, data, and policy requirements in a representative pilot before committing to production.
Deep dive
Use these details to turn a product page into an implementation conversation.
A health endpoint, an internal operations dashboard, per-job heartbeats, service objectives with escalation roles, and alerts for database, payment and email failures are all in the product. Most of it depends on the daily job actually being scheduled, which is the step most easily skipped at go-live.
Publishing a figure we do not measure would be the least useful sentence on this page. There is no external uptime monitoring or public status page in the product; if you want an availability commitment, it belongs in your agreement and needs monitoring behind it.
Assign someone to schedule the school job, inspect heartbeats, receive webhook alerts, and act on a stale service. Monitoring without a named response owner only records the problem.
Evidence layer
Read the supporting product and implementation material before making a capability claim.
Straightforward answers for visitors evaluating the product.
There is no published uptime figure, and we would rather say so plainly. The application runs on your server, so availability depends mostly on that host. If you need an availability commitment, raise it in the agreement and expect it to come with monitoring obligations on both sides.
Run a representative class through draft, review, and publish states before relying on the output for a reporting deadline. Check which role owns corrections after the result becomes visible to families.
No. There is a health endpoint your own monitoring can poll, and an operations dashboard inside the product for staff with the right role, but no public status page and no third-party uptime monitoring included.
Treat that boundary as an explicit procurement or deployment decision. Document the responsible owner and any supporting process before rollout.
The failure is recorded as a job heartbeat, and a stale required job raises an alert once alert evaluation runs. The alert is visible in the operations dashboard, and reaches a webhook if you configure one. There is no automatic retry - the next scheduled run is the retry.
Validate credentials, permissions, and failure handling in a non-production environment before connecting live school records. Assign an owner for monitoring the handoff after launch.
The daily school operations job. Examination jobs install their own timer during deployment; the school job is documented but not installed for you, and fee autopay, dunning, reminders, notices, and alert evaluation all depend on it.
Before the first collection cycle, reconcile one paid, partially paid, and overdue student account so the family receipt and finance view agree. Keep any tax, gateway, refund, or accounting boundary as an explicit deployment decision.
Not a published one. There is no documented on-call rotation or support service level in the product, so treat support expectations as something to agree in writing rather than something to infer from this page.
Pilot one record through application, review, decision, and handoff so the public status and staff queue remain aligned. Include an incomplete-document or declined-offer case before opening the workflow to every intake.
No. The health endpoint reports application and database availability when polled; it does not provide external monitoring, a status page, or a response commitment.
Treat that boundary as an explicit procurement or deployment decision. Document the responsible owner and any supporting process before rollout.
Continue exploring
Follow the next link based on the question your team needs to answer.
School software procurement questionnaire
A practical questionnaire for evaluating school software across workflows, data, security, implementation, support, and total cost.
Read the pageFirst 90 days of a school software rollout
Sequence foundation data, one visible workflow, role training, and evidence-based expansion instead of attempting a big-bang launch.
Read the page
We can walk through the workflow with your school’s roles, calendar, data, and first-term priorities.
Already using Schoolyi? Sign in
