Skip to content
Kinetic Melbourne OCC User manual

Manual / When something looks wrong

Who to tell

For
a controller who has found something wrong
Status
current
Covers
the version chip, the browser's address bar, and the Admin Console
Last checked against the app
0963ac5 (2026-08-19)

There is no report button in this app. Nothing on any screen sends a message to anybody. Reporting a problem means telling a person, and this page is what to tell them so that they can act on it without a conversation first.

Who

Whoever administers this deployment — the person or team who creates accounts, loads a newer timetable and loads the roster. They are the only people who can fix most of what goes wrong here, and the Admin Console is where they do it: accounts and roles, the data versions the server is serving, and the record of recent activity.

This manual cannot name them: it ships with the app, and every control room's answer is different. If you do not know who yours is, the person who gave you your account is the right place to start.

What to send

Six things. The first two do most of the work.

1. The version chip's date. It is in the top bar. Hover it for the exact release name and send that too. This one line separates "the fix has not reached us" from "the fix does not work", which is otherwise a whole afternoon.

2. The address from your browser's address bar. It reproduces the tab, the route, the direction, the stop, the date, the operator filter and the overlays you had switched on — so instead of describing where you were, you can hand it over. It does not carry your exact pan and zoom; the map frames the route for itself at the other end.

Keep an Operations address inside your control room. An address pointing at the Operations Analysis tab names a shift or a run, and that is roster detail. The same goes for anything naming a diversion's cascade.

3. The exact words on screen. Quote the banner, the message or the tooltip rather than summarising it. This app writes different sentences for different causes, and the sentence is usually the diagnosis.

4. When, and how often. The time it happened, and whether it happens every time or happened once.

5. Whether you were signed in, and as what role. Not your password — nobody will ever ask for it, and nobody in this app can see it.

6. Whether anyone else sees it. Ask someone at another workstation to look. It is the fastest way to separate "something about this browser" from "something about this deployment", and it is the first question you would otherwise be asked.

What never to send

  • Passwords. No administrator needs yours; they can reset it instead.
  • Anything from the driver roster, to anyone outside your control room: driver names, shift identifiers, duty times, depot rosters.
  • Screenshots of the Operations Analysis tab or of a diversion's cascade, outside your control room. Both are drawn from the confidential roster, and an image cannot be redacted after it has been sent.

Check these three first

Most reports resolve into one of them, and each takes under a minute:

  • The banners, one by one — the app's own account of what is wrong is more specific than any description you could write;
  • A tab is greyed out — faded, padlocked and absent are three different problems with three different answers;
  • The map looks wrong — a zoom, a filter or a switch explains most empty maps.

What they do not mean

A missing feature is not a fault, and reporting it as one sends the wrong person looking. If the control has never been there on this deployment, the question is a setup question. Say "we have never had this" rather than "this has stopped working" — they are answered by different people.

"It works for me" does not clear the report. Several of the things on these pages are per browser: the release notice, the record of where you have been, and any setting you have chosen while signed out. Two people at two desks can honestly see different screens with nothing wrong.

An administrator cannot fix the feeds. Where the problem is that the state's live feed or a road feed has stopped publishing, the app is reporting somebody else's outage faithfully. What an administrator can do is confirm that is what it is.

And if this manual is the thing that is wrong

Say so, to the same person. If a page here disagrees with the app, the page is wrong — even where the page is more accurate than the button. A reader hunting the screen for a word this manual invented has been sent nowhere, and cannot tell whether they are on the wrong screen or reading the wrong page. Quote the sentence and name the page, and it can be corrected.

There is a second document, for whoever changes the software rather than uses it: the Developer handbook. It answers a different set of questions — how the app is built, how it is deployed, what each part of the code is for — and it is not the place to look for anything on these pages.

You almost certainly cannot open it, and that is not a fault. Where it is published at all, it is published to administrators, so the link to it in the map's copyright popout is simply not drawn for most accounts. If a problem really does need it, the administrator you are already telling has it. Nothing in this manual sends you there.