Release notes

List Mode's display rules (Last Out, the care week, sorting, the assessment countdown) and the Sync issues wording now come from one shared place used by the web and the phone, so the two cannot drift apart. We compared the old and new rules over more than 27,000 cases, including daylight-saving days: nothing changes on the web.

Where: Not visible in the app.

When a new version takes over a page quietly, the page you are on is saved for offline use at that moment, so it still opens without a connection. Error reports are sent before the app reloads itself for an update, so a problem just before a reload is no longer lost.

Where: Not visible in the app, apart from the page you are on still opening offline after an update.

A new version sometimes has to add an index to a busy table. That used to make every save to the table wait until the index was built. Indexes are now built without blocking saves, the release checks afterwards that none was left half-built and stops with the fix in its message if one was, and a check before each release refuses a database change that would lock a busy table or break the version still running.

Where: Not visible in the app. It means a release during the day does not freeze sign-outs.

This version adds dozens of automatic checks that run before every release. Each one guards a kind of mistake found while building it: a page that flashes back to placeholders, a form that loses what you typed, a button hidden under the phone bar, text that cannot be read in the dark theme, an animal missing from the search after a save. A release that fails any of them does not go out.

Where: Not visible in the app. It means fewer fixes that come back.

The building blocks Shelter Sense is made from (the web framework, the build tools, the server framework and the error-reporting library) moved to their current versions.

Where: Not visible in the app.

The enrichment totals and Quality of Life scores at the top of List Mode were worked out once, while the page was being built, and then left alone. Recording an enrichment session or an evaluation changed the animal's card but not the totals above it, so the two halves of the same page disagreed until you reloaded.

Those numbers now refresh after a change, including a change somebody else made on another device. They also refresh when the device reconnects, when you come back to the tab, and once a minute as a fallback, so a signal that never arrived cannot leave a stale number on screen. Bursts of changes are gathered into one refresh, and an answer that arrives after a newer one is ignored rather than overwriting it.

Opening a page no longer immediately reloads the same numbers. Unrelated changes and ordinary staff logins leave them alone. Temporary background refresh failures retry quietly without repeatedly interrupting your work.

Where: The statistics cards and the summary table at the top of List Mode.

List Mode prepares the cards near the top of the page first and the rest just before you scroll to them. A live update that arrived before a card had been prepared had nowhere to go and was dropped, so an animal signed out on another tablet in that moment kept showing its old state until the page was reloaded.

Those early updates are now held and replayed the moment the card is ready. An older saved live update can no longer replace a more recent location or badge name loaded from the server.

Where: Animal cards in List Mode, most often in the first seconds of a long roster.

Editing something an animal points at, rather than something on the animal itself — its location, its colour code, a biosecurity level, a special need or a behaviour — saved the change but told nobody, so other open screens kept showing the old name. Deleting one had the same problem.

Every active animal affected by such an edit or deletion is now published, and the cards and summary rows that show it update without a manual reload. Data-point field names and choice labels now follow the same update path. Live changes to those relations are also ordered separately from changes to the animal record itself, so neither one can now discard the other for looking older than it is.

Where: Animal cards and the List Mode summary, after an edit in Locations, Colour Codes, Biosecurity Levels, Special Needs or Behaviours.

Only the Locations table refreshed itself, through a workaround written for that one page. Every other settings table showed whatever it was given when the page opened, so an entry added or renamed elsewhere — or by you, in another tab — stayed invisible until you reloaded.

Nineteen tables now share one refresh: Animals, Animal Types, Locations, Biosecurity Levels, Colour Codes, Special Needs, Behaviours, People, People Types, Users, Cohorts, Roles, Permissions, Census Types, Enrichment Types, Enrichment Sessions, Evaluations, Comments and Training Plans. The page you are on and the filters you have set are kept, and a change you have just made yourself is not undone by the refresh that follows it. Each table only ever receives the rows you are allowed to see, checked on the server as before.

Where: The Animals page and the management tables under Settings.

The card used to flip to "signed out" as soon as you pressed the button, before the server had answered. If the answer was then something the app could not read — which is what a dropped connection or a server restart mid-request looks like — the card could break outright, or settle into showing the animal as signed out when nothing had been recorded.

The form now shows that it is working until the server answers, and the card changes only once the sign-out is confirmed. If the answer is lost on the way back, the card is left as it was and an error is shown; if the sign-out did reach the server, the live update brings the card up to date. A sign-out made while offline still shows straight away on that tablet, marked as queued; other tablets see it once the server has accepted it.

Where: The sign-out form on animal cards in List Mode.

Signing an animal in or out, or undoing it, tells every other open tablet about the change a moment after your save finishes. Each of those announcements used to carry its own copy of the change. When two actions on the same animal came close together — most often a sign-out followed straight away by Undo — the two announcements could arrive in the wrong order. Other tablets then showed the animal as still out on its old outing while the shelter's records said it was back in, and stayed that way until the animal changed again or the overnight refresh ran.

Each announcement is now read fresh from the shelter's records as it is sent, and one that a newer change has already overtaken is turned away and read again. Whichever order they arrive in, every tablet ends up showing what was actually saved.

Where: Animal cards and the List Mode summary on other tablets, after a quick sign-out and Undo.

When a tablet believes it is offline, a sign-out is queued and the card on that tablet changes straight away. If the live connection was in fact still open — a wifi drop the browser had not noticed yet, for example — that change also went out to every other tablet. And if a colleague had already signed the same animal out, the shelter refused the queued sign-out when it synced ("Animal is already signed out"), but nothing put the other tablets right. They showed the queued tablet's version instead of the real outing until the overnight refresh, and so did the queued tablet itself, even after a reload.

A queued sign-in, sign-out or undo now changes only the tablet it was made on. Other tablets hear about it from the server once it has been saved. If the shelter refuses it, the animal is announced again from what was actually recorded, so every screen, including the one that queued it, goes back to the truth.

Where: Animal cards on every tablet, after a sign-in, sign-out or undo made on a tablet that was offline.

An animal that is currently signed out cannot be archived. The Animals table now says so — "Sign the animal back in before archiving it" — and keeps archiving disabled while the animal is out, instead of letting you confirm and then failing.

The same check runs again when you confirm, so an animal that somebody else signed out while your dialog was open is caught as well, and the server still refuses it as a last line of defence. That refusal is now treated as the ordinary rule it is rather than as a fault in the app.

Where: The archive action in the Animals table.

Archiving an animal on a device that is offline is now described as queued rather than done, because whether the shelter will accept it is not known until the device reconnects.

If the server then refuses it — most often because the animal is signed out — the refusal is listed under Sync issues with the real reason. Archives queued by an older version used to come back as an unexpected failure and be retried forever; they now keep their reason too.

Where: Archiving from a device working offline, and the Sync issues list behind the warning badge.

A tablet or phone that works offline keeps a copy of recent pages so it can still show them without a connection, and that copy belongs to the organisation that turned offline mode on. After you had visited such an organisation, pages from another organisation where offline mode is off were saved into the first organisation's copy as well, and shown from it whenever the connection was down or took longer than eight seconds to answer. On a tablet shared between staff, the same mix-up could show a page saved during one person's session to the next person who signed in, when the first person's sign-in had expired instead of being signed out.

The offline copy now only keeps and shows pages of the organisation it belongs to. Turning offline mode off for an organisation removes its pages from every copy on the device, and Log Out starts the device afresh for the next person.

Where: Tablets and phones that work offline, especially ones used for more than one organisation or shared between staff.

The app already reloaded a page section once on its own when the connection died halfway through loading it. Firefox words that failure differently, and so does the offline service that serves pages when the network is poor, so neither was recognised and both were left on screen as a broken section.

Both are recognised now, so opening a page and refreshing the offline copy recover on any browser. Downloading the offline copy also stops when you leave the page instead of carrying on in the background, and a device that already has a usable copy no longer downloads a second one.

Where: Any page after a brief connection loss, and preparing offline access on tablets and phones.

The occasional "How is your experience?" prompt used to offer one empty box labelled Comments, which left you to guess what we were hoping to hear. It now asks two questions instead: what you love most — the parts that make your shelter's day smoother or faster — and your biggest pet peeve — the clunky steps, missing features or confusing screens that need fixing. Answer one or both. Each answer reaches the Shelter Sense team under its own question, so praise and problems no longer arrive tangled together in one paragraph. Line breaks stay as entered and no longer make an answer exceed the displayed character limit when it is submitted.

Because the questions are new, everyone sees the prompt once more after this update, even if you answered or dismissed the old one a few days ago. After that it goes back to its usual schedule.

Where: The "How is your experience?" prompt, for organisations that have it turned on.

A request that fails and then succeeds on the retry is ordinary life on shelter wifi. It is now recorded as a warning everywhere, instead of a warning in some places and an application error in others. An archive refused because the animal is signed out is an expected answer and no longer files an error report at all.

The point of both is that a real fault stands out instead of being buried under hundreds of these.

Where: Not visible in the app. It means real problems get noticed sooner.

Every open List Mode page keeps a live connection to its organisation's shared room: a small store on our server that tells every tablet the moment an animal is signed in or out, and tells each person how many unread notifications they have. Until now the room took the browser's word for things. Any signed-in member's browser could write any entry in it, including entries only our server should ever set, and could read every entry, including other staff members' unread-notification counts.

The room now accepts changes only from the Shelter Sense server, which takes them from the shelter's records, and each connection can read only the entries every member shares plus its own notification count. Which person a connection belongs to is decided by our server, never by the browser.

Where: Not visible in the app. It closes a way one browser could change what every tablet in a shelter showed.

When our server cannot tell the tablets about a change — a network fault between our servers, or a restart during an update — it now writes the change down and keeps retrying until the tablets have it, as described above. A repair that is still failing after about an hour raises one alert for us, so a stuck repair is noticed the same day rather than waiting for someone to spot an out-of-date card.

The overnight refresh, the last safety net that re-sends every animal to every tablet, also carries on to the rest of a shelter's animals when one batch fails, instead of stopping there. The checks we run before every release now exercise the repair list against a real database, because the timing problems it guards against cannot be reproduced any other way.

Where: Not visible in the app. It means a tablet that missed a change is put right, and we hear about it if that ever stalls.

Three changes had shipped without an entry here: the demo-request fix, the single nightly-maintenance check, and the move of app email and scheduled work to Cloudflare. All three are now written up below, under the release that carried them.

Where: This page, and the release-notes window inside the app.

Shelter Sense runs five scheduled jobs overnight. Each one was watched separately, so an incomplete night showed up as a gap in one of five places rather than as a single clear answer.

One check now confirms that all five finished, and alerts us after the morning catch-up window if any of them did not. Each job still retries on its own, so a job that stumbles once and then recovers raises nothing.

Where: Not visible in the app. It means an incomplete night of maintenance is noticed the same morning.

Submitting the demo-request form answered "Error submitting request, please try again", however many times you tried. The form was sending its request to an address the server did not recognise, so nothing was recorded and no acknowledgment was sent — and because the form looked as though it had simply failed, there was nothing to suggest trying another way of getting in touch.

That address is now connected to the handler that records the request and sends the acknowledgment email.

Where: The demo-request form on the Shelter Sense website.

App emails now use Cloudflare's email service, with a queue that tracks delivery and retries temporary failures. Scheduled maintenance and the trial-reminder sweep also run on Cloudflare. Nightly jobs retain a catch-up run so a missed first attempt can be recovered without repeating work that has already finished.

Where: App emails and background maintenance.

The service every sign-in depends on used to be replaced in one go during an update, which left a short window in which nobody could sign in. It now starts the new copy, waits until it can reach its database, and only then switches over, and it will run as a pair so a restart outside an update does not take it down either.

Where: Not visible in the app. It matters on the day we ship an update.

The dashboards we watch, the alerts we receive and the checks that confirm the site and the nightly jobs are running are now defined in code with the app, reviewed like any other change, and cover the gaps found in this release's investigation. Network blips on shelter devices are recorded as warnings instead of being filed as application errors, so a real fault is no longer buried under them.

Where: Not visible in the app.

Until now, every time Shelter Sense read or saved a record, the request travelled from the servers that run the app in Toronto to a database in the eastern United States and back. The database now runs in the same Toronto facility as the app, so that round trip is gone. Pages that read a lot of records, such as List Mode and reports, feel quicker, and saves come back sooner.

The database also runs as a pair: a second copy stands ready, and if the first one fails the second takes over on its own within moments, without anyone at the shelter needing to do anything.

Where: Not visible in the app. Every page and every save benefits.

Your records are now backed up every hour, with a full copy taken every day, and ten days of history is kept. If something ever had to be restored, we can bring records back to a chosen point in time within that window instead of only to the previous night.

Where: Not visible in the app. It matters on the day something goes wrong.

The brief server errors that earlier releases learned to recover from came from the service that used to sit between the app and its database. That service is no longer in the path, so that whole family of errors goes away rather than being retried.

Where: Any page, most often while saving or opening a long list.

On a long roster, List Mode used to pause for several seconds after the page appeared while it prepared every animal's card at once — taps and clicks did nothing until it finished. It now prepares only the cards near the top right away; the rest keep their place on the page and finish preparing just before you scroll to them. Every card still receives live updates the whole time, whether or not it has been prepared yet.

Where: List Mode.

Every heading in the List Mode summary table is now a sort control. Click a heading to order the rows by that column, click it again to reverse the order, and the animal cards below follow the same order. The choice is kept in the page address, so it survives a reload and can be shared as a link. Clicking a row still scrolls to that animal's card, and an animal whose live status changes moves to its new place in the order without a reload.

Where: The summary table at the top of List Mode.

Several forms handled a refusal from the server but not a lost connection or an unexpected server failure. In those cases the button stopped spinning and nothing else happened. Archive, restore, cohort removal, placement changes, census export, and other affected actions now show a clear error and leave the current screen in a safe state.

Multi-part edits now save as one operation as well. An animal edit, special need edit, assessment, or access approval can no longer leave only half of the requested change behind.

Where: Animal editing, reference-data settings, access requests, reports, and List Mode.

A connection changing state at exactly the wrong moment could make an online save disappear instead of either reaching the server or joining the offline queue. The app now decides once which path owns the save. Signing out and switching accounts also fail closed if private offline data cannot be cleared, rather than opening another account over the previous user's cached records.

Where: List Mode saves, sign out, and account switching on devices that work offline.

Until now an assessment could only be added. If one was recorded by accident, on the wrong animal, or by someone who had misunderstood what an assessment is, there was no way to take it back — so the workaround was to file a second, empty assessment to cancel out the first. That left invented records in the behavioural history of a real animal.

Each animal card now has an Assessments button listing everything recorded for that animal, newest first, with Edit and Delete on each entry. Editing changes the wording only; the date an assessment was recorded stays as it was, because that date is what the assessment-due countdown is measured against. Deleting asks for confirmation first.

Deleting the most recent assessment brings that animal's assessment-due countdown back, exactly as if the assessment had never been recorded. An animal can never be left looking up to date because of an assessment that was removed.

Editing an assessment needs the same permission as editing an animal, and deleting one needs the same permission as deleting an animal, so a volunteer who cannot change animal records cannot change assessments either.

Where: The Assessments button on each animal card in List Mode.

A training plan written for the wrong animal, or one that no longer applies, can now be removed from the animal's profile. The Training Plan panel on the animal detail page has a Remove button that asks for confirmation and then shows the panel's empty state, ready for a new plan. If the plan fails to load, the panel offers Try again instead of leaving its buttons disabled.

The Delete button on the Training Plans list page now appears only for people whose role allows deleting training plans; before, it was shown to everyone and then refused.

Where: The Training Plan panel on each animal's detail page, and the Training Plans page.

Animals now have a Sex field with Male, Female, Intersex, and Unknown choices. Existing animals begin as Unknown, and Sex appears in List Mode by default. Administrators can also add their own text, number, date, yes/no, and choice fields for each animal type, decide which ones are required, and choose which ones appear as List Mode columns.

These details are available while adding or editing an animal, in Quick Edit, during cohort quick-add, on animal cards and detail pages, in search and filters, and in animal-related CSV exports. Archived fields and choices keep their historical values, including through offline syncing.

Where: Animal Type Options, animal forms, List Mode, animal details, filters, exports, and offline work.

Cohort membership is now recorded on stays, enrichment sessions, and evaluations. Moving an animal between cohorts no longer rewrites earlier census or enrichment results. Completed assessments also keep the funnel that produced them instead of changing when today's animal settings change.

Historical records are protected from destructive cleanup too. A color code, special need, role, or animal cannot be removed when doing so would erase or expose records that still depend on it. Animals with placement history remain available to historical census reports, and an animal on an active outing must be signed back in before it can be archived.

Where: Census, enrichment reports, assessments, roles, animal settings, and archive actions.

Placements can no longer end before they begin, arrivals cannot be dated in the future, and malformed or fractional page values no longer reach database queries. These are rejected with an explanation before they can create a record that later reports cannot interpret.

Where: Animal intake and outcome history, placements, and paginated lists.

Organization creation now includes its default roles and settings in the same transaction, so a temporary database failure cannot leave a paid organization only partly usable. Super-user provisioning can resume after an interrupted attempt. Expired, revoked, or cancelled invitations stay unusable, and simultaneous invite, accept, cancel, and access-request actions now have one database-backed winner.

Deleting a role also refuses while current users, pending invitations, or restricted comments still depend on it, so access cannot silently broaden.

Where: New organization setup, invitations, access requests, and role management.

Two identical report requests made together now produce one job. Report failures show a safe, useful message without exposing database or service details, and retries cannot race into duplicate work. Failed CSV downloads now tell you they failed.

Replacing a photo or deleting a training plan now removes superseded files only after the database change succeeds. Failed uploads are cleaned up, and direct upload endpoints apply the same subscription checks as the rest of the app.

Where: Generated reports, CSV exports, animal photos, and training-plan files.

On the sign-in page, pressing Tab in the email box used to land on the "Forgot password?" link, so reaching the password box took two presses. The link now sits below the password box, where it is still reachable by keyboard, and Tab goes from email to password in one press. Staff who share a tablet and sign in many times a day asked for this.

Where: The sign-in page.

Shelter Sense's colours use a colour format that Chrome added in version 111 (March 2023). A Chromebook past its update expiry, or any older browser, silently dropped every one of those colours: badges lost their fill and dialogs lost their background, so a training plan appeared on top of the card behind it. Those browsers now see a clear notice at the top of every page saying the browser is too old and should be updated, and the panels and the primary badge keep a plain fallback colour so the page stays legible in the meantime. Up-to-date browsers are unaffected.

In the same spirit, a card whose training-plan status has not arrived yet shows Unknown rather than a confident "NO", and Quick Edit does not offer to create a plan until it knows whether one exists.

Where: Every page on an old browser; the training-plan badge on animal cards.

When your session has ended, or your access to a shelter has changed, the app is meant to move you to the sign-in page. If our server happened to be slow at that exact moment, it did something else instead: it left you where you were, with the list replaced by an error message, and never moved you anywhere. Reloading produced the same thing, so there was no obvious way out except closing the tab.

The app has to decide where to send you before the page starts drawing. Normally it does. When the server was slow to answer, the decision landed after drawing had already started — too late to move you, so it surfaced as a broken panel instead. It now recognises when it has missed that moment and moves you from your own browser instead, which still works.

Where: Any page inside a shelter, when a session ends or access changes during a brief server hiccup.

Nothing here changes what you see. When the app hits a problem it sends us a report, and for a few days those reports came back from part of the app with the location missing — a position inside one very large file, rather than the file and line the problem was actually in. The fix above was found in spite of that, not because of it.

Two separate faults caused it, and both are fixed: the reports are readable again, and a check now runs before every release that refuses to ship if they would not be. We have also stopped publishing a set of developer files alongside the app that were never meant to be public.

Where: Not visible in the app. It means problems you report get diagnosed faster.

Before showing you anything, every page inside an organisation asked our server three questions in a row: who you are, which shelter you are in, and whether you are allowed to be there. Each one waited for the previous one to come back, and nothing at all was drawn on screen while that happened. On a cold open, List Mode held a blank screen for roughly two seconds before it even began asking for the animals.

Those three questions are now one question, asked once, before the page starts drawing — and asked in a place where the answers are already close at hand, so it costs less than any one of the three did before.

Where: Every page inside a shelter. Most noticeable opening a page cold, or after the app updates.

The list of animals was fetched only after the page heading came back, because the heading was the only thing that knew which shelter and which animal type you were looking at. So the two waits happened one after the other rather than together.

The server can work both of those out on its own, so it now does, and the page asks for both at once. The wait is the longer of the two instead of the sum.

Where: Every List Mode page.

Four separate requests on the busiest paths existed to produce answers that were thrown away — one of them asked before every single page render. Nothing read them. They are gone, and nothing about what you see has changed.

One of these was quietly making a real problem worse: when our sign-in service had a hiccup, the app reported it as "you are not signed in" and sent you to the login page. It now reports it as what it is, a temporary fault.

Where: Every page inside a shelter.

Signing an animal in and editing an animal are the two things you do most, and both were taking around three seconds. Almost none of that was saving your work — the save finished quickly, and then the app kept you waiting while it tidied up afterwards: clearing caches in small batches with deliberate pauses between them, and telling every other open tablet what had changed, across the internet, retrying if that failed.

Your work is saved at the moment the save finishes, so that is when you get the tablet back. The tidying still happens, just not while you are standing there holding it. Your own screen already knew about the change; other people's screens are told the same way they were before.

Where: Signing in, signing out, undo, and editing an animal.

Every time a tablet opened its live connection, the app ran the same heavy lookup a whole page render runs — including, occasionally, a call out to our payment provider — to read one small fact from it and discard the rest. Those connections are made far more often than pages are opened.

It now asks only the question it actually needs answered.

Where: Automatic, on every List Mode page.

A tablet whose session had ended kept trying to reconnect every thirty seconds, indefinitely, and said nothing about it. In one day that was more than four hundred attempts from a single tablet — each one a full request to our server to be told something the tablet already knew, that it had no session.

It now recognises that itself without asking, and, more to the point, it tells you: a tab that has been signed out says so instead of sitting there looking fine and quietly doing nothing.

Where: Any tab left open long enough to be signed out.

For a short window after an update, an animal's detail page could show a "—" for Quality of Life, hide the sparkline and the Engagement, Wellness and Sentiment tiles, and say there were no records in the last seven days — while List Mode showed that same animal a real score.

Neither screen was wrong about the data; the detail page was misreading days that were recorded before the update as days with nothing recorded on them. It now reads them the same way the rest of the app does.

Where: The Quality of Life section of an animal's detail page.

The last release took each animal card from fourteen live connections down to three. That helped, but three per animal is still one set per animal — a list of seventy cats opened over two hundred of them, all at the same moment, every time the page loaded and again every time the app came back after an update. That burst is what the tablet was struggling with.

The page now opens three in total, for the whole list, no matter how many animals are on it. A list of five hundred costs exactly what a list of five costs. Nothing about the cards or what they show has changed.

You should notice this most on first load and in the minutes after an update — the two moments the hanging was worst.

Where: Every List Mode page.

Both of these only happened when two people were working at once, which is why they were easy to miss and hard to describe.

If somebody signed an animal in while your page was open, and you then expanded that animal's card, the card could go back to showing it signed out. Your screen said one thing and theirs said another until you reloaded.

Separately, the very first time an animal was signed in after an app update, nobody else's screen was told about it at all.

Both are fixed.

Where: List Mode cards and the summary table.

When a change you made offline is rejected by the server, it used to stay stuck until somebody opened Sync issues and pressed Retry. In practice nobody does — we found someone carrying two weeks of undelivered work without knowing it.

Some rejections fix themselves: a role that was removed and later restored, or a subscription that lapsed and was renewed. In both cases the change would go through perfectly well on a second attempt, and nothing was ever making one. Those now retry on their own, a few hours apart, several times over.

The rest are left alone deliberately — an animal that has since been deleted, a clash with something a colleague already recorded, an entry the server will not accept. Retrying those would fail the same way forever, so they still wait for you on Sync issues, where you can review and re-enter them. Nothing is ever discarded on your behalf.

Where: Automatic. Sync issues should have fewer rows waiting for you.

Until now, if a page was slow for you, the first we knew about it was somebody mentioning it. We could see errors — the moments the app broke outright — but not the far more common case where everything works and simply takes too long. That is the gap the last release was spent closing after the fact.

Every action the app takes now records how long it took and whether it worked: opening a list, saving a comment, signing an animal in or out. So do the parts you never see — work saved offline making it to the server, live updates dropping and coming back, the nightly reports. We watch those numbers rather than waiting for a phone call.

Two things worth saying plainly. This does not make the app faster on its own; it tells us where to look, which is what the last release needed and did not have. And it records timings and counts only — never names, notes, comments, or anything about a specific animal or person.

Where: Nothing on screen changes.

Every card on the list was asking the server for its own details separately — seventy-two separate requests for a list of seventy-two cats, each one also re-checking who you are before answering. The cards all waited for the slowest of those before any of them filled in, which is why the grey placeholders sat there so long, and that many requests at once is what was tripping the brief "busy" spells that turned into error pages.

The list now asks once, for all of its animals together, and every card fills in from that one answer. Nothing about the cards themselves has changed.

Where: The detail cards on every List Mode page.

Each animal card was keeping fourteen separate live connections open for things that only needed three. That was fine for one card and not fine for seventy, and when the site came back after an update every tablet re-opened all of them at the same moment — which is the hang you saw. Worse, every time that happened a few of the old ones were left behind, so each update was a little heavier than the last.

Each animal now keeps exactly three, shared by everything on the page that shows it, and reconnecting re-opens exactly those three — no more, and none left behind. Tablets also now come back in a gentle spread over the first couple of minutes after an update rather than all at once.

Where: List Mode, especially in the minutes after an update.

When a change made offline is rejected later — for example a sign-in that clashed with one somebody else had already recorded — the Sync issues page used to tell you to review it and re-enter it, while offering only Retry and Discard. There was nothing to review.

Every row on that page now has a Review button. It shows exactly what was entered — the animal, the comment, the rating, the scores, who the comment was visible to — so you can copy it across before discarding the old copy. Rows also name the animal instead of saying "a change to sign animals in".

Where: Sync issues, from the warning badge in the top corner.

Two small checks that run on nearly every page — confirming you belong to the organisation, and counting the animals for the sidebar — had no second try if the data service was busy for a second. One of them failing meant the whole page failed. Both now wait a moment and try again, like the rest of the app already did.

Where: Any page in the app, and the Animal Lists section of the sidebar.

The copy of your animal list that the app keeps on the device — the one it shows you when the connection goes — was fetched during a quiet moment, and the app asked the browser to pick that moment without ever saying how long it was prepared to wait. On a busy screen the quiet moment can be a long time coming, and the animal list is the busiest screen there is. If it had not arrived by the time you walked out of range, there was no copy at all: the list simply came up empty offline, with nothing to explain why.

The app now waits a few seconds for a good moment and then goes ahead regardless.

Where: Any animal list, on a device where offline working is turned on.

Changes made without a connection are held on the device and sent up once you are back in range. They were sent twenty-five at a time — and only twenty-five. If a shift had produced more than that, the rest stayed on the tablet and waited for something else to happen: the connection dropping and returning, the screen being locked and woken, or somebody closing the tab and opening it again. Left alone on the animal list, as a shelter tablet usually is, nothing else happened, and the remainder sat behind "will sync automatically" for the rest of the day.

The app now keeps going until the queue is empty.

Where: Anywhere you work offline. The count is in the sync badge, and the details are under Sync issues.

When sending a change did not work — a moment of bad signal, usually — the app waited a little before trying again, doubling the wait each time up to fifteen minutes. But nothing was actually watching the clock. The wait ended only when something unrelated woke the app up, so a single failure could park one animal's sign-out until the tablet was next picked up.

The app now comes back by itself when the wait is over.

Where: Anywhere you work offline.

When a subscription lapses the app becomes read-only: you keep your data and can still read it, but changes are held until billing is sorted out. One screen was not covered. Deleting an animal type went through — and the version of that action which also removes every animal of that type went through too.

That is the most destructive thing the app can do, and it was the one thing an inactive account could still do. It now refuses like every other change.

Where: Settings, Animal Types. Nothing changes for an active subscription.

The email on your account page could be typed over. It looked like it worked, and it did change what the page showed — but your sign-in details live somewhere separate, so the two stopped agreeing. The next time you loaded the app it looked you up by the address you actually sign in with, did not find you, and started you off as somebody new: still signed in, but with none of your organisations.

The field is now shown for reference and cannot be edited, with a note pointing at support. If your account has already ended up in that state, get in touch and we will put it back.

Where: Account, under your name.

Your organisation's short name becomes the first part of every link you use — sheltersense.ca/your-shelter/.... A handful of words are used by the app itself, and one of those would have made links inside your organisation behave strangely. New sign-ups are now told to pick another one instead of finding out later.

Existing organisations are unaffected.

Where: Choosing a name when a new organisation signs up.

This release tightens several checks behind the scenes — how the app decides who is allowed to administer it, how it treats the link you are sent back to after signing in, and what it says when you ask to reset a password for an address that has no account. None of this changes anything you do day to day.

We have no evidence any of it was used against your data.

Where: Signing in, password reset, and staff-only administration screens.

Bringing an animal back records several things at once: the visit itself, a health note if you left one, your comment, and the fact that the animal is no longer out. The app was saving these one at a time, and each one is a separate trip out to the database. On a busy afternoon that added up past the time limit, the whole thing was thrown away, and the animal stayed on the board as still out.

Worse, it looked like it had worked right up until it did not. Trying again then said the animal was already signed out — which was true, but only because the first attempt had failed halfway.

It is now saved in one trip instead of several, so there is no longer a clock running against it. If that one trip does hit a hiccup, the app tries again on its own, and it cannot record the same visit twice while doing so.

Where: The sign-in form on any animal card in List Mode.

The service that carries our data occasionally gets busy for a few seconds and drops whatever happens to be passing through at that moment. It is not personal to your request and it passes quickly — but signing an animal out, checking your permissions, and loading the dropdown lists all gave up the instant it happened, and you got an error.

All of these now wait a moment and try again. Because these interruptions last seconds, the second attempt almost always goes straight through and you never see anything.

The Animals page gets the same treatment. Its first retry was tuned for a different kind of interruption and gave up inside the same few seconds the busy spell lasted, so the page could still come up with an error; it now waits long enough to outlast one.

Where: Signing animals out, the Animals page, and most screens in the app.

Saving an animal writes several things together — the animal, where it is kennelled, which lists it belongs to, its shelter ID. If the data service had one of its busy moments part-way through, the save failed and you got an error, even though there was nothing wrong with what you had typed.

Those saves now try again on their own. Adding a new animal was the delicate one: trying again must not leave you with two of the same animal. Each save now carries an identifier from the moment you press the button, so if the app has to try again it recognises the work its first attempt already did and finishes it, rather than starting a second one.

Where: The Add Animal form, and editing an animal's details.

When someone signs an animal out, everyone else's screen is supposed to update by itself. On tablets left open for a long time that connection was gradually breaking, and the app did not always notice — so two people could look at the same animal and see different things.

The cause was ours. Every few hours the app renewed the pass that lets it hold that live connection, and renewing it accidentally left the old connection behind instead of replacing it. Those abandoned connections kept calling in, and enough of them eventually crowded out the real one. Tablets left running overnight were the worst affected, because they had done it the most times.

The app no longer needs to renew anything mid-session, so there is nothing left behind and nothing to crowd the connection out.

Where: List Mode, on every device with the app open.

When you change an animal, everyone else looking at the board is told about it so their screen updates. That message was being put together after your change had already been saved — and if the data service hiccupped during that step, the message was dropped silently. Your edit was safe, you saw no error, and everybody else carried on looking at the old version of the card until something else refreshed it.

The step that was failing only decides which shelter ID system to label an animal's ID with. It now tries again, and if it still cannot answer, the update goes out without that label rather than not going out at all.

Where: List Mode, on everyone else's screen, after you edit an animal.

List Mode loads the comment counts for every animal on the page in a single request, which is much faster than asking for each one separately. But if that single request failed, every card on the page failed with it, and the list came up broken.

Three things changed. The list itself no longer depends on that request succeeding — the animals, their kennels, their colour codes and their sign-out forms all appear regardless. The request now retries by itself before giving up at all. And if it still does not arrive, the card says so, then fetches the comments again on its own as soon as you open that card's Comments tab, so they fill themselves in without you reloading anything.

Waiting for you to open the tab is deliberate, and we got it wrong first. Fetching them back for every card at once meant a long list firing off a couple of hundred requests in the space of three seconds — which is the exact thing the single combined request exists to avoid, and the exact thing that was overloading the data service in the first place. Our own testing caught it before it reached you. Now only the card you are actually looking at goes back for its comments.

Where: List Mode.

If your connection stumbled while part of a page was still arriving, the app already knew how to quietly fetch it again — but only when the browser described the problem in one particular way. Safari, Chrome and Firefox each word it differently, so on most browsers the app did not recognise its own recovery case and simply gave up.

It now recognises all of them, so a stalled panel refreshes itself instead of sitting empty or showing an error.

Where: Anywhere in the app, most visibly the sidebar and the animal cards.

Last release said that pressing Reload on the update message would show a spinner while the new version took over. It did not. The spinner was being created and then removed again in the same instant, so pressing Reload cleared the message and left you looking at an unchanged screen for several seconds before the page finally reloaded — which is exactly the "did that button do anything?" moment the spinner was added to prevent.

It now stays up until the page reloads, so there is something on screen for the whole wait.

If you have been seeing the update message come back after reloading, that was a tab still running the older version from before these fixes. Once a tab has loaded this release it stops.

Where: The "Update available" message, on any device with offline mode switched on.

After the last release, some people saw "Update available — Reload", reloaded the page, and got the same message straight back. Reloading again did the same thing. The message never expires on its own, so it simply sat there.

The cause is an unkind detail of how offline support works. A new version of the app installs quietly in the background and then waits for the old one to step aside — and pressing your browser's refresh button does not make it step aside. Only the button inside the message did, and even that had a timing flaw that could miss. So reloading the way anyone would normally reload left you in a loop with no way out of it. The previous release was the first one able to hand out a new version at all, which is why this surfaced now and not sooner.

The app now steps the new version in itself, at a moment when doing so costs you nothing: not while you are typing, not with a dialog open, and not in the middle of syncing. The message still offers a Reload button if you would rather not wait, it can now be dismissed, and repeats no longer stack up.

Pressing that Reload button also used to sit there looking like it had done nothing, because swapping the version over takes a moment. It now shows a spinner and tells you it is switching over, and the app says the same thing on the occasions it updates on its own — a page that reloads itself with no explanation reads as a glitch rather than an update.

We also added an alarm on our side for a device that cannot take an update. This particular failure was invisible to us — every request succeeded, nothing crashed, and the only place it existed was on the affected screen — so the first we knew of it was someone taking the trouble to write in. Thank you for that.

Where: The "Update available" message, on any device with offline mode switched on.

Tapping a link fetches the next page before anything on screen changes, so on a slow connection nothing happened for a moment and it was easy to think your tap had been missed — and to tap again.

There is now a slim bar across the very top of the screen while a page is loading. It waits a moment before appearing, so quick taps still feel instant rather than suddenly looking like they load, and it stays up until the new page is actually on screen rather than dropping away just before it arrives.

It does not pretend to know how far along it is — there is no way for us to know that — so it sweeps rather than filling toward a finish line it would only have guessed at.

Where: Every page-to-page move inside the app.

Announcements from us — a rollout going out, a scheduled maintenance note — sat at the top of the page and scrolled away with everything else. If you were part-way down a roster when one arrived, you would never see it.

Those notices now stay pinned at the top of the screen while you scroll, and they are set a size larger so the message reads at a glance instead of squinting. They can still be dismissed.

Where: App-wide notices, on every page.

Clicking Sign out did nothing. No error, no redirect — the request quietly stalled on our side and the screen stayed where it was, still signed in. Every sign-out button in the app was affected, and nothing in our automated checks covered it, which is how it shipped. Signing out is now a plain, boring page request that lands you on the login screen in one click, and the missing check now exists.

The same underlying fault could also swallow anything you did after your session had quietly expired — a save that neither saved nor explained itself. That situation now takes you to the login page instead of leaving you typing into a dead session.

Where: Every sign-out control, and any save made after a session expires.

The opposite problem, and the more disruptive of the two. If the service that checks your login had a bad moment — a restart, a slow reply, a network blip between it and us — the app read that non-answer as a firm "this session is invalid", signed you out, and then remembered that answer for the next five minutes, so signing straight back in did not reliably help. You had done nothing wrong and there was nothing to see; the app simply decided you were logged out.

A check that fails to answer is now treated as exactly that. Your session is left alone, the request is retried a couple of times, and if the problem really persists the app tells you the sign-in service is unavailable instead of quietly logging you out. A genuinely expired or invalid session is unchanged — that still returns you to the login page, as it should.

Where: Anywhere in the app, at any moment — most likely during one of our own updates.

The nightly job that emails trial-ending reminders marked a reminder as sent before confirming it had actually gone out. If it met a momentary conflict — two sweeps touching the same organization's settings at the same instant — the reminder was recorded as sent having delivered zero emails, and every later run then skipped it as already handled. That reminder was lost for good, silently, and the first anyone knew of it was the trial ending unannounced.

A reminder is now only recorded once at least one email has genuinely been delivered, and that step retries rather than giving up on the first conflict. Separately, subscription changes made by our own nightly jobs now reach your billing screens right away instead of after a delay.

Where: Trial-ending reminder emails to organization admins, and billing screens.

A scoring window containing no observations at all showed a blank "QoL —" where the model should have scored it around 29 — Critical. In other words, the animals most in need of someone's attention were exactly the ones showing no score. Those windows now score, and the animal page says plainly when there is genuinely no data yet rather than showing a dash that could mean anything.

Where: The Quality of Life card on animal pages, and any trend built from it.

A cohort set up for dogs offered every species in its Add Animals picker — and if a bird was picked, the server accepted it. The picker now shows only the matching species and says so, and the server refuses a mismatch with a clear message no matter how it arrives.

Where: Cohort pages → Add Animals.

A surprising number of forms closed silently on success: creating a person, creating an assessment, editing an evaluation — and every save on the settings page, whose "Saved." confirmation was being destroyed by the page refreshing underneath it before it could ever appear. All of them now confirm with a small notice. Creating your first animal type was the worst of these: it created the type and then simply sat there, blank; it now returns you to where you started, new type in place.

Where: Settings, people, assessments, evaluations, and animal types.

Reported to us from the floor: a behaviour colour showing None in the list while the Quick Edit for that same animal, opened seconds later, showed a different colour. The two read the animal's colour by different routes, and only one of them needs the colour's name and shade as well as its identity — so a colour code missing either could go blank in the list while the edit form still had it. It appears after an edit rather than on a fresh page, which is what made it look like colours changing on their own.

We found one way this happens and closed it. The list needed a colour's shade as well as its name before it would show anything — and it never actually needed the shade, because it can colour the badge from the name alone. So a colour code missing its shade went blank everywhere it appeared, for a detail nothing was using. That requirement is gone.

Around that, three more changes. The list will no longer answer "None" for an animal that has a colour: where the colour can be identified it is shown, and where it genuinely cannot the badge says "Unknown" instead of claiming there is none — these colours are your caution system, and a confident wrong answer is worse than an honest gap. Beside an "Unknown" badge there is now a small refresh button that reloads that animal for everyone looking at it, not just for you. And a colour code that is somehow missing its name or shade is repaired the moment we see it, rather than waiting for someone to notice.

Separately, every part of a page now agrees about an animal. The summary row, the card header, the card body and Quick Edit each used to fetch their own copy, and those copies could be up to a minute apart in age — so two parts of one screen could genuinely disagree. They now share one, and the newest wins.

One possibility remains open, rarer and harder to catch in the act. This release reports it to us with the record attached the moment it next occurs.

Where: The Behaviour Colour column, and the behaviour badge on animal cards.

When we publish an update — or a connection drops for a moment — a request caught in the wrong instant could fail, and one failed corner of a page replaced the entire app with "Something went wrong". Each section of a page now contains its own trouble: the rest of the page keeps working, the affected section offers a retry, and a page load that was cut off mid-stream quietly retries itself once before bothering you. Underneath that, requests that are safe to repeat are now repeated automatically when the first attempt hits a blip, so most of these moments resolve without you seeing anything at all.

Where: Every dashboard page — most visibly in the minute or two while we publish an update.

Morning rush — several people signing animals in and out at the same time — could push a save past our database's patience and fail it. The time budgets on those operations now match how the database actually behaves under load, pages answer repeated questions from a short-lived cache instead of asking the database twice, and the live board tolerates a large batch of updates without pausing for some viewers.

Where: Sign-in and sign-out under load, and the live list-mode board.

If the network dropped in the exact instant you tapped a link, the tap did nothing at all — no error, no message, nothing moved — leaving you to wonder whether you had really hit it, and often to tap again several times. A navigation that fails now tells you it failed, so trying again is a decision rather than a guess.

Where: Any link inside the app, on a weak connection.

Preparing the offline snapshot is the heaviest single thing the app asks of our database, and it was the last place with no protection against a momentary blip. When one landed, the whole snapshot failed and what reached the device was a raw, unreadable error. It now retries the way the rest of the app does, and if it genuinely cannot finish it says so in plain words.

Where: Preparing offline access on tablets and phones.

If you run a list on a wall-mounted screen, you have been reading a laptop-sized page marooned in the middle of it. On a 4K panel almost two thirds of the screen was empty background, around text sized for somebody sitting two feet away.

Above roughly 1680 pixels the page now widens to use the space, and on genuinely large panels the whole interface — text, spacing, buttons, the sidebar — scales up with the screen rather than staying laptop-sized in the centre of it. Ordinary laptops and monitors are deliberately left alone: the scaling begins above the largest common desktop resolution, so nothing changes for anyone working at a desk. If you have set a larger default text size in your browser, that is still respected and still the starting point.

Where: Every page, on screens larger than a desktop monitor.

The arrow that returns you to the top of a long list sits in the bottom-right corner — and so did every notification the app raises. Two of those never go away on their own (the "update available" prompt and the offline-storage warning), so the arrow could stay covered indefinitely. Notifications now stack above it.

Where: The bottom-right corner of list-mode pages.

The list-mode card tabs pushed the whole page sideways off the edge of a phone screen; table toolbars with more than one button clipped the first and hid the second; and the census flow diagram squeezed its labels into unreadability. The tabs and toolbars now wrap and truncate properly, and at phone widths the census page shows the numbers behind the diagram as a table instead — the diagram remains on anything wider.

Where: List mode, management tables, and the census report on phones.

In dark mode, the confirm button on delete dialogs rendered so washed out it read as disabled — the one button in the app that should never be ambiguous. It is now unmistakably red, everywhere, in both themes.

Where: Every delete confirmation, in dark mode.

"Sync live status" is now "Sync live data", and does what the old name implied: it used to republish only who is signed in and out, so a stale location or behaviour colour could sit on every tablet with nothing in the app able to correct it. It now refreshes both. The user block at the bottom of the sidebar looked like a menu but did nothing — it is now a real menu with account settings and sign out. Location forms offered both "None" and "Level 0 - None" for bio-security — the clear-the-field option is now labelled distinctly. The report animal picker claimed one count while its banner said another — it now tells you the truth ("showing first 500 of 818"). Census diagram labels no longer clip at the card edge. Weights display with sensible decimal places. A wrong address shows a proper page instead of a bare line of text. Report searches no longer re-capitalize the name you typed. And a handful of labels, placeholders, and dialog descriptions now say what is actually true.

Where: Throughout.

When a device has no signal, a sign-in is held on the device and sent to us when it reconnects. The outing itself recorded the right times — but the note and the health reading attached to it were stamped with the moment the device got back online. This was reported to us as a session reading Departed Aug 11 6:34 PM, Returned 6:42 PM sitting directly above a comment card labelled "captured at sign-in" that showed Aug 13 6:48 AM.

The readings mattered more than the mismatched dates did. Fecal, urine and FAS scores are counted by date, so a reading taken on the Monday with no signal was counted on the Wednesday it synced — landing in the wrong day's numbers, and in the wrong week or month of a trend if it crossed a boundary. Both the note and the reading are now recorded against the moment they were taken.

We have corrected the existing records we could. One gap we cannot close: a note or an inline reading recorded offline on its own — rather than as part of a sign-in — has nothing left on it that remembers the original time, so anything already saved that way keeps the date it synced. Everything recorded from this release onward is right.

Where: Sign-in comments and readings, animal comments, and any report or trend that counts evaluations by date.

A reading taken offline was filed under whatever date the device believed it was. A tablet whose clock had drifted badly, or been reset, could therefore file today's reading years in the past — where no report you ever ran would show it again. Readings can now only be backdated by up to a month, so a wrong clock produces a date that looks odd rather than a reading that quietly disappears.

Where: Evaluations recorded offline.

1.0.13 added a repair that runs after each update, bringing the live sign-in/sign-out board back in step for tabs that were left open. In 1.0.14 that repair asked about every organisation in one request and ran out of time before it could finish, so it gave up having done nothing — and a board left open stayed stale until the 4am nightly pass. It now works through one organisation at a time and completes.

The nightly pass had a quieter version of the same problem: if it could not read the list of organisations, it treated that as "there are none" and reported success. It now says so and tries again.

Where: List mode, after we publish an update.

1.0.13 taught the app to refresh itself onto a new version at a safe moment. Watching the first release that used it, all the tablets in a shelter tended to refresh within about a minute and a half of each other, and the live-updates service briefly struggled under everyone reconnecting at once — which showed up as the board pausing for a moment on some devices. The app now spreads those refreshes across about ten minutes instead. You should notice nothing at all, which is the point; if you were watching closely before, the brief pause after an update should be gone.

Where: Every dashboard page, after we publish an update.

If you pressed Save in the seconds while a new version was going live, the page silently reloaded itself. Whatever dialog you had open closed, whatever you had typed was gone, and nothing told you why — it simply looked like the app had jumped. This was the framework's built-in reaction to any server hiccup, and it fired for saves, not just for page navigation. It also hid the problem from us: the failure never reached our error reporting, so a save that vanished this way was invisible on our side. This is fixed. A save that hits a moment of unavailability now shows you an error and leaves your work exactly where it was, so you can press Save again rather than start over.

Where: Every form in the app.

Our servers were being replaced abruptly during an update: any request in flight at that moment was cut off mid-answer, which is what produced "Server Unavailable" while your device was plainly online. Replacement machines were also being given real work before they had finished starting up, so the first few requests after an update could fail even though everything looked healthy. Both are fixed. A server now finishes what it is doing before it steps aside, and a new one only receives traffic once it has genuinely connected to the database. Updates also now run the new version alongside the old one and switch over only when the new one is ready, instead of taking capacity away while the changeover happens.

Where: Everywhere — this is how updates are delivered.

A browser tab that had been open since before an update was still running the old version of the app. When it asked for a piece of the app that no longer existed, it showed "Something went wrong" — and reloading sometimes landed on the same broken state, which is exactly what you reported. The app now recognises this specific situation, waits until the new version is genuinely being served, and refreshes itself. What it means for you: a tab you left open overnight comes back working, without a mysterious error page in between.

Where: Any tab left open across an update.

This is the direct answer to "Reloading doesn't always fix it", which turned out to be the most useful sentence anyone sent us. The app keeps a saved copy of each page so it can work offline. It was giving up on the live version after three seconds and showing you the saved copy instead — and that saved copy could be a day old. So a reload could hand you back the same stale page, over and over, while a hard refresh worked because it skips the saved copy entirely. The app now waits considerably longer for the real page before falling back.

Where: Every dashboard page.

The mechanism that tells your browser a new version exists was checking with a copy of itself, so it always concluded nothing had changed. Every device stayed on whichever version it first installed until something forced it to start fresh — which is a large part of why different people saw different behaviour on the same day, and why some of you were reporting problems we had already fixed. Fixed: your browser now sees new versions and picks them up. As a side effect this also stops the app's saved-page storage growing without limit, which could eventually push out your offline data.

Where: Everywhere.

When a colleague signs an animal in or out, your list updates without you doing anything. That connection has to be re-established whenever we publish an update — and if your tab had been open for more than a few hours, its permission to reconnect had expired, so it was refused. Nothing said so. The board simply kept showing what it had, for as long as the tab stayed open, and only a full reload brought it back. In a shelter that is not a cosmetic problem: two people can take the same animal out, each believing it was available. This is fixed — the connection renews its own permission when it needs to. And because "we fixed the known cause" is not the same as "it can never happen", a Live updates paused indicator now appears in the dashboard header if the live connection genuinely drops, so a stale board never looks like a current one.

Where: List mode and every dashboard page — the live board, notifications, and report progress.

Picking up a new version meant noticing the banner and pressing Refresh, so a tablet left running on a counter could sit on a version from last week — which is part of why some of you were reporting problems we had already fixed. The app now refreshes itself onto a new version, but only at a moment that costs you nothing: never while you are typing, never within a few minutes of your last keystroke, never with a dialog open, and never while work you did offline is being sent. A tab sitting in the background updates quietly. If no safe moment arrives, nothing happens and the Refresh banner simply stays where it is, for you to use when you're ready. What it means for you: the version you're using stops drifting away from the one we're supporting, without anything disappearing from under your hands.

Where: Every dashboard page.

Larger reports are built in the background, which can take minutes. If an update replaced the server midway through, that work stopped — and the page went on showing "Generating your report…" indefinitely, with the Retry button hidden for another half hour. This is fixed: an interrupted report is handed back straight away and can be retried immediately. A second fault found while fixing the first was worse. A server standing down could also fail reports that the replacement servers were generating, so a report that went on to build perfectly well was recorded as failed and its result discarded. That is fixed too — a server now only ever hands back its own work.

Where: Reports.

"Showing cached data captured just now" while everything was up. The app checks every ten seconds whether it can reach us, and a single slow answer was enough to declare the connection dead. That is not a cosmetic problem: it swapped your live list for a saved snapshot and started queueing your sign-ins and sign-outs as if you were offline. The check itself was also far heavier than it needed to be, so it was slow often. Three changes: the check is now much cheaper, it waits longer before giving up, and — most importantly — it takes two failures in a row to conclude anything is wrong, while a single success is enough to recover. The giveaway was in the message itself: "captured just now" meant we had reached the server seconds earlier.

Where: List mode, and anywhere the offline badge appears.

Reported as "easily 1 every 10 seconds". There was meant to be a limit of one such alert every 45 seconds, but the rule had a flaw that exempted the exact pattern it was written for, so the limit never applied when it mattered. It applies now, and the app also stays quiet about recovering from an interruption it never told you about.

Where: The connectivity alerts on every dashboard page.

When your session had quietly expired, the app reported it as "Shelter Sense cannot be reached" rather than asking you to log in again — and, worse, kept accepting your work into a queue that could never be saved. It now recognises an expired session for what it is and prompts you to log back in.

Where: Everywhere.

If an animal was archived on a device that was offline, that action waited in a queue to be sent later. When sending it partly failed, it was queued again to be retried — and if someone had un-archived the animal in the meantime, the retry archived it a second time, using the original date. So an animal a colleague had deliberately brought back into care was quietly archived again, with the wrong date on its stay, and nobody had done anything wrong. This is fixed: a queued archive now recognises that it has already been applied and does nothing on the retry — whether the animal was brought back the same day or a week later.

Where: Archiving an animal, from any device that has been offline.

A new subscription was only set up when your browser returned from the payment page to the confirmation screen. If that return never happened — a closed tab, a dropped connection, a redirect landing in the middle of one of our updates — the card had been charged and no organisation existed, and the only way back was signing in again later and hoping. Payment completion is now reported to us directly, and the organisation is created from that, independently of whether any browser arrives. If both happen at once, they settle on one organisation instead of colliding and showing a payment error for a payment that succeeded.

Where: New subscriptions.

On 11 August a single bug report reached us twenty-five times. That was our fault twice over: the send could fail after the report had already been delivered, so our system kept retrying something that had worked, and the form left your text in place with the button ready — so pressing Send again was the natural thing to do, and each press added more. Reports are now recorded when you submit them and identified by the submission rather than the attempt, so retries and repeat presses land on the same report. Sorry about the noise; it made your actual reports harder for us to pick out, not easier.

Where: Feedback, and the "How is your experience?" prompt.

Reported as: the dialog "popped and then disappeared before I even had a chance to type anything in the box, and I didn't click away from it". It was closing itself in response to anything else happening on the page — and at the time, a connectivity alert was appearing behind it every ten seconds. It now closes only when you close it.

Where: The "How is your experience?" prompt.

Several reports described things we had already fixed, and we had no way to tell whether you were seeing an old version. Reports now carry the version your browser was running and the version our servers were running at that moment. What it means for you: fewer replies asking you to reload and try again, and less chance of us chasing something that was already resolved.

Where: Feedback, and the "How is your experience?" prompt.

That was fair, and the frustration behind it was earned. It is also worth being straight about what was actually happening, because it explains why the same features worked fine one minute and not the next.

Almost everything above only occurs in the few minutes around an update being published, or when a connection is briefly slow. None of it shows up when you run the app and click through it — the tests all passed, and the features genuinely worked. What we were not testing was the transition: the window where a new version is going live while people are mid-task, and the window where a device has an old version loaded and the server has a new one.

Two of these were worse than untested, and they are the ones worth admitting to. The alert-frequency limit had a test named for the exact behaviour it was supposed to guarantee — and the test passed only because of the flaw. And the server's own health check reported "ok" no matter what, so nothing it said could ever have been a warning. A check that cannot fail is not a check.

We have started testing the transition itself rather than only the finished state, and the checks that could not fail have been fixed so that they can.

Where: How we build and ship, rather than any one screen.

Two reports arrived on the morning of August 11:

Here's what was actually happening. The Quick Edit dialog's colour dropdown only knew the colour codes that existed when your page loaded. A colour created after that — exactly what happens while you're setting up colour coding — wasn't in its list, so the dialog silently showed "None" for an animal that really had a colour, and because saving writes the whole form, editing any field then erased the colour for everyone, live. That's why Parrot's white vanished "on its own": a routine quick edit made from a slightly older page was quietly taking it away, and no amount of refreshing brought it back because the saved record itself had lost it. This is fixed the same day it was reported: the dialog now always recognises the animal's real colour, and an untouched field can never erase anything on save. What it means for you: what you see in an edit form is what the animal actually has, and saving one field never destroys another.

Where: List mode Quick Edit, Edit animal. Reported 9:56 AM · fixed and verified end-to-end the same day.

The same flaw existed in sibling forms, with different symptoms: editing a location could silently clear its bio-security level; editing an enrichment session or evaluation for an animal that had since been archived showed a blank "select an animal" and blocked the save; a person's type, an animal's type, or a colour code's animal type could show as unset when the page's lists were older than the record. This is fixed everywhere with one shared rule: an edit form's dropdown always includes the record's current value, even when the page's own list doesn't know it yet. What it means for you: opening an edit form shows the truth, and saving it never quietly discards a value you didn't touch.

Where: Edit location, Edit person, Edit enrichment session, Edit evaluation, Edit colour code, Edit enrichment type, timezone settings.

Dropdowns used to offer only what existed when your page loaded — if a colleague added four new colour codes, your open tab couldn't pick any of them until you reloaded. This is fixed: opening an edit dialog now quietly re-fetches its option lists, so new colours, rooms, and types created anywhere appear in the dropdown within a moment of opening it. If the refresh can't reach the server, the dialog simply keeps the lists it had — nothing breaks offline. What it means for you: you can use reference data your colleagues just created without reloading the page.

Where: Quick Edit, Edit animal, Edit location, Edit person, Edit enrichment session, Edit evaluation, Edit colour code, Edit enrichment type.

If a colleague signed an animal in while you were writing the sign-in note, your text was discarded, and a reload or tab switch lost it too. This is fixed: the note is kept across reloads and tab switches. When the session has already been closed by someone else it can't be filed against it, so it's shown on the card as an Unsaved note you can read and copy until you dismiss it. What it means for you: you don't re-type a note because of what someone else did.

Where: List mode — sign-in / sign-out.

On the list-mode sign-in and sign-out cards, only the comment field used to survive — the scores, ratings, and selections you were entering were lost on a tab switch, a reload, or when the card refreshed because someone else acted on the animal. This is fixed: those fields are kept too. On a shared tablet, un-submitted drafts are cleared at logout so the next person doesn't see them. What it means for you: partly-entered work on a sign-in or sign-out isn't lost when the card changes under you. (Larger forms such as Add animal and New cohort don't keep a draft this way; they warn you before you leave — see below.)

Where: List mode sign-in / sign-out.

A half-completed form was discarded silently on a stray link click, refresh, or tab close. This is fixed: you're asked to confirm before leaving. A successful save (including one queued offline) leaves without a prompt; a failed save keeps your work on screen. What it means for you: you won't lose a form to an accidental navigation.

Where: Add animal, New cohort, New training plan, New evaluation.

An inline evaluation recorded while offline saved only stool, urine, and FAS — weight, behaviour assessment and its reason, appetite, drinking, vomit, and all seven symptom checkboxes were dropped when it synced, even though it reported as saved. This is fixed: every field is saved. What it means for you: an offline evaluation records what you actually entered.

Where: List mode inline evaluations.

Saving an edit to an evaluation cleared every symptom (cough, sneeze, water flip, toys chewed, digging, shredded, and inappropriate elimination) unless you re-ticked them, and editing an enrichment session unlinked the evaluation recorded with it. This is fixed: symptoms are kept on edit, and the session and its evaluation stay linked. What it means for you: editing doesn't quietly erase data.

Where: Evaluations, Enrichment sessions.

A rating added to a comment while offline was lost when it synced, the special-need behaviour form could record a behaviour twice, and syncing the same queued change more than once could create duplicates. This is fixed: the rating is kept, one submit records once, and re-syncing doesn't duplicate. What it means for you: offline ratings survive and you don't get accidental duplicates.

Where: Comments, Behaviours (special needs), offline sync.

Offline changes had no visible queue: a change the server would always reject was retried forever, a conflicting replay was discarded without notice, and logging out could throw away changes you'd queued but not synced. This is fixed: offline changes move through a tracked queue with a Sync issues page where you can see, retry, or discard anything pending; permanently-rejected changes are parked and reported; conflicts are surfaced; and logout keeps unsynced changes. What it means for you: you can see and manage anything waiting to sync, and it isn't lost.

Where: Sync issues page, offline sync.

A brief hiccup while your session was being checked could sign you out mid-task and drop you at the login screen on your next click. This is fixed: a genuinely expired session is handled as its own state, with a clear "log in again" prompt instead of a misleading "offline" message, and a real network drop is no longer mistaken for an expired session. Relatedly, if your session expired while the dashboard was being saved for offline use, the login page could be stored in its place — so going offline later showed a login screen or an error instead of your dashboard. Only a real dashboard page is stored now. What it means for you: you stay signed in through momentary network blips, and what's saved for offline is the page you expect.

Where: Everywhere (connectivity banner and toasts), offline dashboard.

An update that finished downloading in the background was only ever offered at the moment it arrived, so if you missed that one prompt the app stayed on the old version until a hard reload. And the "captured N minutes ago" note on offline data was measured against a fresh fetch while the data itself could come from the previous visit's copy, so the time shown could be wrong. This is fixed: a downloaded update is offered again on your next visit, and the captured time now describes the data you actually have. What it means for you: you're not left behind on an old version, and the offline freshness note can be trusted.

Where: Update prompt, offline data.

Adding an animal — individually or via cohort quick-add, online or offline — could record the arrival a day early on census reports for shelters west of UTC, because the date was read in the server's time rather than yours. This is fixed: the arrival is recorded and shown on the calendar day you chose, in your organization's timezone. What it means for you: intake counts and dates match the day you actually selected.

Where: Add animal, New cohort quick-add, Animal profile, Census report.

Default and custom date ranges could start part-way through the first day and disagree with the range shown, and pickers pre-filled the server's or your device's "today." This is fixed: ranges across reports, statistics, and the animal quality-of-life trend are anchored to your organization's calendar day, and pickers pre-fill your shelter's today. What it means for you: the range you pick is the range that's queried and exported, with no missing partial day.

Where: Reports, Statistics, Animal profile, Medical report, CSV exports.

Assessment-due dates, per-day averages, the summary quality-of-life badge bands, and census length-of-stay could shift with the server clock or a viewer's device. This is fixed: they're all computed in your organization's timezone. What it means for you: these figures are consistent regardless of who's viewing or where the server runs.

Where: Animal profile, Statistics, Census report, list-mode summary.

Saving a colour code, a role's permissions, a comment, an animal type, or a cohort's members could appear to do nothing until you reloaded, and renaming a location, cohort, or bio-security level didn't refresh the animal cards showing it. This is fixed: those changes update the screen immediately. Collapsed animal cards keep up too — name, location and special-need badges update live for everyone in list mode, not only on the expanded card and the summary table, and moving an animal to a new room updates the bio-security badge with it instead of leaving the old room's beside the new name. What it means for you: a save that worked looks like it worked.

Where: Colour codes, User management → Permissions, Comments, Animal types, Cohorts, Animals, list-mode cards.

Opening an edit dialog for one row and saving could overwrite a different row, and Quick Edit could revert a field you'd just changed or drop an animal's existing special needs. This is fixed: edits apply to the row you opened, and Quick Edit keeps your changes and existing special needs. What it means for you: you won't accidentally overwrite the wrong record.

Where: Management tables, Quick Edit.

Some saves write to more than one place — adding an animal records the animal, its room, its cohorts and its shelter id; changing a person's roles removes the old ones and adds the new. Those steps were written separately, so a failure part-way through could leave the work half-applied: an animal on the census without a room, missing cohorts, or an edit that moved a room on the profile but not on the census; a role change that removed a person's old roles without adding the new ones, leaving them with no access at all; and two people saving organization settings at the same time could silently lose one of the changes. This is fixed: each of these saves now applies completely or not at all, and a settings save that collides with someone else's re-reads theirs first instead of overwriting it. What it means for you: a save either happened or it didn't — never half.

Where: Add animal, Animal profile, User management → roles, Global settings.

Opening the profile of an animal currently out in foster or another offsite placement failed to load the header. This is fixed: those profiles load normally. What it means for you: you can open the profile of any animal, including one out in foster.

Where: Animal profile.

"Mark all as read" acted only on the newest rows on screen, so the bell could stay lit when there were older unread items. This is fixed: it uses your true unread count, and rows you've read stay read. What it means for you: you can actually clear the bell.

Where: Notifications.

A save that couldn't reach the server did nothing without explanation, a change queued while the server was unreachable could look "saved," and some "Try again" buttons and controls spun forever or went blank on failure. This is fixed: failed saves show the reason, a queued change is labelled queued rather than saved, and those controls report the problem and recover. What it means for you: you can tell when something failed and why.

Where: All create/edit forms, Reports, animal selector, notifications, training-plan view.

A rejected offline sign-out could show a false success and wipe the fields you'd filled in, and a stale or conflicting offline sign-in could look like a duplicate. This is fixed: a rejected sign-out keeps your entries and reports the problem, and stale or conflicting sign-ins are handled clearly. What it means for you: you get an honest result offline, not a false "done."

Where: List mode sign-out, offline sync.

Some internet-facing screens returned data on membership alone — animal details (including clinical evaluations and training-plan content), the user roster, the permission matrix, cohort rosters, and reference-data lists — and report results weren't scoped to the requester. This is fixed: each is gated by the matching read permission (the sidebar still shows the link, but the data is withheld), and report results are scoped to the requester so private comments can't leak across roles. The Add animal form's dropdown lists — types, locations, colour codes, special needs, cohorts, bio-security levels, intake types — follow the permission to add animals, on both the animals screen and list mode. Separately, a list-mode settings lookup identified a record by an id supplied in the request without checking it belonged to your organization, so a member of one organization could read another's animal-type settings by id; every such lookup is now scoped to your organization first. What it means for you: role permissions are enforced on the data itself, not just the menu, and one organization's records cannot be reached from another's.

Where: Animal profile, User management (roster & Permissions), Cohorts, reference-data lists, Add animal, Reports.

Delete buttons for animals and comments were shown to admins regardless of the delete permission, and the Add Person button showed to roles that can't create people. This is fixed: those controls follow the specific permission, and People now have their own permission resource. What it means for you: the buttons you see match what your role can actually do.

Where: Animals, Comments, People, User management → Permissions.

The real-time updates behind list-mode cards weren't cryptographically scoped to an organization. This is fixed: they're protected by a signed, per-organization token. What it means for you: one organization's live activity cannot reach another's screens.

Where: List mode (live cards).

Rich-text content wasn't fully cleaned before display (a cross-site-scripting risk), spreadsheet cells starting with certain characters could be interpreted as formulas in Excel, and an unexpected error could show internal database or server detail. This is fixed: content is sanitized before display, export cells are neutralized so they're treated as text, and errors show a generic message. What it means for you: your data and exports are safer to open and share.

Where: Comments and notes, CSV exports, everywhere errors surface.

You could accidentally remove or demote the last admin of an organization, the billing portal and checkout didn't fully confirm identity and permission from your session, a failed live payment-status check could lock a whole organization out, and a session stayed valid briefly after logout. This is fixed: the last admin is protected, billing actions confirm your identity and billing permission, a failed status check no longer locks you out, logout invalidates the session immediately, and making changes now requires an active subscription — uniformly, across everything: adding, editing, or removing records; signing animals in and out; and logging comments, evaluations, or enrichment. If a subscription lapses the workspace becomes read-only until it's renewed; only the billing and account actions needed to fix the plan stay available (and a super-admin helping you is never blocked). What it means for you: no patchwork where some changes are allowed and others aren't — either the plan is active and everything works, or it's lapsed and you renew to continue.

Where: User management, Billing, sign-out.

Some CSV downloads showed accented names, en dashes, and curly apostrophes as garbled characters in Excel. This is fixed: exports carry the correct encoding, and every entered value is escaped safely. What it means for you: exported reports are readable in Excel without cleanup.

Where: All CSV exports (statistics, enrichment, census).

Some report and statistics screens loaded and iterated whole animal sets on common paths, which was slow for large shelters, and background reports (large selections) could notify twice, miss a completion, or fail to recover from a step. This is fixed: those screens avoid the whole-set work, and background reports notify once, guard against duplicate or lost completion, and recover from a failed step. What it means for you: reports are quicker on large shelters and background reports finish reliably.

Where: Reports, Statistics.

The session-distribution heatmap could render its least-active cells indistinguishably from empty ones, and animal photos were served at full size. This is fixed: low-activity cells stay visible, and photos are served at display size. What it means for you: the heatmap is readable and cards and lists load lighter.

Where: Statistics heatmap, Animals, list mode.

Text on several tables, chips, tooltips, and other surfaces was hard to read in dark mode because it used light-mode colours. This is fixed: those surfaces use the correct dark colours. What it means for you: dark mode is legible across those screens.

Where: Multiple screens in dark mode.

Some controls — list-mode form controls, notification rows, the sign-in Session Rating, the heatmap cells, and the summary-row "scroll to card" action — lacked names or roles or couldn't be used by keyboard, and focus could be lost when a control was briefly disabled during a save. This is fixed: those controls have proper names and roles, work by keyboard, and keep focus. What it means for you: the app is usable with a keyboard and screen reader in those places.

Where: List mode, Notifications, Statistics, sign-in.

The default Volunteer role couldn't read evaluations. This is changed: Volunteers can read evaluations, with raw evaluation access tied to the quality-of-life read permission. What it means for you: volunteers can see evaluation information relevant to their work.

Where: Evaluations, User management → Permissions.

Adding animals through a cohort's quick-add couldn't set an intake type, unlike the single add-animal form. This is fixed: you can set the intake type for the batch. What it means for you: cohort-added animals get the same intake information as individually-added ones.

Where: New cohort quick-add.

A trial invitation could be accepted more than once, and a reminder could be marked "sent" even if the email failed. This is fixed: an invitation is single-use, and a reminder is recorded only after the email is actually sent. What it means for you: no duplicate trial provisioning and no "reminder sent" without an email.

Where: Trials / onboarding, reminder emails.

Clearing a role's description silently kept the old text; training-plan content was validated only on create; a plan and its animal flag could be created separately; updating the behaviours linked to a special need failed with a generic error when several were selected; evaluation score fields (behaviour assessment, stool) weren't held to the same valid range on create and edit, and an out-of-range value submitted from outside the browser wasn't rejected; multi-word animal-type names didn't open or link correctly; deleting an enrichment session didn't warn that its note and assessment go with it; a paginated table could strand you on a blank page; and a failing sidebar widget could crash the whole app. All are fixed. What it means for you: these smaller rough edges behave as expected.

Where: User management → Permissions, Training plans, Special needs, Evaluations, Animal types, Enrichment sessions, management tables, Dashboard.

Create and edit forms are held to the same validation and error-reporting contract, with automated checks so they can't drift apart again; date handling across the app is guarded against a class of timezone mistakes; dark-mode text colours now come from one shared token rather than a pairing copied to every element; spreadsheet exports and rich-text previews each go through a single shared routine; per-organization data is kept separate in caches; and release tagging, background email delivery, and developer tooling were made more reliable. The security and framework checks that back these now run automatically on every build, not just on request. None of these change what you do in the app.