We are actively investigating this issue, subscribe and stay tuned for updates.

Based on our investigation, there were two aspects in this incident

• Ops reported an increase in 460 Errors and a low recovery rate after retries.

• Slowness in the UI that allows manual retries.

For point 1, we verified all components in our system, and all are working as expected with no errors (Note: error 460 is from ClaimMD and doesn't depend on our payload; it's "try later"). But we identified some settings adjustments that can improve the success rate: 1st: increase waits between batches, 2nd: improve scheduled retries for Monday and Tuesday. For point 2, we created these two linear tickets https://linear.app/paradigmseniors/issue/RCM-919/improve-performance-for-eligibility-benefits-page-by-adding-indexes & https://linear.app/paradigmseniors/issue/RCM-920/improve-performance-for-eligibility-benefits-page RCM-919 is already DONE, and RCM-920 is in Triage.

Causes: Instability in the HSRM website, a 1-hour hard limit of session time, and a high volume of providers associated with Nicole's acc. Investigation was done in: https://linear.app/paradigmseniors/issue/RCM-807/investigate-timeout-when-clicking-on-providers-details (more details of other incidents related to the instability of the hsrm website in the slack channel https://careswitch.slack.com/archives/C09P1NUHG1Z) Steps to resolve: Initial mitigation: https://linear.app/paradigmseniors/issue/RCM-830/allow-human-intervention-to-do-a-manual-filter-of-the-auths-before-rpa RCM-813/allow-the-bot-to-scrape-a-past-date-range https://linear.app/paradigmseniors/issue/RCM-832/deploy-the-bot-in-an-ops-machine-and-train-the-operator-to-execute-it Then continue with a broader plan to return the bot to the cloud with minimal human attention (ideally 0) and the highest possible success rate. The details of the plan are in linear tasks.

This issue in under investigation. I'm gathering info from the stakeholder to understand better the issue reported