Hint Health Outage History

This incident has been resolved.

Between 09:52 PT and 10:18 PT, our authentication vendor experienced an issue that resulted in errors during login attempts as well as session refreshes. As a result, customers were unable to sign in or continue using the app once their session tokens expired after the standard 15-minute window. At 10:18 PT, our vendor deployed a fix that restored normal authentication functionality. We are working with the vendor to understand the root cause and will provide a detailed update shortly on our status page.

Between 08:15 ET and 10:50 ET today, a subset of authentication edge servers maintained by our vendor in the Chicago region began returning errors. During this window, customers routed to one of these faulty nodes were unable to sign in or continue using the app—their session tokens failed to refresh after the standard 15-minute window. We estimate fewer than 200 users—primarily in Missouri, Wisconsin, Iowa, Indiana, Michigan, and Illinois—were affected. At 10:50 ET, we deployed a fix to restore full service. Monitoring confirms all authentication services are now operating normally. We apologize for the disruption and are working with our vendor to enhance fail-over and token-refresh resilience across their edge clusters.

During a recent release aimed at performance improvement, we observed an unexpected disruption at 10:56 AM PT. Active users with expired authentication tokens were affected and redirected to a 401 error page, temporarily limiting their ability to use our app. This issue was an unintended side effect of the new release, which inadvertently overlooked the automatic refresh of expired tokens for these users. Our team has since addressed and rectified this problem by 11:23 AM PST.

Our automated systems detected an issue that impacted our login system at around 5:00am PST, this corresponds to an incident impacting our Authentication vendor with their hosting provider Microsoft Azure which confirmed the issue had been resolved at 12:45pm PST. For information about the incident from our vendor, FrontEgg, please see their incident report https://status.frontegg.com/incidents/gyfgn2hzwdv2

Our automated systems detected an issue that impacted our login system at around 1:40am PST lasting for about 27 minutes. This corresponds to an incident impacting our Authentication vendor at the same time. Impact on customers is unclear as there were no error logs or customer reported issues during this time. For information about the incident from our vendor, FrontEgg, please see their incident report https://status.frontegg.com/incidents/y4rt16yjv7fd

A production release last week (week of 6/24) introduced a change that negatively impacted performance when loading the application. For at least 2 users this caused the application to fail to load at least once. This slow performance was detected by our automated monitoring over the weekend and our engineers investigated the issue but did not identify the root cause. This (Monday) morning the root cause was determine fix was deployed by 6:52am. We've started a RCA and post-mortem, which includes adding automated checks on the performance of the key API endpoints that were impacted.

At 2:38 AM PST (on May 22) our Mailgun account was enabled again. New emails after that point where delivered right away and emails that failed to send while the account was disabled where retried successfully by our team. We continue to work on adding a secondary email provider as backup.