Core Practice Outage History

Started Oct 29, 2026, 10:45 PM UTC· resolved Oct 30, 2026, 12:25 AM UTC

1. investigating Oct 29, 2026, 10:45 PM UTC

   Our phone support line is currently experiencing issues due to an outage at our telephony provider. You may be unable to get through, calls may drop, or you may not reach an agent. Our live chat and web support channels are unaffected and operating as normal. Please contact us through either of these and our team will help you as usual. We’re monitoring the provider’s progress and will update this page once phone support is restored. The Core Practice application itself is not affected.

2. investigating Oct 29, 2026, 10:47 PM UTC

   We are continuing to investigate this issue.

3. monitoring Oct 29, 2026, 11:29 PM UTC

   Our telephony provider has implemented a fix and phone support has been restored. We’re monitoring to make sure service stays stable. If you called during the disruption and couldn’t get through, or your call dropped, please try again or reach us via live chat or web support.

4. resolved Oct 30, 2026, 12:25 AM UTC

   This incident is resolved. Our telephony provider has confirmed their outage is fixed and phone support is working normally again. Thank you for your patience.

Read the full incident report →

Started Apr 28, 2026, 11:12 PM UTC· resolved Apr 29, 2026, 08:23 AM UTC

1. investigating Apr 28, 2026, 11:12 PM UTC

   We are aware of an issue with generating invoices and are currently investigating. We apologise for the inconvenience and will provide an update in 15 mins.

2. identified Apr 28, 2026, 11:31 PM UTC

   We have identified a permission issue that is affecting a number of users. A hotfix is currently being prepared, and we will have a further update in the next 15mins.

3. identified Apr 28, 2026, 11:50 PM UTC

   We are continuing to work on the hotfix for the permission issue affecting invoice generation. Our development team has identified the root cause and the fix is currently being prepared and tested before deployment. We will provide a further update in 30 minutes, or sooner if the hotfix is ready to deploy. We appreciate your patience while we work to resolve this.

4. identified Apr 29, 2026, 12:25 AM UTC

   The hotfix for the permission issue affecting invoice generation has been completed and is now being packaged for deployment. We will provide a further update once deployment is underway, or within 30 minutes — whichever is sooner. We appreciate your patience while we work to resolve this.

5. identified Apr 29, 2026, 01:27 AM UTC

   Apologies for the delay in this update. The hotfix has been completed and is currently undergoing final testing before deployment. We will provide a further update once deployment begins. We appreciate your patience while we work to resolve this

6. identified Apr 29, 2026, 02:10 AM UTC

   The hotfix has completed testing and is scheduled for deployment between 12:30pm and 1:00pm AEST. Users may experience brief intermittent slowness during the window. We will provide a further update once deployment is complete and the fix has been verified. We appreciate your patience while we work to resolve this.

7. monitoring Apr 29, 2026, 03:11 AM UTC

   The hotfix has been deployed. We are now monitoring the system to confirm the issue is fully resolved. Users should now be able to generate invoices as normal. If you continue to experience issues, please contact support. We will provide a further update shortly to confirm full resolution.

8. resolved Apr 29, 2026, 08:23 AM UTC

   Summary: Between 07:00 AEST and 13:00 AEST, a number of users were unexpectedly logged out when attempting to generate invoices. The issue was caused by a regression in the most recent application release. A hotfix was deployed between 12:30pm and 1:00pm AEST and testing confirmed users are no longer being logged out. We will continue to monitor closely. Investigation: Telemetry indicated a consistent pattern of authorisation failures on an endpoint called during the invoice generation workflow. Further review identified that recent changes were causing some users to be logged out when this response was received, rather than handling it gracefully. Next Steps: The hotfix has corrected the client-side handling of these responses. Some users may need to refresh their browser to receive the updated application files. A problem ticket has been raised to review our pre-release testing process, specifically to ensure least-privileged user scenarios are covered in regression testing for permission-sensitive workflows. We apologise for the inconvenience caused and thank affected users for their patience.

Read the full incident report →

Started Mar 05, 2026, 05:37 AM UTC· resolved Mar 05, 2026, 07:12 AM UTC

1. investigating Mar 05, 2026, 05:37 AM UTC

   We are currently investigating elevated CPU utilisation on some instances, which may cause intermittent slowness for some users. Our team is monitoring the situation and working to stabilise performance. We will provide further updates as more information becomes available.

2. investigating Mar 05, 2026, 05:58 AM UTC

   The performance issue has now subsided and system performance has returned to normal levels. Our team will continue to monitor the platform closely to ensure ongoing stability. We apologise for the inconvenience and appreciate your patience.

3. monitoring Mar 05, 2026, 06:01 AM UTC

   The earlier performance degradation has now stabilised and services are operating normally. Our team will continue monitoring the environment to ensure stability. We apologise for any inconvenience caused and appreciate your patience.

4. resolved Mar 05, 2026, 07:12 AM UTC

   Summary: Between 16:20 and 16:45, we experienced elevated CPU utilisation across multiple instances, which caused intermittent slowness for some users. The affected servers have since stabilised and were progressively returned to the pool, with all instances restored by approximately 17:20. Investigation: Initial monitoring through DataDog did not show a common request pattern across the affected servers. Further review of instance logs indicates a consistent sequence of events: spikes in network traffic → RAM saturation → CPU spikes. Next Steps: A detailed log analysis is currently underway to determine the root cause. A problem ticket has been raised to track the investigation and any corrective actions. We apologise for any inconvenience caused and will continue to monitor system performance closely.

Read the full incident report →

Started Feb 25, 2026, 12:42 AM UTC· resolved Feb 25, 2026, 06:10 AM UTC

1. investigating Feb 25, 2026, 12:42 AM UTC

   We are aware of a current issue that is partially affecting system performance. Some users may experience intermittent slowness, while other areas of the platform remain fully operational. Our technical team is actively investigating the cause and working to restore full performance as quickly as possible. We are closely monitoring the situation and prioritising resolution. We will provide a further update once the issue has been resolved or if there are any significant developments.

2. identified Feb 25, 2026, 01:34 AM UTC

   We have provisioned additional servers to stabilise system performance while our investigation continues. We are currently observing recovery in server load levels and overall response times are improving. Our team will continue to closely monitor the environment to ensure stability is maintained. Further updates will be provided as necessary.

3. investigating Feb 25, 2026, 01:34 AM UTC

   We are currently investigating this issue.

4. monitoring Feb 25, 2026, 02:10 AM UTC

   Server performance has returned to normal levels and services are operating as expected. We will continue to monitor the system closely to ensure ongoing stability.

5. resolved Feb 25, 2026, 06:10 AM UTC

   Between 10:55am and 12:05pm 25/02/2026, we saw resource spikes on some of our front end instances. The issue has been resolved, additional servers were provisioned to stabilise performance and server load has returned to normal levels. Response times are back to expected benchmarks. Root cause investigation is ongoing. A post-incident report will be published once completed.

Read the full incident report →

Started Feb 04, 2026, 05:06 AM UTC· resolved Feb 05, 2026, 10:46 PM UTC

1. identified Feb 04, 2026, 05:06 AM UTC

   Identified We are aware of an issue impacting inbound SMS messages for a subset of Australian phone numbers. Core Practice uses Twilio as our SMS delivery provider. Twilio has confirmed an incident on their platform where some inbound SMS messages are not being received. Their engineering team has identified the cause and is actively working on deploying a fix. Impact Inbound SMS replies may be delayed or not received for some Australian numbers. We are monitoring the situation closely and will provide further updates as more information becomes available from Twilio.

2. identified Feb 04, 2026, 10:43 PM UTC

   Twilio has confirmed they have identified the cause of the issue impacting inbound SMS messages for a subset of Australian phone numbers and are continuing to deploy a fix. Inbound SMS replies may still be delayed or not received for some numbers at this time. Outbound SMS messages continue to send as expected. Twilio expects to provide another update within 24 hours, or sooner if additional information becomes available. We will continue to monitor the situation closely and share further updates as they are provided.

3. monitoring Feb 05, 2026, 04:49 AM UTC

   Twilio has advised they are seeing recovery for the issue impacting inbound SMS messages for a subset of Australian phone numbers. Inbound SMS replies may now be successfully received, however some delays may still occur while full recovery is confirmed. Outbound SMS messages continue to send as expected. We will continue to monitor the situation closely and will provide another update within 2 hours, or sooner if more information becomes available.

4. resolved Feb 05, 2026, 10:46 PM UTC

   Twilio has confirmed the issue impacting inbound SMS messages for a subset of Australian phone numbers has been resolved. We are no longer seeing delivery issues and inbound SMS messages are functioning as expected. Outbound SMS messages were not impacted during this incident. We will continue to monitor, but no further action is required at this time.

Read the full incident report →

Started Feb 02, 2026, 09:59 PM UTC· resolved Feb 03, 2026, 12:48 AM UTC

1. identified Feb 02, 2026, 09:59 PM UTC

   We are currently investigating reports of slow system performance impacting some users. Our team is working to identify the cause and restore normal performance as quickly as possible. We will provide further updates as they become available.

2. identified Feb 02, 2026, 10:43 PM UTC

   We are currently investigating an issue with our service provider, Microsoft Azure. The issue is causing virtual machines (VMs) across multiple regions to fail to start. Our team is working with Azure to resolve this as quickly as possible. We will provide further updates as more information becomes available. https://azure.status.microsoft/en-us/status

3. identified Feb 02, 2026, 10:59 PM UTC

   We’ve identified the issue and initiated an emergency response to manually override the VM health state reported by Azure. This forces the VM into a healthy state while Microsoft Azure resolves an issue causing false error notifications. We will continue investigating the root cause and will provide a resolution summary once available. The system is now gradually returning to normal operational state. More info: https://azure.status.microsoft/en-us/status

4. resolved Feb 03, 2026, 12:48 AM UTC

   Resolution Summary We sincerely apologise for the inconvenience caused. This incident resulted from a sequence of compounding events that amplified the impact and extended the resolution time longer than expected. Our emergency response processes were initiated, however, due to external factors, they did not function as effectively as intended. For full transparency, please see the details below. Overview Between 8:00am and 9:50am AEST on 2 February 2026, Core Practice experienced a performance degradation due to a failure in the VM Autoscale automation capability. As a result, newly created virtual machines were unable to successfully install startup configurations, causing them to report an unhealthy state. This led to reduced VM capacity across the platform. 8:34am AEST, We became aware of the issue following customer reports of system slowness. 8:42am AEST, Our engineering team initiated emergency procedures to manually override VM configurations and restore individual virtual machines to a healthy state. In parallel, a separate team began provisioning a new VM pool to restore capacity. 9:15am AEST, We identified ongoing service issues reported by our service provider, Microsoft Azure. Relevant incidents published on the Azure Status page included: https://azure.status.microsoft/en-us/status 19:46 UTC, 2 February 2026 – Incorrect notifications during VM management operations 00:02 UTC, 3 February 2026 – Issues related to storage accounts and host extension packages Issue Amplification The incident was further compounded by Azure reporting incorrect VM health and provisioning states. While engineers were manually overriding configuration files, Azure Monitoring continued to display affected VMs as unhealthy. Under normal circumstances, these VMs should have reported a healthy status. This misleading information diverted engineering efforts toward investigating additional, non-existent issues. 9:40am AEST, We confirmed that the manually overridden VMs were operating correctly and that the primary remaining issue was inaccurate health and provisioning status reporting within Azure Monitoring. Engineers promptly updated the configurations on the remaining VMs to restore full system functionality. 9:50am AEST All systems were fully restored and operating normally. Root Cause The root cause of this incident was an ongoing service issue within Microsoft Azure that affected storage accounts used by VM custom extension packages. These storage accounts are required during VM provisioning to startup configuration routine. This issue was further exacerbated by Azure reporting incorrect VM health and provisioning states, which delayed identification of the true operational status of affected virtual machines. Next Steps We sincerely apologise for the impact this incident had on affected customers. We are continuing to work closely with Microsoft Azure to: Improve the reliability and accuracy of health and provisioning state reporting. Improve our emergency response notification and procedures. Investigate architectural improvements to increase system resiliency and automation to reduce resolution time for future incidents.

Read the full incident report →

Started Jan 15, 2026, 12:05 AM UTC· resolved Jan 15, 2026, 06:10 AM UTC

1. investigating Jan 15, 2026, 12:05 AM UTC

   We are currently investigating reports of slow system performance impacting some users. Our team is working to identify the cause and restore normal performance as quickly as possible. We will provide further updates as they become available.

2. investigating Jan 15, 2026, 12:05 AM UTC

   We are continuing to investigate this issue.

3. identified Jan 15, 2026, 12:13 AM UTC

   We have identified the affected server and removed it from the pool to reduce impact while we continue to investigate the root cause. Further updates will be provided as available.

4. monitoring Jan 15, 2026, 01:28 AM UTC

   CPU usage has stabalised on our web front-end servers and performance has returned to normal. We are continuing to monitor closely.

5. monitoring Jan 15, 2026, 01:46 AM UTC

   We are observing a CPU usage spike on a different server and are continuing to monitor the situation closely. Further updates will be provided as they become available.

6. monitoring Jan 15, 2026, 04:25 AM UTC

   CPU usage has remained stable across all servers over a sustained period. We will continue to monitor closely and provide further updates as needed.

7. resolved Jan 15, 2026, 06:10 AM UTC

   Summary: Between 10:20am - 10:45am and 12:35pm-12:50pm some of our web servers experienced an application process hang, causing health probe failures and degraded performance for a subset of requests. The affected servers were removed from the pool, and traffic continued to be served by the remaining healthy instances. Impact: Some users may have experienced slow response times or brief connection delays during the incident window Resolution: An additional server was provisioned to provide extra capacity while the affected servers were restored to the load balancer pool. All servers are now operating normally. Next Steps: We are continuing to investigate the root cause, which appears related to memory pressure during a period of high concurrent activity. Additional monitoring has been implemented, and we will provide a full post-incident report once the investigation is complete. Current Status: All systems operating normally.

Read the full incident report →

Started Nov 18, 2025, 01:00 PM UTC· resolved Nov 18, 2025, 03:00 PM UTC

1. resolved Nov 18, 2025, 12:00 PM UTC

   Summary Our web application experienced connectivity issues on November 18, 2025 11:00pm - November 19 02:00am (AEST) due to a widespread Cloudflare outage affecting multiple services globally. Service was restored once Cloudflare resolved the issue. Root Cause Third-party service provider (Cloudflare) experienced a global outage impacting DNS and CDN services. Resolution Cloudflare resolved the outage on their infrastructure. All services have been restored to normal operation. Next Steps We continue to monitor service stability and are reviewing our DNS redundancy strategies. We apologise for any inconvenience and thank you for your patience.

Read the full incident report →

Started Nov 16, 2025, 11:03 PM UTC· resolved Nov 17, 2025, 06:30 AM UTC

1. investigating Nov 16, 2025, 11:03 PM UTC

   We are currently experiencing high CPU utilisation on one of our Webset 1 hosts, which may cause performance issues for some users. Our team is investigating and actively working to restore normal performance. Further updates will be provided as soon as they are available.

2. investigating Nov 16, 2025, 11:06 PM UTC

   An additional server has been added to the pool while the investigation continues. CPU levels have returned to normal and performance has stabilised. We will continue to monitor the environment and provide further updates if required.

3. resolved Nov 17, 2025, 06:30 AM UTC

   Summary Our web application experienced performance issues on November 17, 2025 between 09:50 AM and 10:10 AM AEDT, due to elevated CPU usage caused by a surge in connection traffic. Users may have experienced slow page loads and connection timeouts during this period. Root Cause A surge in SignalR reconnection attempts created elevated CPU load on our web servers, leading to degraded application performance. Resolution Our team increased the number of servers to handle the traffic spike. System performance has been restored to normal levels. Next Steps We'll continue monitoring for these connection patterns, and infrastructure scaling adjustments to prevent similar issues in the future and further optimise traffic. We apologise for any inconvenience and thank you for your patience.

Read the full incident report →

Started Aug 12, 2025, 04:39 AM UTC· resolved Aug 12, 2025, 12:23 PM UTC

1. identified Aug 12, 2025, 04:39 AM UTC

   Summary of impact: SMS templates are not populating in the dropdown menu when configuring Batch SMS Reminders for calendar locations where no default template has been previously set. Locations with existing default templates are unaffected. Root Cause: Issue introduced in the most recent application update. Next Steps: Development team is currently working on a hotfix to resolve the dropdown population issue. Timeline for deployment will be communicated once testing is complete. Mitigation: Immediate workaround available: Users can resolve this by navigating to Locations > Site Administration > Settings menu and selecting a default template for the affected location. Once set, Batch SMS Reminder configuration will function normally.

2. resolved Aug 12, 2025, 12:23 PM UTC

   We sincerely apologize for the inconvenience caused to affected customers. Our investigations have been completed, and a hotfix has been deployed to resolve the issue. Templates should now be loading as expected.

Read the full incident report →

Started Aug 01, 2025, 07:41 AM UTC· resolved Aug 01, 2025, 08:45 AM UTC

1. investigating Aug 01, 2025, 07:41 AM UTC

   We are currently monitoring an outage affecting Fort Awesome, causing icon packages (eg. tabs on patient profiles) to fail to load. We'll provide further updates as more information becomes available.

2. resolved Aug 01, 2025, 08:45 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 23, 2025, 11:50 PM UTC· resolved Mar 24, 2025, 06:32 AM UTC

1. identified Mar 23, 2025, 11:50 PM UTC

   We are investigating a server performance issue related to CPU spikes and are adding an additional servers to handle the requests. Users may experience temporary slowness over the next few minutes.

2. monitoring Mar 24, 2025, 12:18 AM UTC

   Additional servers have been successfully added to the pool to handle the load spikes. Users should now experience normal operation. We apologise for any inconvenience caused during this period of degraded performance. Our team will continue to closely monitor the system as we investigate the root cause of the spikes

3. resolved Mar 24, 2025, 06:32 AM UTC

   The incident has now been resolved, and we sincerely apologise for any disruption caused to affected customers. We will continue to review the situation to find ways to strengthen our system’s resilience and prevent similar issues from occurring in the future. Summary Our web application experienced performance issues on March 23, 2025 between 10:30am and 10:51am, due to memory issues on some of our servers. Extra instances were deployed as cover while we investigated the cause. Root Cause Memory constraints on specific instances affected server resources, leading to slow performance. Resolution We added three extra instances to improve capacity and distribution of load while addressing the underlying memory issues. Next Steps We'll implement improved monitoring and review resource allocation to prevent similar issues in the future. We apologise for any inconvenience and thank you for your patience.

Read the full incident report →

Started Jan 13, 2025, 10:01 PM UTC· resolved Jan 13, 2025, 10:19 PM UTC

1. investigating Jan 13, 2025, 10:01 PM UTC

   We are investigating reports users are experiencing degraded performance, you may experience slow response times when accessing Core Practice. We apologise for the delays and will provide an update in 15 minutes.

2. identified Jan 13, 2025, 10:17 PM UTC

   A manual fix has been successfully implemented and system performance is now returning to normal levels. We apologise for any inconvenience caused during this period of degraded performance. Our team will continue to monitor the system closely while we investigate the root cause.

3. resolved Jan 13, 2025, 10:19 PM UTC

   This incident has been resolved. We sincerely apologize for the impact to affected customers. Investigations have assessed the best ways to improve architectural resiliency and mitigate the issues that contributed to this incident and its widespread impact.

Read the full incident report →