Salesforce's MuleSoft Anypoint Platform blocked single sign-on logins for 1h 20m on 28 September. The fault sat with Salesforce, tied to a recent change on their side, and you could do nothing on your end to work around it.
Started
09:14 UTC
Duration
Lasted 1h 20m
Source
IsDown
Next time
Salesforce is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
What happened?
Salesforce logged one incident on 28 September 2026, starting at 09:14 UTC and running for 1h 20m. The problem hit single sign-on logins to Anypoint Platform, part of MuleSoft. Salesforce's first update at 09:24 said customers logging in via SSO could not authenticate if their organisation's stored Identity Provider signing certificate was not formatted as Privacy-Enhanced Mail. They identified this as the result of a recent change and said it affected anyone using SSO login platform-wide. People already logged in were not affected and would not lose access, according to Salesforce. At 09:57 they said a rollback was in progress for one region and they were checking whether it resolved the issue. At 10:18 they confirmed the US region rollback was complete without errors, with other regions still in progress and expected to finish within 60 minutes. No further update is shown beyond that point, and the incident is recorded as lasting 1h 20m in total. Salesforce listed no specific components as affected in the public record. No user reports were filed during this window, so there is no independent account to compare against Salesforce's own description. Over the past 90 days Salesforce has logged 127 incidents with a median duration of 2 hours 31 minutes, which puts this one below that median.
Learning
This incident sat entirely in Salesforce's authentication layer, specifically in how Anypoint Platform validated stored identity provider certificates during login. If your own uptime checks hit your application and not Salesforce's SSO endpoint directly, they would have stayed green while new logins failed, because your probes were testing your half of the connection, not the identity provider handshake happening on Salesforce's side. That is a normal split, not a flaw in either check. Anyone already signed in kept working, per Salesforce's own updates, so the failure was narrow: new authentications only, tied to a certificate format mismatch following a change on their end. The pattern worth remembering is that login failures can originate upstream of your product entirely, in a vendor's identity layer, and no amount of monitoring your own servers reveals that. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
