Salesforce logged three separate incidents on 29 September 2026, touching Log Center, Data Cloud streaming ingestion and MuleSoft features across a dozen PODs and instances. The longest ran 2 hours 24 minutes. All three were on Salesforce's side of the fence.
Started
02:46 UTC
Duration
Lasted 24m
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.
Affected components: JPN2S, JPN4S, USA1, USA2S, USA3S, BRA2S, BRA4S, JPN6S, JPN8S, JPN10S, JPN12S, USA8S, USA20S, USA22S, USA26, JPN18S, JPN20S, JPN22S, JPN24S, JPN28S, BRA6S, BRA8S, USA34, USA36, USA28S, USA30S, USA32S, USA60S, USA62S, BRA14, BRA16, BRA18, JPN132, JPN134, JPN136, JPN138, JPN140, JPN142, USA220, USA224S, USA226, USA228, USA230, USA232, USA234, USA236, USA238, USA240S, USA242S, USA244S, USA248S, USA250S, USA252S, USA254S, USA256S, USA258S, USA260S, USA262S, USA268S, USA270S, USA272, USA274, USA276, USA278, USA280, USA282, USA286, USA288, USA290, USA292, USA294, USA296, USA300, USA302, USA304, USA312, USA314, USA316, USA318, USA320, USA322, USA324, USA326, USA328, USA330, USA332, USA334, USA336, USA338, USA340, USA342, USA344, USA346, USA348, USA350, USA352, USA354, USA356, USA358, USA360, USA364, USA366S, USA372, USA374, USA376, USA384, USA408, USA410, USA412, USA414, USA416, USA418, USA420, USA422, USA424, USA426, USA428, USA430, USA432S, USA434S, USA436, USA438, USA440, USA442, USA444, USA446S, USA448S, USA450, USA452, USA454, USA456, USA460, USA462, USA464, USA466, USA468, USA470, USA472, USA474, USA476, USA478, USA480, USA488S, USA490S, USA80S, BRA24, BRA28, BRA30, BRA32, BRA34, BRA36, BRA38, BRA44, BRA48, BRA50, BRA54S, JPN144, JPN146, USA202S, USA494, USA496, USA534S, USA538, USA540S, USA542S, USA544, USA546, USA548, USA550, USA552, USA554, USA556, USA558, USA560, USA562, USA564, USA566, USA568, USA570, USA572, USA574, USA576, USA578, USA580, USA582, USA584, USA586, USA588, USA590, USA592, USA594, USA596, USA598, USA600, USA602, USA604, USA606, USA608, USA610, USA612, USA614, USA616, USA618, USA620, USA622, USA624, USA626, USA628, USA630, USA632, USA634, USA636, USA638, USA640, USA642, USA644, USA646, USA648, USA650, USA652, USA654S, USA656S, USA658S, USA660S, USA662S, USA664S, USA666S, USA668S, USA670S, USA672S, USA674, USA676, USA678, USA680, USA682, USA684, USA686, USA688, USA690, USA692, USA694, USA696, USA698, USA700, USA702, USA704, USA706, USA708, USA856, USA870S, USA872S, USA874S, USA876, USA880S, USA882S, USA884S, USA886S, USA888S, USA890S, USA892S, USA894S, USA896S, USA898S, USA900S, USA902S, POD257, POD267, POD295
What happened?
The day opened at 02:46 UTC with a MuleSoft Feature Disruption lasting 24 minutes, logged with no further updates from Salesforce. At 05:38 UTC a Feature Degradation incident began, running 2 hours 24 minutes and affecting Log Center on a subset of PODs. Salesforce's own updates say the impact actually began at 02:36 UTC, earlier than the incident's logged start, and that customers could lose application, deployment and Ecom logs, which in turn hits log monitoring, alerting and third-party log streaming. Salesforce ruled out a planned application update as the cause and instead pointed to the log collection component itself, which it restarted instance by instance while continuing to flag and check others caught by its monitoring. A third incident, a Performance Degradation, started at 21:27 UTC and ran 2 hours 21 minutes, hitting Data Cloud streaming ingestion through the Ingestion API, Web and Mobile Connector, and MCP Connector. Salesforce traced this to service startup failures, tried a rollback in one environment first to validate it, then manually increased capacity while it worked out why services weren't scaling automatically. Midway through, Salesforce filed an impact radius increase, admitting the problem reached more instances than first stated. The affected component list spans POD257, POD267, POD295, several Japan and USA instances (JPN2S, JPN4S, USA1, USA2S, USA3S), and Brazil instances BRA2S and BRA4S, out of 268 components tracked that day. One user report landed in the window: a United States user at 13:09 UTC reported "saying username and password incorrect when it's saved", during the gap between the second and third incidents. No post-mortem has been published for any of the three incidents.
Learning
This is a layered-services outage, not a front-door one: Log Center and Data Cloud ingestion sit behind Salesforce's main login and UI, so a synthetic check hitting the login page or a core API endpoint would likely have stayed green while logging and data ingestion quietly failed underneath. Salesforce's own restart-and-validate language for Log Center, and its rollback-then-capacity-increase approach for Data Cloud, show the fault lived in backend components you don't control and can't directly probe from your own product. Your uptime monitor watching your integration endpoints is checking whether your calls succeed, which is a different question from whether Salesforce's internal pipeline is healthy. In the 90 days before this, Salesforce logged 127 incidents with a median duration of 2 hours 31 minutes, so an incident lasting a couple of hours sits squarely in its normal pattern rather than being unusual. Over the same recent window, UptimeRobot's own checks recorded 39 incidents with 37 resolved and a median duration of 3h 17m, a reminder that provider-side problems routinely outlast what a quick glance at a status page would suggest. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
