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.

We’ve released several key updates to support the process and .

To prepare for Support at Home, providers must register for the so Visualcare can securely from Services Australia. This is a critical step before claims can be made under the new program.

You can now complete all Step 4 setup tasks directly in Visualcare, including:

Users with or permissions who manage PRODA or government integrations.

We’ve added the ability to bulk create Agreements directly from your Client List.

Providers need a fast way to set up SAH agreements at scale. This update lets you create agreement “shells” in bulk and link services.

Starting from the view, you can:

Go to , to .

Then, to add services via .

Users with permission to view/edit client profiles and create agreements.