This release introduces Pay Cat Connect, an integration that brings automated SCHADS Award interpretation into your rostering and payroll. Pay Cat handles the award interpretation, and Visualcare gives your rostering and payroll teams the cost visibility to act on it.

Pay Cat Connect adds two capabilities, depending on your plan.

See the real-time SCHADS cost of a shift while you are still on the client roster. When you assign a worker and interpret the shift, Pay Cat looks across the whole pay period, so if that worker has already picked up hours elsewhere, you see the overtime, broken shift or minimum engagement impact before you finalise the roster, not after payroll has run.

Send approved timesheets to Pay Cat, review the interpreted costing grouped by worker, then export the costed payroll to Xero or MYOB.

Pay Cat's SCHADS Award interpretation has been independently audited by Effective HR and legally certified by SLF Lawyers, so your teams are working from award logic that has been verified by HR and legal specialists.

Pay Cat Connect replaces the legacy vAir interpretation and covers the full SCHADS Award, a significant upgrade on what vAir could do.

Want it switched on? Reach out to your customer success manager.

We have updated the NDIS Support Catalogue in Visualcare ahead of the annual NDIS support price changes that apply from 1 July 2026.

The updated NDIS Support Catalogue is now available in Visualcare. It reflects the 2026-27 NDIS pricing schedule released on 22 June 2026.

Your existing pricing will not change automatically. Once you are ready, you can update your NDIS pricing by following the steps in our guide:

We recommend applying the update so your pricing is ready to go from 1 July 2026.

If you have any questions or need help with the update, please reach out to our support team. We are happy to help.

Our second June release is now live with fixes for several issues affecting the Support at Home Dashboard, Statements, Invoicing, Worker Timeline, and Documents.

Our first June release is now live with fixes for two issues that have been affecting statements and the Support at Home Dashboard.

Fixed an issue where participant statements showed incorrect figures for clients with Home Care Package (HCP) or Commonwealth Unspent Funds (CUF) utilisation. In the Ongoing summary, the utilised amount was being incorrectly deducted from the available budget rather than added to it, causing the remaining balance to appear lower than it should be. Statements will now calculate and display the correct figures.

Fixed an issue where March statements (and later months) were not appearing in the Support at Home Dashboard for some providers, even when the statements had been successfully generated. These are now visible as expected.

Our latest release is now live. This one is heavily focused on Support at Home statement reliability and invoicing workflow improvements, along with a handful of platform usability fixes that have been on the list for a while.

We've resolved several statement issues that have been causing pain across a number of customers.

May 19, 2026

09:10 - 16:30 AEST

Visualcare web application (app.visualcare.com.au)

At approximately 09:10 AEST, customers began reporting that the Visualcare web application had become slow and unresponsive. Investigation identified that the primary web application server had entered a degraded state after running under sustained high CPU load for approximately two weeks.

During the incident, a series of unhandled application errors caused PHP-FPM worker threads to hang, resulting in elevated CPU utilisation on the primary server. The degradation became severe enough that AWS was unable to successfully reboot the instance remotely.

Engineering worked to restore service by reintroducing a previous web server and later deploying a new replacement server behind the load balancer. While these actions partially restored access for many customers, additional routing inconsistencies were identified where some customer domains bypassed the load balancer entirely and pointed directly to the failed server. This caused continued intermittent failures for affected customers until those paths were identified and corrected.

The incident was fully stabilised after the temporary replacement environment was removed and routing behaviour was normalised.

Elevated utilisation. See the healthier utilisation following remediation actions outlined in red.

Administrators across multiple providers experienced significant slowness, intermittent failures, and periods where the Visualcare web application was unavailable during the incident window.

Worker and Participant access through the Visualcare mobile applications was unaffected.

No data loss or compromise occurred during the incident.

On May 19, a series of unhandled application errors triggered a condition where PHP-FPM worker threads became stuck and did not recover correctly. As the number of hung workers increased, CPU utilisation escalated, resulting in the server becoming unresponsive to both application traffic and infrastructure management operations.

Because some customer domains were configured to bypass the load balancer and point directly to the affected server, those customers continued experiencing failures even after alternate infrastructure was introduced.

Attempts to restore service using both a previous server and a newly provisioned server improved availability for many customers but introduced secondary issues, including SSL/SNI mismatches and login instability, which prolonged the incident duration.

Engineering restored partial service by temporarily reintroducing a previous web application server into the load balancer, followed by deployment of a newly provisioned replacement server.

During investigation, it was discovered that some customer domain configurations bypassed the load balancer entirely. These configurations were corrected so traffic could route through the intended infrastructure path.

The affected server was ultimately isolated from production traffic while further remediation and stability work continued.

13 May 2026

16:30 – 17:10 AEST

Visualcare web application (app.visualcare.com.au)

Following a scheduled deployment at approximately 16:30 on 13 May 2026, users began experiencing login failures on the Visualcare web application (app.visualcare.com.au). During the deployment process, a file intended for the API component was inadvertently deployed to the web application, overwriting an existing file of the same name (functions.php) that serves a different purpose within the web app. This caused the login authentication step to fail, preventing users from accessing the application.

Engineers responded immediately and began investigating the issue by tracing the path of the login error. Through this analysis, they identified that functions.php on the web application had been replaced with an incorrect version during the deployment. Once identified, the correct version of the file was restored from version control and redeployed to the web application, resolving the issue at 17:10.

During the incident window (16:30–17:10 on 13 May 2026), users were unable to log in to the Visualcare web application (app.visualcare.com.au). No other systems were impacted, for example vWorker remained fully operationally during the outage.

During the 13 May 2026 deployment, the wrong source folder was selected, resulting in the API version of functions.php being uploaded to the web application server instead of the correct web application version. Both components contain a file with the same name; this was not immediately apparent during transfer and led to the web application’s authentication failing.

The issue was resolved by restoring the correct version of functions.php from version control and uploading it to the web application server. Following the fix, the deployment was re-executed using the correct source folder to ensure all intended updates were applied to the appropriate servers.

Our May release is now live, and you should notice less friction across the parts of SAH you use most:

We've released a substantial update to how filters, search, sorting and pagination behave across SAH pages.

We've made several improvements to make the invoicing workflow more reliable.

This release addresses accuracy and usability across the claiming workflow.

See full list of improvements here.

May 1, 2026

07:30 - 10:25 AEST

VisualCare web application (app.visualcare.com.au)

At approximately 7:30 AEST, some providers experienced intermittent issues connecting to the Visualcare web application. Worker and Participant access was not affected through Visualcare mobile applications, as those users connect through a separate domain.

Investigation identified that affected administrators’ browsers were holding outdated connection information that pointed to a web server which was no longer available. We adjusted the underlying configuration to prevent recurrence and worked with our customer teams to guide impacted administrators through a quick browser refresh to restore access.

Administrators across some providers were intermittently unable to access the Visualcare web application (app.visualcare.com.au) during the incident window. Worker and Participant access was unaffected, and no data was lost or compromised. Once administrators completed a browser refresh, access was fully restored.

The Visualcare web application uses load balancers to distribute administrator traffic across multiple web servers. To keep each administrator’s session consistent, browsers temporarily remember which web server they’re connected to.

Overnight, one of those web servers became unavailable. Because the browser-side connection information was set to refresh once per day rather than more frequently, some administrators’ browsers continued attempting to reach the unavailable server instead of being routed to a healthy one. This is what caused the intermittent connection failures.

We are taking action to address this with improved infrastructure. (See Follow-Up Actions).

To restore access, affected administrators needed to refresh their browser’s connection information. Depending on the browser, this was achieved by a hard refresh, clearing the browser cache, or opening the application in a private/incognito window.

To prevent recurrence with the existing infrastructure, we shortened the refresh interval on the underlying configuration so that any future change to a web server is picked up by browsers within minutes rather than up to a day.

Audit related configuration to confirm appropriate refresh intervals are in place across the platform.

Containerise the Visualcare web application and API into a new production environment (already scheduled for next week). This work removes the dependency on the load balancing pattern that caused this incident, meaning this class of issue cannot occur in the new environment.

Continue investing in platform monitoring and resilience to detect and prevent issues of this nature earlier.

29 April 2026

10:20 - 15:35 AEST

Database cluster, downstream application services

At approximately 10:20 AEST, the system experienced a rapid spike in database connections, leading to resource exhaustion and degraded application performance. A failover at 10:40 temporarily alleviated the issue.

A second, more severe spike occurred at 14:00, again resulting in database exhaustion. Investigation identified a recently released query related to Commonwealth Unspent Funds as the root cause. The query was executing at high volume due to backlog processing and contained inefficient subqueries.

A hotfix was deployed at 15:35, resolving the issue.

A query introduced last week for Support At Home contained two unbounded subqueries.This resulted in:

The issue was triggered by a backlog of statements queries which resulted in an increase in database connections and subsequent exhaustion.

The incident was caused by a query design that resulted in large backlog processing. When triggered at scale, it resulted in database load and connection exhaustion. Improvements are required in query design standards, load validation, and bulk processing controls.

Last year Visualcare kicked off an infrastructure upgrade. Key updates include containerisation and database sharding. In recent months we have been piloting this with a key partner to assess performance and reliability. This pilot has been successful and is being pushed live in early May. Once complete we will be rolling out these improvements to support improved reliability and performance.

The duration of incidents within the last 30 days has resulted in an uptime of 99.2%.