Square had a service disruption lasting 1h 47m starting at 04:08 UTC. The fault affected payment authorisation, refunds, tip adjustments, KDS delivery and printing, and it was Square's own systems, not yours.
Started
04:08 UTC
Duration
Lasted 1h 47m
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 one incident on 27 September 2026, starting at 04:08 UTC and running for 1h 47m. The only update posted came at the start time, under the status "monitoring", and no further update followed before the incident closed out the window. That single update describes widespread elevated latency and service errors across Square, affecting Payment Authorization, Refunds, Tip Adjustments, KDS delivery, and Printing. It also notes that Dashboard reporting was delayed, and that Tip Adjustments specifically were degraded but could be retried for up to 36 hours after payment capture. Square's own wording says services "largely recovered" by the time of that post, with residual errors continuing in the listed components. No component list with individual statuses was published separately, so you only have Square's prose description to go on. No user reports were filed during this window, so there is no independent account of what merchants actually experienced at the terminal or dashboard level. Square has not published a post-mortem for this incident, so the cause is not on the record. In the 90 days before this, Square logged 21 incidents with a median duration of 1 hour 9 minutes, which puts this one above that typical length.
Learning
If you run a business on Square, this incident sits in the payment processing layer itself, specifically authorisation, refunds, and tip handling, which is not something your own endpoint checks would ever see. Monitoring your own storefront or app can stay green the entire time because your code is fine, while the calls you make out to Square's authorisation service are the part that is actually failing or slow. That is the shape to recognise: your product looks up, your revenue does not move, and the two facts do not contradict each other. Square's own figures put this incident's length above the typical 90-day median for them, so it was a longer than usual stretch where card transactions, tips, and KDS delivery to kitchens could have been lagging or erroring in retry loops. With no user reports filed and no post-mortem, you are relying entirely on Square's own account of its own system, which is worth remembering when you judge how bad it actually was on the ground. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
