Vendor Status Watch

← all vendors

SugarSync status history

Current state: operational — “All Systems Operational” per https://status.sugarsync.com (Atlassian Statuspage), checked 2026-09-16 12:28 UTC.

2incidents, last 30 days
2incidents, last 90 days
6incidents on record
Incidents per week, last 12 weeks:
Get SugarSync alerts in your Slack — free templateRSS for SugarSync

How long do SugarSync incidents last?

13.9 hmedian incident duration6 measured
37.9 h90th percentile1 in 10 ran longer
29.5 hmedian, major/critical only2 incidents

From 6 incidents with a vendor-posted start and resolve time. Longest on record: Login / Access Degradation — 2.3 days (2026-09-08 15:05 UTC). Excluded, never estimated: nothing. Duration is the gap between the vendor's own posted timestamps — it is not measured downtime, uptime or an SLA figure, and a vendor that posts every blip will look worse here than one that posts nothing. Same rule as the outage-duration dataset.

Incidents on record (6)

StartedIncidentStatusImpactDuration
2026-09-08 15:05 UTCLogin / Access Degradationresolvednone2 d 6 h
2026-08-26 16:30 UTCSupport limited due to network maintenanceresolvednone1 h 02 min
2026-04-15 17:11 UTCLogin and connectivity issuesresolvedcritical21 h 06 min
2026-04-12 00:57 UTCLogin and connectivity issuesresolvedcritical37 h 53 min
2026-04-08 19:29 UTCEmail Message Delaysresolvedminor4 h 34 min
2025-11-18 14:46 UTCServices affected due to Cloudflare outageresolvednone6 h 45 min

Titles, statuses and impact levels are the vendor's own words. Durations marked approx. are inferred from the poll that first found the incident gone. Shows the latest 60; the JSON has everything we hold (up to 400 days).

Watch SugarSync with the template

Put this in config.json of your fork and add a WEBHOOK_URL secret:

{
  "vendors": [
    "sugarsync"
  ],
  "format": "auto",
  "map_url": "https://raw.githubusercontent.com/APVentureEngine/vendor-status-watch/main/vendors.json",
  "unreachable_after": 3,
  "mute_maintenance": false
}