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.

We’ve updated the feature to support uploading AT-HM expense items in bulk. This enhancement helps providers manage high-volume AT-HM records more efficiently and ensures correct mapping of the new AT-HM fields required under Support at Home.

This update is available now under:

The Expenses Bulk Import template has been extended to include all AT-HM-related fields. You can now bulk upload AT-HM items with full classification and linkage to the required AT-HM attributes.

These fields ensure AT-HM expenses are imported with the correct structure, enabling accurate claiming, reporting, and compliance.

These enhancements reduce manual entry and improve data consistency across AT-HM records, particularly important as providers transition to Support at Home and manage higher volumes of AT-HM activity.

Refer to the updated guide in the Support at Home Knowledge Hub, or contact Support or your Customer Success Manager for assistance.

The NDIA has released an update to the Pricing Arrangements and Price Limits.

Visualcare has updated the pricing catalogue to reflect the new prices, effective 24 November 2025.

The updated catalogue is now available for bulk upload.

You can access it from: and apply the latest pricing in your environment.

More information on how to do this can be found in vDocs: Update NDIS Pricing.

We’ve improved the Expenses → Import CSV feature to make bulk expense uploads more accurate and efficient.

Go to and select from the dropdown.

When preparing your CSV, simply enter the Visualcare for each expense in the new column. The system will attach the correct service to the expense during upload , ensuring accurate claiming and reporting.