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%.

On 16 March, 23 March, 9 April and 10 April (outlined in red in the L90 image below), vCore and other services experienced performance degradation, including elevated response times.

Despite normal CPU utilisation on the database (~50%) and healthy API indicators, the system exhibited:

A controlled restored system performance, resulting in the best observed performance baseline in recent periods.

The graph above shows the last 90 days of concurrent database connections. It can be seen that spikes in connection count increased gradually until hitting a critical point mid-last-week which caused a feedback loop of sustained connections, resulting in the performance degradation. Note the total flatline of connections at the far right of the graph (outlined in green), indicating that connections are not piling up and that the failover solution has eliminated stale resources and contentions.

Previous performance issues (notably Monday the 16th and Monday the 23rd of April) are also outlined in red.

(note: AWS metrics were wiped on failover. The latency and load peaks shown above represent the average load for the previous 2 days)

Elevated response times reported via application monitoring

The system entered a degraded state characterised by , despite moderate resource utilisation.

Investigation revealed:

Although indexing improvements were applied, the database remained in a degraded state due to .

A failover reset:

This immediately restored normal performance.

A high-frequency database update query executed without an appropriate index, resulting in:

No alerting on:

Issue was detected only after user-visible degradation

Although the triggering query targeted a specific table, the impact was systemic due to:

Immediate mitigation achieved via:

Performance returned to baseline immediately after failover

Confirm all high-frequency queries are properly indexed

Enable and review slow query logging (lower threshold temporarily)

Monitor and alert on:

Add visibility into connection counts and states

Review connection management strategy (reduce long-lived connections where possible)

Add dashboards for:

● Evaluate architectural changes to reduce high-frequency write contention

● Introduce backpressure or rate limiting on heavy write paths

● Consider read/write isolation improvements or workload partitioning

● Formalise database failover as a controlled operational response (not primary mitigation)

This incident was caused by a combination of:

No single action or individual directly caused the incident.

The system behaved in line with its current design and constraints.

* An Outage indicates that the system was completely inaccessible. Performance Degradation indicates that while the system was slow, it was still accessible and most work could be done, albeit at a less efficient rate.

The duration of actual outages within the last 90 days results in an uptime of 99.86%

On Monday 16 March 2026, Visualcare experienced a major service disruption affecting API availability.

The incident was triggered by inefficient database query behaviour within a background worker process responsible for form-related data processing. This resulted in a surge of long-running queries that exhausted available database connections.

As database resources became constrained, API requests were unable to complete, leading to application worker saturation and instability across API nodes, causing significant slowdowns and incomplete queries in both the Visualcare Web Application and Worker Mobile App.

While initial mitigation actions restored partial functionality, the underlying database pressure persisted, resulting in repeated instability until a controlled recovery was completed.

Service access was fully restored at ~13:11 AEST at a reduced speed and the system resumed to normal behaviour at ~14:22 AEST as database pressure subsided.

A background worker responsible for processing form data executed queries that scaled poorly under certain data conditions, resulting in significantly longer execution times than expected.

As these queries accumulated:

This, combined with elevated system load at the time, accelerated database resource exhaustion, resulting in request backlogs, application worker saturation, and progressive service degradation.

As API nodes became increasingly unstable, overall platform performance deteriorated significantly. Requests were delayed or failed as application processes remained blocked waiting for database access.

Initial recovery actions (traffic redistribution and application restarts) provided only temporary relief, as they did not address the underlying database load:

The worker process continued generating high database activity

Resource contention rapidly reoccurred after each recovery attempt

This resulted in a , significantly extending the duration of the incident

The issue was initially identified through customer reports, followed by internal validation of:

At the time of the incident, there were limited proactive alerts for:

Service was restored through:

Once database pressure was reduced and application services stabilised, normal service resumed.

Inefficient database query behaviour in a background worker process led to sustained resource consumption, exhausting database connections and causing cascading failure across API services.

We are implementing several improvements to prevent recurrence and strengthen system resilience:

We recognise the impact this incident had and take full responsibility for the disruption.

This event has led to clear improvements in how we:

These changes are already planned and underway to ensure a more resilient and reliable platform moving forward.

On 12 January 2026, Visualcare experienced a Priority 0 (P0) service incident affecting the Mobile API and related services. The incident was triggered by a sudden and sustained surge of external request traffic, which placed unexpected pressure on backend systems and led to service unavailability.

Core services were restored by 1:35pm AEDT, with degraded performance continuing until 2:25pm AEDT, after which normal service levels were fully re-established.

During the incident window:

There was no data loss, no unauthorised access, and no impact to data integrity.

The incident was caused by a rapid increase in external request volume directed at the Mobile API. The traffic pattern resulted in a significantly higher number of concurrent requests than typically observed.

As request volume increased, backend processing slowed, and active requests accumulated faster than they could be completed. This led to temporary resource saturation and prevented the system from efficiently accepting or completing new requests.

An initial service restart did not immediately restore normal service. Additional controls were subsequently applied to support stable request handling during high traffic conditions, after which the system recovered.

The issue was detected through a combination of:

The incident was escalated and formally declared a P0 once widespread impact was confirmed.

Service recovery occurred in two phases:

A sudden and sustained surge of external requests placed unexpected load on the Mobile API, leading to temporary saturation of request processing capacity. This prevented the system from handling new requests efficiently until traffic was regulated and services were stabilised.

To reduce the risk and impact of similar events in the future, we are implementing the following improvements:

These actions are actively being tracked through our internal delivery process.

We recognise the operational impact this incident may have caused and appreciate your patience.

Visualcare continues to invest in platform resilience and protection to ensure reliable service, even during abnormal traffic conditions.

If you have any questions or would like further clarification, please contact your Customer Success Manager, or the Head of Customer Success, Maddie Hayes (mhayes@visualcare.com.au).

We’ve released the first version of in Visualcare, including options. This update also introduces new settings for SAH claiming configuration and user-level permissions.

This release supports providers preparing for their first Support at Home claim and introduces the foundational claiming workflow, aligned to the Aged Care Web Services requirements.

A new claiming area is now available:

This workspace allows you to:

Supported statuses include:

This workflow differs from HCP processes. We strongly recommend familiarising yourself with the new screens and statuses before submitting your first SAH claim.

A new configuration area is available to set your claiming rules:

You can now configure:

A new permission setting has been added to control who can access SAH Claiming:

This allows you to limit SAH claiming to specific roles such as finance, coordinators, or administrators.

SAH Claiming - Timesheets > SAH Claiming

SAH Claim Settings - Settings > Integrations

User Access Control - Settings > User Group Security

Refer to the Support at Home Knowledge Hub for detailed guidance, examples, and setup instructions.

For configuration support or assistance validating your first SAH claim, please contact Support or your Customer Success Manager.