Square had two separate service disruptions on 4 November 2026, one starting at 19:27 UTC and lasting 1h 28m, another starting at 21:22 UTC and lasting 1h 13m. Both were on Square's side, affecting payment acceptance, orders and e-money transactions.
Started
19:27 UTC
Duration
Lasted 1h 28m
Source
IsDown
Next time
Square 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?
Square's status page logged two incidents on this day, both titled "Service Disruption". The first began at 19:27 UTC, with Square saying it was "experiencing a disruption that is impacting some Square services". Four minutes later, at 19:31 UTC, Square said it had "released a fix for Payment Acceptance and Orders" and was seeing services return to functionality. That incident ran for 1h 28m in total. The second incident started at 21:22 UTC, this time described as impacting "some e-money transactions". Square did not post another update until 22:17 UTC, when it said a fix had been released for e-money payment processing. That second incident lasted 1h 13m. No components list was published alongside either incident, so there is no breakdown of which specific systems beyond payments, orders and e-money were touched. No user reports were filed during either window. Square has not published any post-mortem for either incident, and neither update explains what caused the disruption. Over the past 90 days Square has logged 20 incidents with a median duration of 1 hour 9 minutes, so two incidents on one day sits above that typical pace, though both individual durations are in a similar range to the historical median.
Learning
UptimeRobot's own 30 day data shows 5 incidents for Square, all resolved, with a median duration of 1h 28m, a figure that lines up closely with what Square itself reported for the first incident of the day. This matters because a provider's own status page is the only place an outage like this gets recorded. If you were watching your own Square integration endpoints from outside, a disruption affecting payment acceptance, orders or e-money processing inside Square's infrastructure would not necessarily show up as your endpoint going down. It would show up as failed or slow transactions passing through, which can look like your own code at first glance. That is the general shape of this kind of failure: your service calls out to Square, Square's internal processing stalls, and the symptom lands on your side even though the fault sits upstream. Checking your own uptime tells you your half is fine. It does not tell you whether Square's payment processing is degraded underneath you. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
