Retention Schedule
What is kept, for how long, and — separately — whether anything actually enforces it.
Effective from 24 August 2026.
In short
This page separates two things most retention policies run together: the period a record should be kept for, and whether a scheduled job actually deletes it.
Where nothing enforces a period, it is listed under not automatically enforced and described as an intention, not a fact. A written commitment nobody keeps is worse than no commitment — and most of what is held here is data about children.
How to read this page
Every figure below is read from the configuration of the deployment serving this page, not retyped from a document. A school that has agreed a different period with Fleetr Edge Technologies Ltd will see its own figure here.
Two badges are used, and they mean exactly what they say:
Enforced a scheduled job deletes this, nightly, without anyone asking.
Not enforced nothing deletes this on a schedule today. Read it as an intention.
Enforced automatically
Each of these is deleted by a job that runs nightly.
| Record | Kept for | Status |
|---|---|---|
| Notification log Who was told what about which child, and when. The message wording is never stored. | 120 days | Enforced Nightly, 02:30. |
| Attendance export files A built spreadsheet of children, stops and times, sitting outside the application's own access controls. | 7 days | Enforced Nightly, 03:00. The file goes; the record of who asked stays. |
| Export audit rows Who took a copy of the roll, and when. Kept long after the copy itself is gone. | 730 days | Enforced Nightly, 03:00, by the same job. |
| Abandoned guardian uploads A spreadsheet of every parent's phone number, uploaded and never confirmed. | 24 hours | Enforced Nightly, 02:45. The file goes; the upload history stays. |
Bounded by design, not by a job
These need no deletion job, because the shape of the data does the work. They are listed so the absence of a job is not mistaken for an oversight.
- Bus positions. School Run keeps one row per bus — the latest fix — and overwrites it. It holds no history of where a bus has been. The historical track lives in core Fleetr, under the School's own fleet-tracking account and that account's retention.
- Confirmed and cancelled uploads. A student or guardian import file is deleted the moment the import is confirmed or cancelled. The row recording who uploaded what survives.
- Sessions. A signed-in session expires after 120 minutes of inactivity, and expired rows are cleared by the framework's own garbage collection.
- Message bodies. Never written down in the first place, so there is nothing to expire.
Not automatically enforced
Nothing deletes any of the following on a schedule today. Each is stated as what it is — an intention, or an operator responsibility — and not as a promise.
| Record | Intended period | Status |
|---|---|---|
| The attendance record Every boarding and alighting, the stop, the time and who confirmed it. | 7 years | Enforced attendance:prune, daily at 03:15. Removes the record and the event log it was built from, together. |
| Raw inbound events The signed telemetry deliveries from core Fleetr, kept append-only so the position projection can be rebuilt. | No period set | Not enforced Vehicle data. Retained indefinitely today. |
| Abandoned student uploads A spreadsheet of children uploaded and never confirmed or cancelled. | Should match guardian uploads | Not enforced There is no equivalent nightly job for student uploads yet. |
| Platform audit log What platform staff did to which school. Read-only; no route edits or removes an entry. | Kept for the life of the platform | Not enforced Deliberate: an audit trail that expires is not much of one. |
| Children, guardians and staff records | While the School subscribes | Not enforced A leaver is marked as left, not deleted, so the attendance that references them survives. |
| Application logs and backups | Operator's own cycle | Not enforced Managed outside the application. Message bodies and credentials are kept out of both. |
Why the attendance record is kept for this long
7 years is not an arbitrary figure. The record exists to answer a question about how a child was handled. In Kenya a claim in contract runs for six years under the Limitation of Actions Act, and a person who was a minor at the time has that clock start at majority — so anything much shorter risks the School being unable to answer the question the record was kept for.
Seven leaves a year of margin for a claim filed on the last day, and it matches the span a Kenyan school already keeps its own books to — one retention rule rather than a second one invented by the bus software. Against that, the Data Protection Act 2019 storage-limitation principle, sharper still for children's data, argues downward. Seven years is where the two meet.
Deletion removes the attendance record and the event log it was built from, in the same pass. The record is a rebuildable summary of the latest event; expiring it while the event log survived would delete the summary and keep every movement it summarised.
On termination
When a subscription ends, the periods above stop being the operative rule. Clause 12 of the Terms of Service takes over: a thirty-day window in which the School may export its data, then deletion from live systems, then encrypted backups ageing out on the ordinary cycle.
Changing a period
A school that needs a different retention period — a shorter one for the notification log, or a firm deletion date for attendance — should ask Fleetr Edge Technologies Ltd in writing at hello@fleetr.co.ke. Every enforced period on this page is a configured value, so changing one is configuration rather than a release.