APProjects commited on
Commit
a95de33
·
verified ·
1 Parent(s): 47d4c50

site refresh

Browse files
This view is limited to 50 files because it contains too many changes.   See raw diff
.deploy-probe DELETED
@@ -1 +0,0 @@
1
- 2026-09-04T10:06:03Z
 
 
api/snapshot.json CHANGED
The diff for this file is too large to render. See raw diff
 
api/v/1password.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "1password",
4
  "platform": "statuspage",
5
  "status_url": "https://1password.statuspage.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "A fix has been deployed and this issue is now resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-07-22T15:20:54.949-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-22T13:55:18.026-04:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-07-17T14:57:38.340-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-17T14:52:15.282-04:00",
@@ -38,7 +38,7 @@
38
  "body": "A fix has been deployed and this issue is now resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-07-13T15:57:14.635-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-13T14:59:33.940-04:00",
@@ -51,7 +51,7 @@
51
  "body": "A fix for this issue has been implemented, and our teams are monitoring. During the outage, GitHub Actions might have failed to pull the latest CLI version, causing the pipeline to fail.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-13T10:30:00.000-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-13T10:30:00.000-04:00",
@@ -64,7 +64,7 @@
64
  "body": "# Incident Postmortem - Device Trust Authentication Outage\n\n**Date of Incident:** 2026-07-02 \n**Time of Incident \\(UTC\\):** 19:28 - 20:28 \n**Service\\(s\\) Affected:** This incident affected: USA/Global \\(Device Trust Authentication Service, Device Trust Checks Server, Device Trust Portal, Device Trust API\\) and Europe \\(Device Trust Authentication Service, Device Trust Checks Server, Device Trust Portal, Device Trust API\\). \n**Impact Duration:** 1 Hour\n\n## Summary\n\nOn July 2, 2026, 1Password Device Trust experienced an outage lasting approximately one hour, beginning at 19:28 UTC. During this window, all Device Trust services were unavailable and users were unable to authenticate. We have identified the root cause: an internal configuration change to our cloud load balancing infrastructure was applied more broadly than intended which temporarily made a required endpoint unreachable. This was not a security incident and did not involve any third party. The configuration has been corrected, service has been fully restored, and we have implemented additional safeguards to help prevent this type of issue from recurring.\n\n## Impact on Customers\n\n* **All Device Trust services were completely unavailable during the 60-minute outage window. Users were unable to authenticate to any Device Trust service, including the authentication portal \\(**[**auth.kolide.com**](http://auth.kolide.com)**\\), admin console \\(**[**app.kolide.com**](http://app.kolide.com)**\\), API endpoints, and device server.**\n* **Number of Affected Customers \\(approximate\\):** 100% of Device Trust customers\n* **Geographic Regions Affected \\(if applicable\\):** US and EU\n\n## What Happened?\n\nOn July 2, 2026, A configuration change intended to improve the security configuration of an internal service was applied more broadly than intended, affecting a shared network routing component relied on by Device Trust. The change replaced the underlying network infrastructure supporting Device Trust. However, the traffic routing configuration continued to reference the previous infrastructure instead of the newly provisioned resources. As a result, Device Trust authentication endpoints became unreachable. Reverting the change restored connectivity and service.\n\n* **Timeline of Events \\(UTC\\):**\n\n * 19:28: Network configuration change applied; Network Load Balancers responsible for routing traffic for Device Trust services became unreachable\n * 19:30: Automated monitoring detects the outage and triggers alerts\n * 19:33: Incident is declared at [status.1password.com](http://status.1password.com)\n * 20:03: Root cause is identified as a load balancer configuration issue\n * 20:24: Load balancer is recreated with correct configuration\n * 20:26 Recovery is confirmed for [app.kolide.com](http://app.kolide.com)\n * 20:28 Recovery is confirmed for [auth.kolide.com](http://auth.kolide.com)\n \n* **Contributing Factors \\(if any\\):**\n\n * **Shared component scope not visible during review or validation.** The network infrastructure class affected by the change was shared across multiple services, but this dependency was not documented or surfaced in the change review process. As a result, the pre-production validation, while performed in a lower environment before production rollout, did not cover all dependent services, and the impact on Device Trust was not identified before the change reached production.\n * **Concurrent diagnostic signals slowed root cause identification.** At the time the outage began, unrelated certificate renewal errors surfaced alongside the network connectivity failure. Investigating both signals simultaneously delayed identification of the network configuration change as the root cause.\n \n\n## How Was It Resolved?\n\n* **Resolution Steps:** Once the source of the outage was identified, engineers reverted the configuration change. The affected network infrastructure was recreated with its original, publicly accessible configuration, restoring routing to all Device Trust authentication endpoints. Service recovery was confirmed sequentially across affected services before the incident was closed.\n* **Verification of Resolution:** Following the revert, engineers verified that all Device Trust authentication endpoints were reachable and accepting traffic. Customer confirmation of resolution was subsequently received through the support team.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Require explicit approval for destructive infrastructure changes.** We are implementing safeguards that require manual review and approval before changes that would destroy and recreate critical network infrastructure can be applied. This creates a forcing function to catch unintended scope before changes reach production.\n* **Improve scope visibility for shared infrastructure components.** We are documenting the dependencies between shared infrastructure components and the services that rely on them, and integrating this information into our change review process. Future changes to shared components will require an explicit assessment of downstream impact before deployment.\n* **Strengthen pre-production validation across shared dependencies.** We are updating our change promotion process to require validation against all services that share affected components \u2014 not only the intended target \u2014 before changes are promoted to production.\n* **Reduce single points of failure in traffic routing.** We are evaluating architectural changes to introduce redundancy into Device Trust's traffic routing configuration, so that a failure in any single component results in degraded service rather than a complete outage.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "critical",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-02T16:30:48.837-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-02T15:44:00.651-04:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-06-30T10:09:25.287-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-29T18:08:19.241-04:00",
@@ -90,7 +90,7 @@
90
  "body": "The issue is now resolved, and access to 1Password services should be fully restored.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-06-24T15:01:46.148-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-24T13:15:10.565-04:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-06-18T14:50:42.250-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-18T13:54:11.964-04:00",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-06-17T12:00:17.093-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-16T12:24:03.697-04:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-06-12T19:18:57.981-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-11T17:49:05.374-04:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-05-16T16:36:03.709-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-16T11:51:33.535-04:00",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-05-04T14:34:49.601-04:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-04T13:59:28.385-04:00",
@@ -168,7 +168,7 @@
168
  "body": "# Incident Postmortem - Login and Sync Issues\n\n**Date of Incident:** 2026-04-27 \n**Time of Incident \\(UTC\\):** 14:15 - 15:41 \n**Service\\(s\\) Affected:** All web APIs \n**Impact Duration:** Approximately 86 minutes\n\n## Summary\n\nOn April 27, 2026, [1Password.com](http://1password.com/) experienced a period of elevated error and full service unavailability in our USA/Global region. A defect deployed in application scaling logic caused a cascading failure during peak usage. This resulted in a period of service unavailability for customers in the USA/Global region.\n\nThis was not a security incident, and there was no loss of data.\n\n## Impact on Customers\n\n* **Sign-in and account access:** Customers in the USA/Global region experienced errors or were unable to sign in or access their 1Password accounts between approximately 14:15 and 15:41 UTC on April 27, 2026.\n* **All 1Password clients:** The disruption applied to all client types, including the web app, CLI, browser extensions, and desktop and mobile applications, for customers connecting through the USA/Global region.\n* **Geographic regions affected:** Only customers on the USA/Global region were affected. Other regions were not impacted.\n\n## What Happened?\n\nWe deployed a change to how our services signal their readiness to serve requests, which contained a latent defect.\n\n* **Timeline of events:**\n\n * **2026-04-27 14:15 UTC** - Load increase triggers issues.\n * **2026-04-27 14:29 UTC** - Incident declared; response team mobilized.\n * **2026-04-27 15:41 UTC** - Issue identified and fix deployed.\n * **2026-04-28 18:06 UTC** - Incident formally resolved following monitoring.\n \n\n## How Was It Resolved?\n\nOur on-call engineering team identified the scaling logic as the cause of the cascading failure and disabled it via a configuration change. Once disabled, capacity was restored, and traffic recovered. A subsequent configuration change was made to prevent this logic from being re-enabled in production environments.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Immediate fix:** We disabled the defective health check logic and locked the configuration to prevent it from being re-enabled in production.\n* **Retrospective:** We are conducting a full retrospective with the incident responders to identify further improvements to our systems and our response processes.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your patience and understanding.\n\nSincerely,\n\nThe 1Password Team",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-04-28T14:00:34.801-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-27T10:54:26.804-04:00",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-04-22T12:06:19.982-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-22T11:18:52.323-04:00",
@@ -194,7 +194,7 @@
194
  "body": "# 2026-04-14 SEV1 Incident Postmortem - Hosted Service in the US experiencing high latency and errors\n\n# Incident Postmortem - Elevated Application Error\n\n**Date of Incident:** 2026-04-14 \n**Time of Incident \\(UTC\\):** 17:25 - 18:00 \n**Service\\(s\\) Affected:** Sign in, Admin console \n**Impact Duration:** Approximately 35 minutes\n\n## Summary\n\nOn April 14, 2026, [1Password.com](http://1Password.com) experienced elevated error rates due to an increase in traffic to our USA/Global infrastructure. Requests arrived more quickly than they could be serviced in our USA/global region. Customers experienced errors and high latency.\n\nThis was not a security incident, and there was no loss of data.\n\n## Impact on Customers\n\n* **Sign-in and account access:**\u00a0Some customers in the USA/Global region experienced errors when attempting to sign in or access their 1Password accounts between 17:25 and 18:00 UTC on April 14, 2026.\n* **All 1Password clients:**\u00a0The disruption applied to all client types, including the web app, browser extensions, and desktop and mobile applications, for customers connecting through the USA/Global region.\n* **Number of affected requests:**\u00a0Approximately 2.95% of requests over the incident window to [1Password.com](http://1Password.com) \\(USA/Global\\) during the incident window resulted in errors or timeouts, though for some brief spikes up to 45% of requests failed.\n* **Geographic regions affected:**\u00a0Customers on our USA/Global only, other regions were not affected.\n\n## What Happened?\n\nAn unusually high volume of traffic exceeded the capacity of our controls, and triggered latency and errors in the underlying applications.\n\n* **Timeline of events:**\n\n * **2026-04-14 17:25**\u00a0- Start of incident.\n * **2026-04-14 17:36**\u00a0- Issue identified.\n * **2026-04-14 17:51**\u00a0- Fix implemented.\n * **2026-04-14 18:01** - Recovery complete.\n \n* **Root cause analysis:** An increase in traffic exceeded the capacity of our traffic management layer, causing degraded service for customers in the USA/Global region.\n\n## How Was It Resolved?\n\n* Established runbooks for load shedding and system upgrades mitigated the issue.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Resolution:** We made two key changes to prevent recurrence:\n\n 1. **Increased capacity of internal systems**\n 2. **Upgraded traffic controls at the network edge**\n \n* **Verification:** Since implementing these changes, we have observed several additional instances of unusually high traffic matching this incident. In each case, the new controls handled the traffic automatically with no impact to customers or our systems.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "critical",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-04-14T21:54:58.647-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-14T13:25:14.000-04:00",
@@ -207,7 +207,7 @@
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-04-22T11:17:50.561-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-13T13:24:27.560-04:00",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-04-02T10:23:16.557-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-04-01T10:13:38.187-04:00",
@@ -233,7 +233,7 @@
233
  "body": "A fix has been deployed and this issue is now resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-03-31T20:43:02.537-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-31T17:28:13.895-04:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-03-16T13:43:02.427-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-16T13:11:54.093-04:00",
@@ -259,7 +259,7 @@
259
  "body": "Users were unable to retrieve documents across multiple platforms. This included degraded performance or failures when attempting to access documents via the CLI as well as through other interfaces.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-03-12T11:00:00.000-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-12T11:00:00.000-04:00",
@@ -272,7 +272,7 @@
272
  "body": "The scheduled maintenance is now complete",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "maintenance",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-03-11T03:39:58.741-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-03-10T16:35:10.567-04:00",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-01-30T13:09:06.557-05:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-30T10:35:45.063-05:00",
@@ -298,7 +298,7 @@
298
  "body": "The fix for the identified 2FA issue has been resolved as of version 8.12.4. The Sign-In attempts policy will become available in the coming weeks.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-03-03T10:52:27.515-05:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-01-23T15:33:54.000-05:00",
@@ -311,7 +311,7 @@
311
  "body": "# Incident Postmortem - 1Password Browser Extension Code Syntax Rendering Issue\n\n**Customer impact began \\(stable rollout start\\):** 2025-12-09\n\n**Investigation Started:** 2025-12-17\n\n**Incident Declared \\(UTC\\):** 2025-12-30 13:13\n\n**Fixed Release First Available:** 2026-01-01\n\n**Fixed Release Fully Available and Verified:** 2026-01-05\n\n**Incident Marked Resolved \\(UTC\\):** 2026-01-05 02:15\n\n**Service\\(s\\) Affected:** 1Password browser extension\n\n## Summary\n\nThe 1Password browser extension, which works by injecting code into web pages, inadvertently included code from PrismJS, a third party dependency, breaking syntax highlighting on some websites that display code blocks. The issue was reported in beta in early December, escalated after additional customer reports and a report from an external partner, and required releasing a stable update to remove the problematic dependency chain. This issue affected page rendering only and did not expose vault data or credentials.\n\n## Impact on Customers\n\nCustomers experienced broken code-block syntax highlighting on websites with `<code>` HTML elements while using the 1Password browser extension version 8.11.22 across all major browsers.\n\n* **Code snippet rendering issue:** Syntax highlighting for code blocks was broken on sites that display code snippet; impacted sites included developer documentation pages, technical forums, and blogs with code snippets.\n* **Browser scope:** Reported in Chromium-based browsers initially, and confirmed to affect all major browsers.\n* **Customer reports:** Started in beta with a single report on December 3, 2025, with additional reports in stable December 15\u201316, 2025. From December 9, 2025 through January 3, 2026 we received 55 unique customer reports. The issue was later observed in stable and amplified via social media.\n\n## What Happened?\n\nThe injected content script in the 1Password browser extension was able to include UI-related dependencies from other parts of the 1Password codebase in a context where they should not exist. This happened due to a small change that accidentally pulled in additional libraries caused by insufficient restrictions/guardrails on what dependencies could be imported into injected scripts.\n\n* **Detection and Escalation:**\n\n On December 3, 2025, we received a beta report that syntax highlighting was broken when the 1Password extension was enabled. That report was incorrectly tagged and did not reach the owning team for timely triage, so we did not recognize it as a potential release blocker before version 8.11.22 rolled out to stable on December 9, 2025.\n\n\n\n On December 17, 2025, an external partner reported the issue affecting stable. That report was routed correctly, we connected it to the earlier beta issue, and we began investigation and remediation.\n\n\n* **Timeline of Events \\(UTC\\):**\n\n * 2025-12-03: Internal ticket created after beta report of broken syntax highlighting.\n * 2025-12-09: Bug released to stable version 8.11.22.\n * 2025-12-15 to 2025-12-16: Three additional customers reported the issue \\(not yet routed to the owning team\\).\n * 2025-12-17: An external partner reported the issue affecting stable via a shared Slack channel; the Filling & Saving team began investigation.\n * 2025-12-22: Fix merged \\(script pruning applied broadly to remove PrismJS from injected scripts\\).\n * 2025-12-30: Reports surfaced that social media users observed the issue; stable update coordination began.\n * 2025-12-31: Releases published across all browser platforms.\n * 2026-01-01: Release approved by web stores.\n \n* **Root Cause Analysis:** We did not have an enforced dependency boundary for injected content scripts, which allowed unexpected UI and runtime dependencies to be bundled into the page-injected context.\n* **Trigger:** A new import introduced an indirect dependency chain from an injected script to a UI module and ultimately to PrismJS.\n* **Contributing Factors \\(if any\\):**\n\n * Mis-triage of beta report\n * Missing side-effect regression tests\n \n\n## How Was It Resolved?\n\nWe removed PrismJS from the scripts the extension injects into web pages by eliminating the import chain that pulled it into the injected bundle. We then shipped an updated extension across all supported browsers.\n\n* **Mitigation Steps:**\n\n * Coordinated releasing a stable update once stable impact and broader visibility were confirmed.\n \n* **Resolution Steps:**\n\n * Fix merged on 2025-12-22.\n * Fix was applied to the previous stable release.\n * New beta/stable builds created and published across platforms.\n * Fix approved by web stores as of 2026-01-01.\n * Releases published across nightly, beta, and stable.\n * Because extension updates roll out via browser web stores and auto-update schedules, we consider the fix fully available once all stores had approved the release and we verified the issue could no longer be reproduced on known affected sites.\n \n* **Verification of Resolution:**\n\n * We tested the new builds on known affected websites, validating that code block formatting is working as expected.\n * We confirmed that the browser extension build no longer contained the PrismJS library.\n \n\n## What We Are Doing to Prevent Future Incidents\n\n* Added lint rules to block disallowed imports into injected scripts.\n* Added internal documentation describing how to avoid dangerous imports and the potential impacts.\n* Ensure new lint rules to prevent dangerous imports are blocking in CI pipelines.\n* Add an automated test to internal testing sites to ensure injected content scripts don\u2019t introduce side effects.\n* Implement automated rules \\+ a triage SLA so new beta issues are reviewed by the owning team before stable release decisions.\n* Ensure bundle size changes are blocking changes, enforced by our automated build systems as part of the code review process.\n\n## Next Steps and Communication\n\n* Most browsers will auto-update extensions via their web stores. If the issue persists, customers should manually check for updates and verify they are on the fixed extension versions \\(8.11.27 and newer\\). Customers can verify their version in their browser\u2019s extension/add-ons settings \\(1Password extension version **8.11.27** or newer\\).\n* We will continue monitoring for regressions and follow up on guardrails \\(blocking lint rules, bundle-size checks, and automated website-side-effect tests\\).\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-01-23T15:04:42.406-05:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-01-23T15:04:42.360-05:00",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-01-12T17:58:31.086-05:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-01-12T12:24:08.874-05:00",
@@ -337,7 +337,7 @@
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2025-12-17T10:08:48.151-05:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-12-17T09:35:23.396-05:00",
@@ -350,7 +350,7 @@
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2025-11-30T16:52:23.620-05:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-11-30T15:35:48.095-05:00",
@@ -363,7 +363,7 @@
363
  "body": "# Incident Postmortem - Cloud Services Degraded\n\n**Date of Incident:** 2025-11-18 \n\n**Time of Incident \\(UTC\\):** 5:03pm UTC - 6:05pm UTC \n\n**Service\\(s\\) Affected:** SSO, sign in, sign up, CLI, web interface, access to vault content and other items, admin console, MFA\n\n**Impact Duration:** ~60 mins\n\n## Summary\n\nOn November 18, 2025, at 5:03 PM UTC, 1Password experienced degraded and temporarily unavailable cloud services for customers in the US region. The issue was caused by database resource exhaustion, causing operations to fail and connections to be rejected. This was not a security incident and no customer data was impacted. The issue was resolved by resizing the database to restore normal performance and ensure additional capacity for future growth.\n\n## Impact on Customers\n\n* **Single Sign-on \\(SSO\\), Multi-factor Authentication \\(MFA\\):** Users with SSO or MFA enabled experienced delays, and in some cases failures to log in.\n* **Browser Extension:** Users who needed to authenticate via the web interface were unable to unlock their vaults.\n* **Web Interface, Administration**: Customers were unable to log in, sign-ups failed, syncing between devices was not functioning, access to vault and other items were unavailable and the admin console was not reachable.\n* **API Access:** CLI users and API requests received timeout errors and slow responses.\n* **Number of Affected Customers \\(approximate\\):** All customers utilizing cloud interfaces and APIs in the affected region for the duration of the incident.\n* **Geographic Regions Affected \\(if applicable\\):** US/Global.\n\n## What Happened?\n\n* **Timeline of Events \\(UTC\\):**\n\n * 2025-11-18 4:59pm: Automated monitoring detects increased errors\n * 2025-11-18 5:03pm: Team began investigating\n * 2025-11-18 5:09pm: Servers restarted, service is still degraded\n * 2025-11-18 5:23pm: Public status page updated to Investigating and services Degraded\n * 2025-11-18 5:25pm: Servers scaled down to reduce database load\n * 2025-11-18 5:41pm: Database instance size upgrade started\n * 2025-11-18 5:44pm: Potentially problematic cron job disabled\n * 2025-11-18 5:56pm: Services slowly started to scale up\n * 2025-11-18 5:57pm: Services started to come back as the database instance resize completes\n * 2025-11-18 6:05pm: Incident marked as Identified\n * 2025-11-18 6:05pm: Team continues to monitor, performance has returned to normal levels\n * 2025-11-18 6:23pm: Incident marked as Monitoring and services Operational\n * 2025-11-18 7:16pm: Incident marked as resolved\n \n* **Root Cause Analysis:** The refactor of a feature increased the impact of a poorly performing query that had previously gone undetected. The result was the exponential increase in resource consumption for the main database. Once resources were fully exhausted, the service rejected connections and all requests failed.\n* **Contributing Factors \\(if any\\):**\n\n * Non-performant queries\n * Database under-provisioned\n \n\n## How Was It Resolved?\n\n* **Mitigation Steps:**\n\n * Background services were halted to reduce load on the database.\n * Application servers were scaled down to further reduce load.\n \n* **Resolution Steps:** Increasing the database instance size resolved the issue.\n* **Verification of Resolution:** Monitoring metrics were closely observed to ensure error rates returned to normal and database performance had stabilized.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Improving monitoring:** We are updating our monitoring systems to better detect database issues like this before impacting customers.\n* **Improve database performance:** We are refactoring the responsible query to improve performance and reduce load, and tuning the background service to prevent resource contention.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2025-11-18T14:15:40.905-05:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-11-18T12:22:41.032-05:00",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-11-18T10:47:43.501-05:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-11-18T07:06:21.480-05:00",
@@ -389,7 +389,7 @@
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-11-18T10:37:24.918-05:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-11-13T10:57:39.653-05:00",
@@ -402,7 +402,7 @@
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-11-06T17:04:08.478-05:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-11-06T15:16:11.532-05:00",
@@ -415,7 +415,7 @@
415
  "body": "The upstream provider has reported full service recovery and Trelica is fully operational. This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-10-30T10:11:06.156-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-10-29T14:20:52.280-04:00",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "major",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-10-28T21:37:45.856-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-10-28T16:41:50.485-04:00",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-10-24T14:08:14.942-04:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-10-24T13:04:32.048-04:00",
@@ -454,7 +454,7 @@
454
  "body": "# Incident Postmortem - 1Password Cloud Services Degraded\n\n* **Date of Incident:** 2025-10-20 \n* **Time of Incident \\(UTC\\):** 07:26:00 - 20:55:00 \n* **Service\\(s\\) Affected:** [1Password.com](http://1password.com/) website, Sign in, Access to passwords and other items \n* **Impact Duration:** 13 hours, 29 minutes\n\n## Summary\n\nOn October 20, 2025 at 07:26:00 UTC, [1Password.com](http://1password.com/) faced intermittent latency, authentication failures, and degraded service availability due to a major outage at [AWS in the us-east-1 region](https://aws.amazon.com/message/101925/). This was not a security incident and no customer data was affected.\n\nAs a result, the 1Password server-side application experienced degradation or intermittent failures, affecting up to 50% of traffic in the US region. Complete service restoration occurred in conjunction with AWS\u2019s final mitigations around 18:30 UTC.\n\n## Impact on Customers\n\nAll US customers accessing 1Password cloud services experienced intermittent latency, authentication failures, and degraded availability on [1Password.com](http://1password.com/).\n\n* **File Share:** Sharing of passwords via links could intermittently fail\n* **Login:** Users logging into vaults experienced timeout errors and slow responses\n* **Web Access:** Users accessing their vault through the web interface experienced timeout errors and slow responses\n* **API Access:** CLI users and API requests received timeout errors and slow responses\n\n## What Happened?\n\nAt 07:11:00 UTC, AWS began experiencing DNS resolution failures in the us-east-1 region, initially affecting DynamoDB and rapidly cascading to multiple AWS services.\u00a0 1Password monitoring detected impact at 07:26:00 UTC when monitoring alerts fired for inability to scale up clusters, and an incident was declared.\n\n1Password immediately deployed mitigations inside our infrastructure to ensure there was adequate compute capacity to serve our US-based users, which included pausing deployments and scaling down any services not critical to key functionality for our users.\n\n**Timeline of Events \\(UTC\\):**\n\n* 06:55:05 - 1Password monitoring triggers warning for unavailable Pods in Deployment \\(caused by inability to obtain AWS IAM credentials\\)\n* 07:03:06 - 1Password monitoring alerts for 5xx errors on auth start endpoint \\(caused by inability to obtain AWS IAM credentials\\) - pages authentication team, but alert recovers within minutes\n* 07:26:00 - 1Password monitoring alerts for inability to scale clusters, engineers begin investigating, Incident declared\n* 07:26:41- AWS confirms elevated error rates across multiple services\n* 07:49:06 - 1Password monitoring alerts for 5xx errors on auth start endpoint \\(caused by inability to obtain AWS IAM credentials\\)\n* 07:51:09 - AWS identifies DNS as the root cause, begins mitigation\n* 08:02:13 - 1Password suspends auto-scaling tooling to retain existing capacity\n* 09:27:33 - AWS reports significant recovery signs\n* 10:35:37 - AWS declares DNS issue fully mitigated, services recovering\n* 14:14:00-15:43:00 - AWS announced full recovery across all services; throttles EC2 launches\n* 16:42:49 - 1Password tooling and users start reporting 503s and inability to login due to volume of traffic\n* 16:50:00 - 1Password services restarted to reset and flush connections, prioritizing post-recovery traffic.\n* 20:53:00 - AWS resolves their incident\n* 20:55:00 - 1Password engineers overscale deployments for stability and overnight observation\n* Oct 21, 2025 - Incident resolved after confirmation of complete upstream recovery\n\n## How Was It Resolved?\n\n* **Mitigation Steps:** 1Password paused deployments and auto-management of cluster capacity to ensure enough capacity was available to serve users through peak access times. As demand outstripped available capacity, 1Password engineering reset the circuit breaker to allow additional connections to the service.\n* **Resolution Steps:** AWS announced system restoration and a reduction in throttling of EC2 API calls. To ensure sufficient capacity for peak traffic, 1Password engineers updated the required number of pods for core services the following business day and resumed auto-management of cluster capacity tooling. The following day, 1Password engineers resumed verification of the health of the systems, deployments, and auto-scaling of the services.\n* **Verification of Resolution:** Engineers observed monitoring systems and cluster management tooling logs to ensure system health.\n\n## **Root Cause Analysis**\n\n* **Root Cause Analysis:** The failures in AWS's internal network affected multiple AWS product APIs. This disruption directly impacted 1Password\u2019s ability to scale up infrastructure, deploy applications, and retrieve configuration data.\n* **Contributing Factors \\(if any\\):**\n\n * Third-party incident response services and paging services were affected by the AWS incident, which complicated communications.\n * Upstream customer IDPs were affected by the AWS outage, and returned errors that resulted in authentication failures.\n \n\n## What We Are Doing to Prevent Future Incidents\n\n* **Improve Incident Response:** Create additional backup protocols for when our incident response tooling is unavailable.\n* **Improve multi-service outage response:** Create strong break-glass runbooks in the event of a multi-service cloud provider outage.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "major",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-10-21T09:51:06.701-04:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-10-20T05:05:23.290-04:00",
@@ -467,7 +467,7 @@
467
  "body": "# Incident Postmortem - Degraded performance when accessing 1Password\n\n**Date of Incident:** 2025-09-26 \n**Time of Incident:** 4:20pm UTC - 5:39pm UTC \n**Service\\(s\\) Affected:** SSO, Web Sign In, Sign Up, Web Interface, CLI \n**Impact Duration:** ~60 minutes\n\n## Summary\n\nOn September 26, 2025 at 4:20 UTC 1Password\u2019s web interface and APIs experienced degraded performance for all customers in the US region. This was not a result of a security incident and customer data was not affected.\n\n## Impact on Customers\n\nDuring the duration of the incident:\n\n* **Web interface, Administration:** Customers experienced delays when accessing the 1Password web interface.\n* **Single Sign-on \\(SSO\\), Multi-factor Authentication \\(MFA\\):** Users with SSO or MFA enabled experienced delays, and in some cases failures to login.\n* **Command Line Interface \\(CLI\\):** CLI users faced increased latency and timeouts when attempting to access our web APIs.\n* **Browser Extension:** Users requiring web interface authentication experienced delays or failures.\n* **Number of Affected Customers \\(approximate\\):** ~30%\n* **Geographic Regions Affected:** [1password.com](http://1password.com) \\(US/Global\\)\n\n## What Happened?\n\nAt 4:20PM UTC and 5 PM UTC There were traffic bursts which caused extra load on one of our caches. This cache was under-provisioned to handle that spike of activity, which resulted in it exhausting available CPU. This caused cascading errors/latency which manifested in slow and failed requests.\n\n* **Timeline of Events \\(UTC\\):**\n\n * 2025-09-26 4:20pm: Spike in customer traffic began\n * 2025-09-26 4:29pm: Automated monitoring detects increased errors and latency\n * 2025-09-26 4:35pm: The team activates our incident protocol and begins investigation\n * 2025-09-26 4:58pm: The team decides to restart application servers\n * 2025-09-26 5:00pm: The servers have been restarted, service is still degraded, as a second traffic burst begins\n * 2025-09-26 5:18pm: Service starts to improve\n * 2025-09-26 5:25pm: The team detects increased load for the second time\n * 2025-09-26 5:33pm: The team restarts application servers again\n * 2025-09-26 5:39pm: Service is back to normal, team continues to investigate\n * 2025-09-26 7:26pm: Team has found the issue, and proceeds to upgrade cache instance size\n * 2025-09-26 7:49pm: Cache upgrade completed successfully\n * 2025-09-26 7:50pm: Team continues to monitor, performance has returned to nominal levels\n * 2025-09-26 8:24pm: Incident is marked as resolved\n \n* **Root Cause Analysis:**\n\n A code library installed in July introduced latency issues for cache connections. Authentication operations weren't properly rate-limited, allowing large traffic influxes. During peak traffic periods, the cache infrastructure was operating near maximum CPU capacity. The incident occurred when a burst of authentication traffic pushed the cache CPU utilization to 100%. The increased latency and CPU usage together directly caused the incident.\n\n\n* **Contributing Factors:**\n\n * Latency increase due to cache library version upgrade\n * Inadequate rate limiting allowed traffic bursts to go unchecked\n * Cache instance size is under-provisioned\n \n\n## How Was It Resolved?\n\n* **Mitigation Steps:** Restarting application servers temporarily mitigated the latency and errors, but the problems returned when traffic spiked again.\n* **Resolution Steps:** Increasing the instance size for the cache resolved the issue.\n* **Verification of Resolution:** The incident team tested the upgrade in a staging deployment before executing it in production. They then monitored metrics to confirm the system returned to normal levels.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Improve capacity planning for cache:** We will ensure our internal infrastructure is properly sized to handle current traffic volumes and accommodate future growth. We'll implement regular resource evaluations to maintain adequate capacity as our traffic increases. We will also implement proactive alerting systems that notify our teams when resource utilization approaches critical thresholds.\n* **Update library to a more performant version:** We will upgrade our caching library to the latest stable version to eliminate the current latency issues.\n* **Improve rate limiting for operations that triggered the traffic burst:** Enhancing our rate limiting system will significantly improve our ability to handle future traffic bursts.\n* **Timeline for Implementation:** Observability improvements have already been implemented, and we will complete the remaining work by the end of Q1, 2026.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\n\u200c\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-09-26T16:24:58.720-04:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-26T12:51:38.625-04:00",
@@ -480,7 +480,7 @@
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-09-25T13:22:01.362-04:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-25T11:43:45.006-04:00",
@@ -493,7 +493,7 @@
493
  "body": "# Incident Postmortem - Some customers are unable to interact with the admin console\n\n**Date of Incident:** 2025-09-24 \n\n**Time of Incident \\(UTC\\):** 02:27 - 17:16 \n\n**Service\\(s\\) Affected:** Admin console, Sign in \n\n**Impact Duration:** 36:49\n\n## Summary\n\nSome customers with certain account configurations were placed on a blocklist and presented with a 403 error page after accessing the admin console.\n\n## Impact on Customers\n\n* **Admin console:** Affected customers were presented with a 403 error page whenever they tried to interact with any of the admin console pages.\n* **Log in:** Affected customers were also unable to log in to the application.\n* **Number of Affected Customers \\(approximate\\):** 515\n* **Geographic Regions Affected \\(if applicable\\):** All regions\n\n## What Happened?\n\n* **Timeline of Events \\(UTC\\):**\n\n * Sep 24th 2:27am: Spike in application monitoring alerted engineers to increased rates of IP blocking\n * Sep 24th 3:00am: Cause identified as a change to requests in the application, which had been partially rolled out via a feature flag.\n * Sep 24th 4:03am: The feature flag was enabled to all customers which reduced the spike, but IP blocks continued throughout the day.\n * Sep 24th 10:03pm: Merged an application change to revert the change to prevent the issue reoccurring.\n * Sep 25th 5:03pm: The change was deployed with scheduled application release, error rate dropped off shortly after.\n \n* **Root Cause Analysis:** The issue was caused by GET requests to the Users API exceeding the URL length limit due to a recent change to append a list of UUIDs to the request parameters to resolve customer reported performance issues.\n* **Contributing factors:**\n\n * Requests were switched from GET to POST to prevent requests from exceeding the URL limit, however an issue with the feature flag configuration was causing UUIDs to be sent with the GET endpoint.\n * An underlying issue with the feature flag not resolving as expected in the application.\n \n\n## How Was It Resolved?\n\n* **Mitigation Steps:** Customers were manually removed from the blocklist at multiple points in time as we evaluated the root cause and worked to patch the root issue.\n* **Resolution Steps:** The issue was mitigated by removing UUIDs at the API level if a GET request is used. Additional logging has been added to identify the root cause of the feature flag configuration issue.\n* **Verification of Resolution:** We monitored our server logs to ensure that we did not observe any additional GET requests to the affected URL.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Audit additional admin console API requests:** We\u2019re performing a sweep of admin console API requests to ensure the utilization of POST requests with highly parameterized URLs.\n* **Remove the feature flag misconfiguration:** We\u2019re correcting the way the feature flag is configured to ensure consistent outcomes.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\n\u200c\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-09-24T00:10:05.235-04:00",
498
  "resolved_inferred": false,
499
  "started_at": "2025-09-23T23:00:42.664-04:00",
@@ -506,7 +506,7 @@
506
  "body": "# **Provisioning Invites could not be accepted**\n\n**Date of Incident:** 2025-09-23 \n**Time of Incident \\(UTC\\):** 17:18 - 00:46 \n**Service\\(s\\) Affected:** Sign Up \n**Impact Duration:** 7h 28m\n\n## **Summary**\n\nFor 7 hours and 28 minutes, 1Password Provisioning invites could not be accepted, presenting to the user as an invite expiry. Invites could not be accepted due to a web browser routing defect that was not caught during development, review, or release. First identified by customer reports approximately two and a half hours after release, the issue was escalated to development teams and an incident was immediately called. The root cause was identified as a defect introduced by a web client modification, and a fix was created, tested, and released. By 00:46 UTC, the fix was deployed to all environments and service was fully restored.\n\n## **Impact on Customers**\n\n* **Sign-up:** Provisioning invites could not be accepted.\n* **Number of Affected Customers \\(approximate\\):** 100% of provisioning invites could not be accepted\n* **Customer-facing impact**: Users clicking their invite links encountered a misleading \u2018Invite Expired\u2019 message.\n* **Geographic Regions Affected:** 1Password USA/Canada/EU/Enterprise\n\n## **What Happened?**\n\nA change to the web client contained a router defect that incorrectly rendered provisioning invites as expired. Users were presented with an error message that erroneously stated the invite was expired. The change responsible for introducing the defect was able to be released because it was not captured under automatic change notification rules, was lacking automated test coverage, and was not included in the set of manual tests.\n\n* **Timeline of Events \\(UTC\\):**\n\n * 17:18: 1Password Release containing defect\n * 19:53 \\(2 hours, 35 minutes later\\) First customer report\n * 20:49 \\(56 minutes later\\) Escalation to developer teams\n * 21:01: \\(12 minutes later\\) Incident called\n * 22:02: \\(1 hour, 1 minute later\\) Root cause identified\n * 22:29: \\(27 minutes later\\) Fix created and testing initiated\n * 23:49: \\(1 hour, 30 minutes later\\) Fix merged\n * 00:46: \\(57 minutes later\\) Fix released and service fully restored\n \n* **Root Cause Analysis:** A change modified the order in which key provisioning web routes were rendered. As a result, the route handling provisioning invitations failed to use the correct query parameters and the invite rendered as expired.\n* **Contributing Factors:** Automated tests on this endpoint do not exist. Manual testing missed testing the Provisioning routes. The modified code was not covered by automatic change notification rules to notify the Provisioning team. An existing bug that can fail the resending of invites was an initial red herring during the investigation.\n\n## **How Was It Resolved?**\n\n* **Resolution Steps:** The defect in the 1Password web client was corrected so provisioning invites would render correctly.\n* **Verification of Resolution:** 1Password engineering tested the changes and validated that the functionality was restored, as well as verifying that requests for the affected endpoints were successful after the fix was deployed.\n\n## **What We Are Doing to Prevent Future Incidents**\n\n* **Improve automated tests:** We are enhancing our automated tests for the Provisioning Invite routes.\n* **Expand automatic change notifications:** Expanding coverage of automatic change notification rules for areas of code owned by the Provisioning team.\n\n## **Next Steps and Communication**\n\n* No action is required from our customers at this time. Existing invites do not need to be resent and may be accepted.\n* If you are still experiencing issues, please contact our support team at [support@1password.com](mailto:support@1password.com). \n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-09-23T22:07:03.833-04:00",
511
  "resolved_inferred": false,
512
  "started_at": "2025-09-23T17:24:26.152-04:00",
@@ -519,7 +519,7 @@
519
  "body": "We have confirmed resolution of this issue and this incident is now resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2025-09-19T14:17:59.181-04:00",
524
  "resolved_inferred": false,
525
  "started_at": "2025-09-18T16:19:16.670-04:00",
@@ -532,7 +532,7 @@
532
  "body": "Our provider has deployed a fix. Error rates have returned to normal. This incident is now resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2025-09-18T13:08:47.709-04:00",
537
  "resolved_inferred": false,
538
  "started_at": "2025-09-18T10:48:41.437-04:00",
@@ -545,7 +545,7 @@
545
  "body": "# Performance Degradation\n\n**Date of Incident:** 2025-09-03 \n**Time of Incident \\(UTC\\):** 11:06 - 12:07 \n**Service\\(s\\) Affected:** All APIs \n**Impact Duration:** 61 minutes\n\n## Summary\n\nFor 61 minutes on the morning of September 3rd, 2025, all 1Password APIs in the US/Global environment had degraded performance or returned an error for approximately 20% of requests. 92% of the impact was mitigated within 13 minutes at 11:19 by automation scaling up infrastructure. By 12:06 a manual restart of the remaining infrastructure completed mitigation. A permanent fix was implemented and deployed to prevent the issue from reoccurring.\n\n## Impact on Customers\n\n* **APIs:** High latency, or a 500 Internal Server Error.\n* **Number of Affected Customers:** 20% of all requests returned errors for 13 minutes, 1% thereafter.\n* **Geographic Regions Affected \\(if applicable\\):** 1Password USA/Global\n\n## What Happened?\n\n* **Timeline of Events \\(UTC\\):**\n\n * 11:05: A customer started a stream of an unusually high volume of requests to an API with sub-optimal performance.\n * 11:06: Some servers started consuming abnormally high memory, causing slow response times and high error rates.\n * 11:19: Automation scaled up infrastructure to service additional load\n * 11:30: Increased errors trigger escalation, on-call engineer begins investigation\n * 11:51: Engineers declare an incident and alert response teams\n * 12:02: Response team begins restarting affected servers.\n * 12:07: All servers completed restarts, and error rates returned to normal levels\n \n* **Root Cause Analysis:** A poorly performing cache operation was triggered repeatedly in a short period of time across multiple servers, leading directly to greatly delayed responses.\n\n## How Was It Resolved?\n\n* **Mitigation Steps:** Automatic instance scaling restored over 98% of operational capacity after 13 minutes. Full capacity was restored through manual intervention\n* **Resolution Steps:** We refactored the poorly performing query.\n* **Verification of Resolution:** We tested the affected API to confirm refactoring of query produced the desired performance improvement. We deployed the fix and monitored it for 24 hours to assert the issue was resolved.\n\n## What We Are Doing to Prevent Future Incidents\n\n* We are auditing services for sub-optimal query performance.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\n\u200c\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "minor",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2025-09-03T07:00:00.000-04:00",
550
  "resolved_inferred": false,
551
  "started_at": "2025-09-03T07:00:00.000-04:00",
@@ -558,7 +558,7 @@
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2025-08-18T18:53:58.892-04:00",
563
  "resolved_inferred": false,
564
  "started_at": "2025-08-18T17:36:12.219-04:00",
@@ -571,7 +571,7 @@
571
  "body": "## **Incident Postmortem - Sign-in Service Degradation**\n\n* **Date of Incident:** 2025-08-05\n* **Time of Incident \\(UTC\\):** 20:20 - 21:20\n* **Service\\(s\\) Affected:** Sign-in, Web Application, Command Line Interface \\(CLI\\), Single Sign On \\(SSO\\), API\u2019s\n* **Impact Duration:** 1 hour\n\n### **Summary**\n\nOn August 5, 2025, 1Password experienced a service degradation that impacted customers' ability to sign in and access the web application. The incident was triggered during a planned architectural improvement when a misconfigured rollback attempt caused an overload of traffic and a subsequent database connection bottleneck. The issue was resolved by correcting the misconfiguration and restarting the web application servers, fully restoring service.\n\n### **Impact on Customers**\n\nDuring the service disruption, some customers experienced degraded performance when accessing their 1Password vaults and signing in.\n\n* **Sign-in Issues**: Customers may have experienced sign-in slowness or timeouts.\n* **Error Messages**: Customers may have seen error messages when attempting to sign in, such as \"Can't sign in\", \"Failed to determine sign in methods for email\", or \"Upstream connect error\".\n* **Vault Access**: Some customers experienced degraded performance when accessing their 1Password vaults.\n* **Geographic Regions Affected:** USA/Global\n\n### **What Happened?**\n\nThe incident was part of ongoing improvements to the 1Password infrastructure and was not the result of a security incident. Customer data was not affected.\n\n**Timeline of Events \\(UTC\\):**\n\n* **17:12**: A planned, phased rollout of an architectural improvement to authentication systems begins.\n* **18:20**: Engineers monitoring the rollout begin to observe higher latency during sign-in for a small subset of accounts.\n* **20:17**: A rollback of the change is initiated. An error in the rollback configuration sends a high volume of traffic to the new code path, causing a database connection bottleneck. Engineers observing the deployment immediately observe service impact.\u00a0\n* **20:21**: A corrective action is deployed to revert the system to its previous state before the misconfigured rollback.\n* **20:39**: While impact is still being observed, a failover from the primary database to a secondary database is initiated. This action has no effect.\u00a0\n* **20:58**: A restart of the service that manages incoming traffic to our services is initiated to reset connections.\n* **21:13**: A rolling restart of the web application servers is initiated.\n* **21:20**: Service is fully restored for all customers.\n\n**Root Cause Analysis:** The root cause was an error in the configuration of an attempted rollback. This misconfiguration incorrectly routed a high volume of sign-in traffic through a new, slower code path, which created a bottleneck of connections to our primary database and made the web application unresponsive.\n\n### **How Was It Resolved?**\n\n**Resolution Steps:** The issue was fully resolved through two key actions:\n\n1. The rollback misconfiguration was identified and corrected, which stopped traffic from flowing to the problematic new code.\n2. A rolling restart of the web application servers was performed to clear the backlog of stuck database connections.\n\n**Verification of Resolution:** Monitoring systems were closely observed for 30 minutes to ensure error rates returned to normal.\n\n### **What We Are Doing to Prevent Future Incidents**\n\nWe are working to implement the following improvements:\n\n* **Improve configuration testing**: We will improve testing procedures of configuration updates and their rollbacks prior to being pushed to production.\n* **Improve our deployment tooling**: We will add additional validation to our traffic management tools to prevent similar configuration errors.\n* **Review our incident response procedures**: We have updated the runbook used to respond to this type of incident with guidance that will enable faster recovery.\n* **Enhance our monitors**: We will add more specific alerts that will help us more quickly distinguish between different application tiers, allowing for faster diagnosis and time to resolution.\n\n### **Next Steps and Communication**\n\nNo action is required from our customers. 1Password applications are designed to be resilient, with local copies of vault data always available on customer devices, even without a connection to the 1Password service.\n\nIf you are still experiencing issues, please contact our support team.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely, The 1Password Team",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2025-08-05T17:59:54.829-04:00",
576
  "resolved_inferred": false,
577
  "started_at": "2025-08-05T16:46:48.030-04:00",
 
3
  "slug": "1password",
4
  "platform": "statuspage",
5
  "status_url": "https://1password.statuspage.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "A fix has been deployed and this issue is now resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-07-22T15:20:54.949-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-22T13:55:18.026-04:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-07-17T14:57:38.340-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-17T14:52:15.282-04:00",
 
38
  "body": "A fix has been deployed and this issue is now resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-07-13T15:57:14.635-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-13T14:59:33.940-04:00",
 
51
  "body": "A fix for this issue has been implemented, and our teams are monitoring. During the outage, GitHub Actions might have failed to pull the latest CLI version, causing the pipeline to fail.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-13T10:30:00.000-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-13T10:30:00.000-04:00",
 
64
  "body": "# Incident Postmortem - Device Trust Authentication Outage\n\n**Date of Incident:** 2026-07-02 \n**Time of Incident \\(UTC\\):** 19:28 - 20:28 \n**Service\\(s\\) Affected:** This incident affected: USA/Global \\(Device Trust Authentication Service, Device Trust Checks Server, Device Trust Portal, Device Trust API\\) and Europe \\(Device Trust Authentication Service, Device Trust Checks Server, Device Trust Portal, Device Trust API\\). \n**Impact Duration:** 1 Hour\n\n## Summary\n\nOn July 2, 2026, 1Password Device Trust experienced an outage lasting approximately one hour, beginning at 19:28 UTC. During this window, all Device Trust services were unavailable and users were unable to authenticate. We have identified the root cause: an internal configuration change to our cloud load balancing infrastructure was applied more broadly than intended which temporarily made a required endpoint unreachable. This was not a security incident and did not involve any third party. The configuration has been corrected, service has been fully restored, and we have implemented additional safeguards to help prevent this type of issue from recurring.\n\n## Impact on Customers\n\n* **All Device Trust services were completely unavailable during the 60-minute outage window. Users were unable to authenticate to any Device Trust service, including the authentication portal \\(**[**auth.kolide.com**](http://auth.kolide.com)**\\), admin console \\(**[**app.kolide.com**](http://app.kolide.com)**\\), API endpoints, and device server.**\n* **Number of Affected Customers \\(approximate\\):** 100% of Device Trust customers\n* **Geographic Regions Affected \\(if applicable\\):** US and EU\n\n## What Happened?\n\nOn July 2, 2026, A configuration change intended to improve the security configuration of an internal service was applied more broadly than intended, affecting a shared network routing component relied on by Device Trust. The change replaced the underlying network infrastructure supporting Device Trust. However, the traffic routing configuration continued to reference the previous infrastructure instead of the newly provisioned resources. As a result, Device Trust authentication endpoints became unreachable. Reverting the change restored connectivity and service.\n\n* **Timeline of Events \\(UTC\\):**\n\n * 19:28: Network configuration change applied; Network Load Balancers responsible for routing traffic for Device Trust services became unreachable\n * 19:30: Automated monitoring detects the outage and triggers alerts\n * 19:33: Incident is declared at [status.1password.com](http://status.1password.com)\n * 20:03: Root cause is identified as a load balancer configuration issue\n * 20:24: Load balancer is recreated with correct configuration\n * 20:26 Recovery is confirmed for [app.kolide.com](http://app.kolide.com)\n * 20:28 Recovery is confirmed for [auth.kolide.com](http://auth.kolide.com)\n \n* **Contributing Factors \\(if any\\):**\n\n * **Shared component scope not visible during review or validation.** The network infrastructure class affected by the change was shared across multiple services, but this dependency was not documented or surfaced in the change review process. As a result, the pre-production validation, while performed in a lower environment before production rollout, did not cover all dependent services, and the impact on Device Trust was not identified before the change reached production.\n * **Concurrent diagnostic signals slowed root cause identification.** At the time the outage began, unrelated certificate renewal errors surfaced alongside the network connectivity failure. Investigating both signals simultaneously delayed identification of the network configuration change as the root cause.\n \n\n## How Was It Resolved?\n\n* **Resolution Steps:** Once the source of the outage was identified, engineers reverted the configuration change. The affected network infrastructure was recreated with its original, publicly accessible configuration, restoring routing to all Device Trust authentication endpoints. Service recovery was confirmed sequentially across affected services before the incident was closed.\n* **Verification of Resolution:** Following the revert, engineers verified that all Device Trust authentication endpoints were reachable and accepting traffic. Customer confirmation of resolution was subsequently received through the support team.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Require explicit approval for destructive infrastructure changes.** We are implementing safeguards that require manual review and approval before changes that would destroy and recreate critical network infrastructure can be applied. This creates a forcing function to catch unintended scope before changes reach production.\n* **Improve scope visibility for shared infrastructure components.** We are documenting the dependencies between shared infrastructure components and the services that rely on them, and integrating this information into our change review process. Future changes to shared components will require an explicit assessment of downstream impact before deployment.\n* **Strengthen pre-production validation across shared dependencies.** We are updating our change promotion process to require validation against all services that share affected components \u2014 not only the intended target \u2014 before changes are promoted to production.\n* **Reduce single points of failure in traffic routing.** We are evaluating architectural changes to introduce redundancy into Device Trust's traffic routing configuration, so that a failure in any single component results in degraded service rather than a complete outage.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "critical",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-02T16:30:48.837-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-02T15:44:00.651-04:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-06-30T10:09:25.287-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-29T18:08:19.241-04:00",
 
90
  "body": "The issue is now resolved, and access to 1Password services should be fully restored.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-06-24T15:01:46.148-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-24T13:15:10.565-04:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-06-18T14:50:42.250-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-18T13:54:11.964-04:00",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-06-17T12:00:17.093-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-16T12:24:03.697-04:00",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-06-12T19:18:57.981-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-11T17:49:05.374-04:00",
 
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-05-16T16:36:03.709-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-16T11:51:33.535-04:00",
 
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-05-04T14:34:49.601-04:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-04T13:59:28.385-04:00",
 
168
  "body": "# Incident Postmortem - Login and Sync Issues\n\n**Date of Incident:** 2026-04-27 \n**Time of Incident \\(UTC\\):** 14:15 - 15:41 \n**Service\\(s\\) Affected:** All web APIs \n**Impact Duration:** Approximately 86 minutes\n\n## Summary\n\nOn April 27, 2026, [1Password.com](http://1password.com/) experienced a period of elevated error and full service unavailability in our USA/Global region. A defect deployed in application scaling logic caused a cascading failure during peak usage. This resulted in a period of service unavailability for customers in the USA/Global region.\n\nThis was not a security incident, and there was no loss of data.\n\n## Impact on Customers\n\n* **Sign-in and account access:** Customers in the USA/Global region experienced errors or were unable to sign in or access their 1Password accounts between approximately 14:15 and 15:41 UTC on April 27, 2026.\n* **All 1Password clients:** The disruption applied to all client types, including the web app, CLI, browser extensions, and desktop and mobile applications, for customers connecting through the USA/Global region.\n* **Geographic regions affected:** Only customers on the USA/Global region were affected. Other regions were not impacted.\n\n## What Happened?\n\nWe deployed a change to how our services signal their readiness to serve requests, which contained a latent defect.\n\n* **Timeline of events:**\n\n * **2026-04-27 14:15 UTC** - Load increase triggers issues.\n * **2026-04-27 14:29 UTC** - Incident declared; response team mobilized.\n * **2026-04-27 15:41 UTC** - Issue identified and fix deployed.\n * **2026-04-28 18:06 UTC** - Incident formally resolved following monitoring.\n \n\n## How Was It Resolved?\n\nOur on-call engineering team identified the scaling logic as the cause of the cascading failure and disabled it via a configuration change. Once disabled, capacity was restored, and traffic recovered. A subsequent configuration change was made to prevent this logic from being re-enabled in production environments.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Immediate fix:** We disabled the defective health check logic and locked the configuration to prevent it from being re-enabled in production.\n* **Retrospective:** We are conducting a full retrospective with the incident responders to identify further improvements to our systems and our response processes.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your patience and understanding.\n\nSincerely,\n\nThe 1Password Team",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-04-28T14:00:34.801-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-27T10:54:26.804-04:00",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-04-22T12:06:19.982-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-22T11:18:52.323-04:00",
 
194
  "body": "# 2026-04-14 SEV1 Incident Postmortem - Hosted Service in the US experiencing high latency and errors\n\n# Incident Postmortem - Elevated Application Error\n\n**Date of Incident:** 2026-04-14 \n**Time of Incident \\(UTC\\):** 17:25 - 18:00 \n**Service\\(s\\) Affected:** Sign in, Admin console \n**Impact Duration:** Approximately 35 minutes\n\n## Summary\n\nOn April 14, 2026, [1Password.com](http://1Password.com) experienced elevated error rates due to an increase in traffic to our USA/Global infrastructure. Requests arrived more quickly than they could be serviced in our USA/global region. Customers experienced errors and high latency.\n\nThis was not a security incident, and there was no loss of data.\n\n## Impact on Customers\n\n* **Sign-in and account access:**\u00a0Some customers in the USA/Global region experienced errors when attempting to sign in or access their 1Password accounts between 17:25 and 18:00 UTC on April 14, 2026.\n* **All 1Password clients:**\u00a0The disruption applied to all client types, including the web app, browser extensions, and desktop and mobile applications, for customers connecting through the USA/Global region.\n* **Number of affected requests:**\u00a0Approximately 2.95% of requests over the incident window to [1Password.com](http://1Password.com) \\(USA/Global\\) during the incident window resulted in errors or timeouts, though for some brief spikes up to 45% of requests failed.\n* **Geographic regions affected:**\u00a0Customers on our USA/Global only, other regions were not affected.\n\n## What Happened?\n\nAn unusually high volume of traffic exceeded the capacity of our controls, and triggered latency and errors in the underlying applications.\n\n* **Timeline of events:**\n\n * **2026-04-14 17:25**\u00a0- Start of incident.\n * **2026-04-14 17:36**\u00a0- Issue identified.\n * **2026-04-14 17:51**\u00a0- Fix implemented.\n * **2026-04-14 18:01** - Recovery complete.\n \n* **Root cause analysis:** An increase in traffic exceeded the capacity of our traffic management layer, causing degraded service for customers in the USA/Global region.\n\n## How Was It Resolved?\n\n* Established runbooks for load shedding and system upgrades mitigated the issue.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Resolution:** We made two key changes to prevent recurrence:\n\n 1. **Increased capacity of internal systems**\n 2. **Upgraded traffic controls at the network edge**\n \n* **Verification:** Since implementing these changes, we have observed several additional instances of unusually high traffic matching this incident. In each case, the new controls handled the traffic automatically with no impact to customers or our systems.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "critical",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-04-14T21:54:58.647-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-14T13:25:14.000-04:00",
 
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-04-22T11:17:50.561-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-13T13:24:27.560-04:00",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-04-02T10:23:16.557-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-04-01T10:13:38.187-04:00",
 
233
  "body": "A fix has been deployed and this issue is now resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-03-31T20:43:02.537-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-31T17:28:13.895-04:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-03-16T13:43:02.427-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-16T13:11:54.093-04:00",
 
259
  "body": "Users were unable to retrieve documents across multiple platforms. This included degraded performance or failures when attempting to access documents via the CLI as well as through other interfaces.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-03-12T11:00:00.000-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-12T11:00:00.000-04:00",
 
272
  "body": "The scheduled maintenance is now complete",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "maintenance",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-03-11T03:39:58.741-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-03-10T16:35:10.567-04:00",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-01-30T13:09:06.557-05:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-30T10:35:45.063-05:00",
 
298
  "body": "The fix for the identified 2FA issue has been resolved as of version 8.12.4. The Sign-In attempts policy will become available in the coming weeks.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-03-03T10:52:27.515-05:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-01-23T15:33:54.000-05:00",
 
311
  "body": "# Incident Postmortem - 1Password Browser Extension Code Syntax Rendering Issue\n\n**Customer impact began \\(stable rollout start\\):** 2025-12-09\n\n**Investigation Started:** 2025-12-17\n\n**Incident Declared \\(UTC\\):** 2025-12-30 13:13\n\n**Fixed Release First Available:** 2026-01-01\n\n**Fixed Release Fully Available and Verified:** 2026-01-05\n\n**Incident Marked Resolved \\(UTC\\):** 2026-01-05 02:15\n\n**Service\\(s\\) Affected:** 1Password browser extension\n\n## Summary\n\nThe 1Password browser extension, which works by injecting code into web pages, inadvertently included code from PrismJS, a third party dependency, breaking syntax highlighting on some websites that display code blocks. The issue was reported in beta in early December, escalated after additional customer reports and a report from an external partner, and required releasing a stable update to remove the problematic dependency chain. This issue affected page rendering only and did not expose vault data or credentials.\n\n## Impact on Customers\n\nCustomers experienced broken code-block syntax highlighting on websites with `<code>` HTML elements while using the 1Password browser extension version 8.11.22 across all major browsers.\n\n* **Code snippet rendering issue:** Syntax highlighting for code blocks was broken on sites that display code snippet; impacted sites included developer documentation pages, technical forums, and blogs with code snippets.\n* **Browser scope:** Reported in Chromium-based browsers initially, and confirmed to affect all major browsers.\n* **Customer reports:** Started in beta with a single report on December 3, 2025, with additional reports in stable December 15\u201316, 2025. From December 9, 2025 through January 3, 2026 we received 55 unique customer reports. The issue was later observed in stable and amplified via social media.\n\n## What Happened?\n\nThe injected content script in the 1Password browser extension was able to include UI-related dependencies from other parts of the 1Password codebase in a context where they should not exist. This happened due to a small change that accidentally pulled in additional libraries caused by insufficient restrictions/guardrails on what dependencies could be imported into injected scripts.\n\n* **Detection and Escalation:**\n\n On December 3, 2025, we received a beta report that syntax highlighting was broken when the 1Password extension was enabled. That report was incorrectly tagged and did not reach the owning team for timely triage, so we did not recognize it as a potential release blocker before version 8.11.22 rolled out to stable on December 9, 2025.\n\n\n\n On December 17, 2025, an external partner reported the issue affecting stable. That report was routed correctly, we connected it to the earlier beta issue, and we began investigation and remediation.\n\n\n* **Timeline of Events \\(UTC\\):**\n\n * 2025-12-03: Internal ticket created after beta report of broken syntax highlighting.\n * 2025-12-09: Bug released to stable version 8.11.22.\n * 2025-12-15 to 2025-12-16: Three additional customers reported the issue \\(not yet routed to the owning team\\).\n * 2025-12-17: An external partner reported the issue affecting stable via a shared Slack channel; the Filling & Saving team began investigation.\n * 2025-12-22: Fix merged \\(script pruning applied broadly to remove PrismJS from injected scripts\\).\n * 2025-12-30: Reports surfaced that social media users observed the issue; stable update coordination began.\n * 2025-12-31: Releases published across all browser platforms.\n * 2026-01-01: Release approved by web stores.\n \n* **Root Cause Analysis:** We did not have an enforced dependency boundary for injected content scripts, which allowed unexpected UI and runtime dependencies to be bundled into the page-injected context.\n* **Trigger:** A new import introduced an indirect dependency chain from an injected script to a UI module and ultimately to PrismJS.\n* **Contributing Factors \\(if any\\):**\n\n * Mis-triage of beta report\n * Missing side-effect regression tests\n \n\n## How Was It Resolved?\n\nWe removed PrismJS from the scripts the extension injects into web pages by eliminating the import chain that pulled it into the injected bundle. We then shipped an updated extension across all supported browsers.\n\n* **Mitigation Steps:**\n\n * Coordinated releasing a stable update once stable impact and broader visibility were confirmed.\n \n* **Resolution Steps:**\n\n * Fix merged on 2025-12-22.\n * Fix was applied to the previous stable release.\n * New beta/stable builds created and published across platforms.\n * Fix approved by web stores as of 2026-01-01.\n * Releases published across nightly, beta, and stable.\n * Because extension updates roll out via browser web stores and auto-update schedules, we consider the fix fully available once all stores had approved the release and we verified the issue could no longer be reproduced on known affected sites.\n \n* **Verification of Resolution:**\n\n * We tested the new builds on known affected websites, validating that code block formatting is working as expected.\n * We confirmed that the browser extension build no longer contained the PrismJS library.\n \n\n## What We Are Doing to Prevent Future Incidents\n\n* Added lint rules to block disallowed imports into injected scripts.\n* Added internal documentation describing how to avoid dangerous imports and the potential impacts.\n* Ensure new lint rules to prevent dangerous imports are blocking in CI pipelines.\n* Add an automated test to internal testing sites to ensure injected content scripts don\u2019t introduce side effects.\n* Implement automated rules \\+ a triage SLA so new beta issues are reviewed by the owning team before stable release decisions.\n* Ensure bundle size changes are blocking changes, enforced by our automated build systems as part of the code review process.\n\n## Next Steps and Communication\n\n* Most browsers will auto-update extensions via their web stores. If the issue persists, customers should manually check for updates and verify they are on the fixed extension versions \\(8.11.27 and newer\\). Customers can verify their version in their browser\u2019s extension/add-ons settings \\(1Password extension version **8.11.27** or newer\\).\n* We will continue monitoring for regressions and follow up on guardrails \\(blocking lint rules, bundle-size checks, and automated website-side-effect tests\\).\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-01-23T15:04:42.406-05:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-01-23T15:04:42.360-05:00",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-01-12T17:58:31.086-05:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-01-12T12:24:08.874-05:00",
 
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2025-12-17T10:08:48.151-05:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-12-17T09:35:23.396-05:00",
 
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2025-11-30T16:52:23.620-05:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-11-30T15:35:48.095-05:00",
 
363
  "body": "# Incident Postmortem - Cloud Services Degraded\n\n**Date of Incident:** 2025-11-18 \n\n**Time of Incident \\(UTC\\):** 5:03pm UTC - 6:05pm UTC \n\n**Service\\(s\\) Affected:** SSO, sign in, sign up, CLI, web interface, access to vault content and other items, admin console, MFA\n\n**Impact Duration:** ~60 mins\n\n## Summary\n\nOn November 18, 2025, at 5:03 PM UTC, 1Password experienced degraded and temporarily unavailable cloud services for customers in the US region. The issue was caused by database resource exhaustion, causing operations to fail and connections to be rejected. This was not a security incident and no customer data was impacted. The issue was resolved by resizing the database to restore normal performance and ensure additional capacity for future growth.\n\n## Impact on Customers\n\n* **Single Sign-on \\(SSO\\), Multi-factor Authentication \\(MFA\\):** Users with SSO or MFA enabled experienced delays, and in some cases failures to log in.\n* **Browser Extension:** Users who needed to authenticate via the web interface were unable to unlock their vaults.\n* **Web Interface, Administration**: Customers were unable to log in, sign-ups failed, syncing between devices was not functioning, access to vault and other items were unavailable and the admin console was not reachable.\n* **API Access:** CLI users and API requests received timeout errors and slow responses.\n* **Number of Affected Customers \\(approximate\\):** All customers utilizing cloud interfaces and APIs in the affected region for the duration of the incident.\n* **Geographic Regions Affected \\(if applicable\\):** US/Global.\n\n## What Happened?\n\n* **Timeline of Events \\(UTC\\):**\n\n * 2025-11-18 4:59pm: Automated monitoring detects increased errors\n * 2025-11-18 5:03pm: Team began investigating\n * 2025-11-18 5:09pm: Servers restarted, service is still degraded\n * 2025-11-18 5:23pm: Public status page updated to Investigating and services Degraded\n * 2025-11-18 5:25pm: Servers scaled down to reduce database load\n * 2025-11-18 5:41pm: Database instance size upgrade started\n * 2025-11-18 5:44pm: Potentially problematic cron job disabled\n * 2025-11-18 5:56pm: Services slowly started to scale up\n * 2025-11-18 5:57pm: Services started to come back as the database instance resize completes\n * 2025-11-18 6:05pm: Incident marked as Identified\n * 2025-11-18 6:05pm: Team continues to monitor, performance has returned to normal levels\n * 2025-11-18 6:23pm: Incident marked as Monitoring and services Operational\n * 2025-11-18 7:16pm: Incident marked as resolved\n \n* **Root Cause Analysis:** The refactor of a feature increased the impact of a poorly performing query that had previously gone undetected. The result was the exponential increase in resource consumption for the main database. Once resources were fully exhausted, the service rejected connections and all requests failed.\n* **Contributing Factors \\(if any\\):**\n\n * Non-performant queries\n * Database under-provisioned\n \n\n## How Was It Resolved?\n\n* **Mitigation Steps:**\n\n * Background services were halted to reduce load on the database.\n * Application servers were scaled down to further reduce load.\n \n* **Resolution Steps:** Increasing the database instance size resolved the issue.\n* **Verification of Resolution:** Monitoring metrics were closely observed to ensure error rates returned to normal and database performance had stabilized.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Improving monitoring:** We are updating our monitoring systems to better detect database issues like this before impacting customers.\n* **Improve database performance:** We are refactoring the responsible query to improve performance and reduce load, and tuning the background service to prevent resource contention.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2025-11-18T14:15:40.905-05:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-11-18T12:22:41.032-05:00",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-11-18T10:47:43.501-05:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-11-18T07:06:21.480-05:00",
 
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-11-18T10:37:24.918-05:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-11-13T10:57:39.653-05:00",
 
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-11-06T17:04:08.478-05:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-11-06T15:16:11.532-05:00",
 
415
  "body": "The upstream provider has reported full service recovery and Trelica is fully operational. This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-10-30T10:11:06.156-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-10-29T14:20:52.280-04:00",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "major",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-10-28T21:37:45.856-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-10-28T16:41:50.485-04:00",
 
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-10-24T14:08:14.942-04:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-10-24T13:04:32.048-04:00",
 
454
  "body": "# Incident Postmortem - 1Password Cloud Services Degraded\n\n* **Date of Incident:** 2025-10-20 \n* **Time of Incident \\(UTC\\):** 07:26:00 - 20:55:00 \n* **Service\\(s\\) Affected:** [1Password.com](http://1password.com/) website, Sign in, Access to passwords and other items \n* **Impact Duration:** 13 hours, 29 minutes\n\n## Summary\n\nOn October 20, 2025 at 07:26:00 UTC, [1Password.com](http://1password.com/) faced intermittent latency, authentication failures, and degraded service availability due to a major outage at [AWS in the us-east-1 region](https://aws.amazon.com/message/101925/). This was not a security incident and no customer data was affected.\n\nAs a result, the 1Password server-side application experienced degradation or intermittent failures, affecting up to 50% of traffic in the US region. Complete service restoration occurred in conjunction with AWS\u2019s final mitigations around 18:30 UTC.\n\n## Impact on Customers\n\nAll US customers accessing 1Password cloud services experienced intermittent latency, authentication failures, and degraded availability on [1Password.com](http://1password.com/).\n\n* **File Share:** Sharing of passwords via links could intermittently fail\n* **Login:** Users logging into vaults experienced timeout errors and slow responses\n* **Web Access:** Users accessing their vault through the web interface experienced timeout errors and slow responses\n* **API Access:** CLI users and API requests received timeout errors and slow responses\n\n## What Happened?\n\nAt 07:11:00 UTC, AWS began experiencing DNS resolution failures in the us-east-1 region, initially affecting DynamoDB and rapidly cascading to multiple AWS services.\u00a0 1Password monitoring detected impact at 07:26:00 UTC when monitoring alerts fired for inability to scale up clusters, and an incident was declared.\n\n1Password immediately deployed mitigations inside our infrastructure to ensure there was adequate compute capacity to serve our US-based users, which included pausing deployments and scaling down any services not critical to key functionality for our users.\n\n**Timeline of Events \\(UTC\\):**\n\n* 06:55:05 - 1Password monitoring triggers warning for unavailable Pods in Deployment \\(caused by inability to obtain AWS IAM credentials\\)\n* 07:03:06 - 1Password monitoring alerts for 5xx errors on auth start endpoint \\(caused by inability to obtain AWS IAM credentials\\) - pages authentication team, but alert recovers within minutes\n* 07:26:00 - 1Password monitoring alerts for inability to scale clusters, engineers begin investigating, Incident declared\n* 07:26:41- AWS confirms elevated error rates across multiple services\n* 07:49:06 - 1Password monitoring alerts for 5xx errors on auth start endpoint \\(caused by inability to obtain AWS IAM credentials\\)\n* 07:51:09 - AWS identifies DNS as the root cause, begins mitigation\n* 08:02:13 - 1Password suspends auto-scaling tooling to retain existing capacity\n* 09:27:33 - AWS reports significant recovery signs\n* 10:35:37 - AWS declares DNS issue fully mitigated, services recovering\n* 14:14:00-15:43:00 - AWS announced full recovery across all services; throttles EC2 launches\n* 16:42:49 - 1Password tooling and users start reporting 503s and inability to login due to volume of traffic\n* 16:50:00 - 1Password services restarted to reset and flush connections, prioritizing post-recovery traffic.\n* 20:53:00 - AWS resolves their incident\n* 20:55:00 - 1Password engineers overscale deployments for stability and overnight observation\n* Oct 21, 2025 - Incident resolved after confirmation of complete upstream recovery\n\n## How Was It Resolved?\n\n* **Mitigation Steps:** 1Password paused deployments and auto-management of cluster capacity to ensure enough capacity was available to serve users through peak access times. As demand outstripped available capacity, 1Password engineering reset the circuit breaker to allow additional connections to the service.\n* **Resolution Steps:** AWS announced system restoration and a reduction in throttling of EC2 API calls. To ensure sufficient capacity for peak traffic, 1Password engineers updated the required number of pods for core services the following business day and resumed auto-management of cluster capacity tooling. The following day, 1Password engineers resumed verification of the health of the systems, deployments, and auto-scaling of the services.\n* **Verification of Resolution:** Engineers observed monitoring systems and cluster management tooling logs to ensure system health.\n\n## **Root Cause Analysis**\n\n* **Root Cause Analysis:** The failures in AWS's internal network affected multiple AWS product APIs. This disruption directly impacted 1Password\u2019s ability to scale up infrastructure, deploy applications, and retrieve configuration data.\n* **Contributing Factors \\(if any\\):**\n\n * Third-party incident response services and paging services were affected by the AWS incident, which complicated communications.\n * Upstream customer IDPs were affected by the AWS outage, and returned errors that resulted in authentication failures.\n \n\n## What We Are Doing to Prevent Future Incidents\n\n* **Improve Incident Response:** Create additional backup protocols for when our incident response tooling is unavailable.\n* **Improve multi-service outage response:** Create strong break-glass runbooks in the event of a multi-service cloud provider outage.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "major",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-10-21T09:51:06.701-04:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-10-20T05:05:23.290-04:00",
 
467
  "body": "# Incident Postmortem - Degraded performance when accessing 1Password\n\n**Date of Incident:** 2025-09-26 \n**Time of Incident:** 4:20pm UTC - 5:39pm UTC \n**Service\\(s\\) Affected:** SSO, Web Sign In, Sign Up, Web Interface, CLI \n**Impact Duration:** ~60 minutes\n\n## Summary\n\nOn September 26, 2025 at 4:20 UTC 1Password\u2019s web interface and APIs experienced degraded performance for all customers in the US region. This was not a result of a security incident and customer data was not affected.\n\n## Impact on Customers\n\nDuring the duration of the incident:\n\n* **Web interface, Administration:** Customers experienced delays when accessing the 1Password web interface.\n* **Single Sign-on \\(SSO\\), Multi-factor Authentication \\(MFA\\):** Users with SSO or MFA enabled experienced delays, and in some cases failures to login.\n* **Command Line Interface \\(CLI\\):** CLI users faced increased latency and timeouts when attempting to access our web APIs.\n* **Browser Extension:** Users requiring web interface authentication experienced delays or failures.\n* **Number of Affected Customers \\(approximate\\):** ~30%\n* **Geographic Regions Affected:** [1password.com](http://1password.com) \\(US/Global\\)\n\n## What Happened?\n\nAt 4:20PM UTC and 5 PM UTC There were traffic bursts which caused extra load on one of our caches. This cache was under-provisioned to handle that spike of activity, which resulted in it exhausting available CPU. This caused cascading errors/latency which manifested in slow and failed requests.\n\n* **Timeline of Events \\(UTC\\):**\n\n * 2025-09-26 4:20pm: Spike in customer traffic began\n * 2025-09-26 4:29pm: Automated monitoring detects increased errors and latency\n * 2025-09-26 4:35pm: The team activates our incident protocol and begins investigation\n * 2025-09-26 4:58pm: The team decides to restart application servers\n * 2025-09-26 5:00pm: The servers have been restarted, service is still degraded, as a second traffic burst begins\n * 2025-09-26 5:18pm: Service starts to improve\n * 2025-09-26 5:25pm: The team detects increased load for the second time\n * 2025-09-26 5:33pm: The team restarts application servers again\n * 2025-09-26 5:39pm: Service is back to normal, team continues to investigate\n * 2025-09-26 7:26pm: Team has found the issue, and proceeds to upgrade cache instance size\n * 2025-09-26 7:49pm: Cache upgrade completed successfully\n * 2025-09-26 7:50pm: Team continues to monitor, performance has returned to nominal levels\n * 2025-09-26 8:24pm: Incident is marked as resolved\n \n* **Root Cause Analysis:**\n\n A code library installed in July introduced latency issues for cache connections. Authentication operations weren't properly rate-limited, allowing large traffic influxes. During peak traffic periods, the cache infrastructure was operating near maximum CPU capacity. The incident occurred when a burst of authentication traffic pushed the cache CPU utilization to 100%. The increased latency and CPU usage together directly caused the incident.\n\n\n* **Contributing Factors:**\n\n * Latency increase due to cache library version upgrade\n * Inadequate rate limiting allowed traffic bursts to go unchecked\n * Cache instance size is under-provisioned\n \n\n## How Was It Resolved?\n\n* **Mitigation Steps:** Restarting application servers temporarily mitigated the latency and errors, but the problems returned when traffic spiked again.\n* **Resolution Steps:** Increasing the instance size for the cache resolved the issue.\n* **Verification of Resolution:** The incident team tested the upgrade in a staging deployment before executing it in production. They then monitored metrics to confirm the system returned to normal levels.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Improve capacity planning for cache:** We will ensure our internal infrastructure is properly sized to handle current traffic volumes and accommodate future growth. We'll implement regular resource evaluations to maintain adequate capacity as our traffic increases. We will also implement proactive alerting systems that notify our teams when resource utilization approaches critical thresholds.\n* **Update library to a more performant version:** We will upgrade our caching library to the latest stable version to eliminate the current latency issues.\n* **Improve rate limiting for operations that triggered the traffic burst:** Enhancing our rate limiting system will significantly improve our ability to handle future traffic bursts.\n* **Timeline for Implementation:** Observability improvements have already been implemented, and we will complete the remaining work by the end of Q1, 2026.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\n\u200c\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-09-26T16:24:58.720-04:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-26T12:51:38.625-04:00",
 
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-09-25T13:22:01.362-04:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-25T11:43:45.006-04:00",
 
493
  "body": "# Incident Postmortem - Some customers are unable to interact with the admin console\n\n**Date of Incident:** 2025-09-24 \n\n**Time of Incident \\(UTC\\):** 02:27 - 17:16 \n\n**Service\\(s\\) Affected:** Admin console, Sign in \n\n**Impact Duration:** 36:49\n\n## Summary\n\nSome customers with certain account configurations were placed on a blocklist and presented with a 403 error page after accessing the admin console.\n\n## Impact on Customers\n\n* **Admin console:** Affected customers were presented with a 403 error page whenever they tried to interact with any of the admin console pages.\n* **Log in:** Affected customers were also unable to log in to the application.\n* **Number of Affected Customers \\(approximate\\):** 515\n* **Geographic Regions Affected \\(if applicable\\):** All regions\n\n## What Happened?\n\n* **Timeline of Events \\(UTC\\):**\n\n * Sep 24th 2:27am: Spike in application monitoring alerted engineers to increased rates of IP blocking\n * Sep 24th 3:00am: Cause identified as a change to requests in the application, which had been partially rolled out via a feature flag.\n * Sep 24th 4:03am: The feature flag was enabled to all customers which reduced the spike, but IP blocks continued throughout the day.\n * Sep 24th 10:03pm: Merged an application change to revert the change to prevent the issue reoccurring.\n * Sep 25th 5:03pm: The change was deployed with scheduled application release, error rate dropped off shortly after.\n \n* **Root Cause Analysis:** The issue was caused by GET requests to the Users API exceeding the URL length limit due to a recent change to append a list of UUIDs to the request parameters to resolve customer reported performance issues.\n* **Contributing factors:**\n\n * Requests were switched from GET to POST to prevent requests from exceeding the URL limit, however an issue with the feature flag configuration was causing UUIDs to be sent with the GET endpoint.\n * An underlying issue with the feature flag not resolving as expected in the application.\n \n\n## How Was It Resolved?\n\n* **Mitigation Steps:** Customers were manually removed from the blocklist at multiple points in time as we evaluated the root cause and worked to patch the root issue.\n* **Resolution Steps:** The issue was mitigated by removing UUIDs at the API level if a GET request is used. Additional logging has been added to identify the root cause of the feature flag configuration issue.\n* **Verification of Resolution:** We monitored our server logs to ensure that we did not observe any additional GET requests to the affected URL.\n\n## What We Are Doing to Prevent Future Incidents\n\n* **Audit additional admin console API requests:** We\u2019re performing a sweep of admin console API requests to ensure the utilization of POST requests with highly parameterized URLs.\n* **Remove the feature flag misconfiguration:** We\u2019re correcting the way the feature flag is configured to ensure consistent outcomes.\n\n## Next Steps and Communication\n\nNo action is required from our customers at this time.\n\n\u200c\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-09-24T00:10:05.235-04:00",
498
  "resolved_inferred": false,
499
  "started_at": "2025-09-23T23:00:42.664-04:00",
 
506
  "body": "# **Provisioning Invites could not be accepted**\n\n**Date of Incident:** 2025-09-23 \n**Time of Incident \\(UTC\\):** 17:18 - 00:46 \n**Service\\(s\\) Affected:** Sign Up \n**Impact Duration:** 7h 28m\n\n## **Summary**\n\nFor 7 hours and 28 minutes, 1Password Provisioning invites could not be accepted, presenting to the user as an invite expiry. Invites could not be accepted due to a web browser routing defect that was not caught during development, review, or release. First identified by customer reports approximately two and a half hours after release, the issue was escalated to development teams and an incident was immediately called. The root cause was identified as a defect introduced by a web client modification, and a fix was created, tested, and released. By 00:46 UTC, the fix was deployed to all environments and service was fully restored.\n\n## **Impact on Customers**\n\n* **Sign-up:** Provisioning invites could not be accepted.\n* **Number of Affected Customers \\(approximate\\):** 100% of provisioning invites could not be accepted\n* **Customer-facing impact**: Users clicking their invite links encountered a misleading \u2018Invite Expired\u2019 message.\n* **Geographic Regions Affected:** 1Password USA/Canada/EU/Enterprise\n\n## **What Happened?**\n\nA change to the web client contained a router defect that incorrectly rendered provisioning invites as expired. Users were presented with an error message that erroneously stated the invite was expired. The change responsible for introducing the defect was able to be released because it was not captured under automatic change notification rules, was lacking automated test coverage, and was not included in the set of manual tests.\n\n* **Timeline of Events \\(UTC\\):**\n\n * 17:18: 1Password Release containing defect\n * 19:53 \\(2 hours, 35 minutes later\\) First customer report\n * 20:49 \\(56 minutes later\\) Escalation to developer teams\n * 21:01: \\(12 minutes later\\) Incident called\n * 22:02: \\(1 hour, 1 minute later\\) Root cause identified\n * 22:29: \\(27 minutes later\\) Fix created and testing initiated\n * 23:49: \\(1 hour, 30 minutes later\\) Fix merged\n * 00:46: \\(57 minutes later\\) Fix released and service fully restored\n \n* **Root Cause Analysis:** A change modified the order in which key provisioning web routes were rendered. As a result, the route handling provisioning invitations failed to use the correct query parameters and the invite rendered as expired.\n* **Contributing Factors:** Automated tests on this endpoint do not exist. Manual testing missed testing the Provisioning routes. The modified code was not covered by automatic change notification rules to notify the Provisioning team. An existing bug that can fail the resending of invites was an initial red herring during the investigation.\n\n## **How Was It Resolved?**\n\n* **Resolution Steps:** The defect in the 1Password web client was corrected so provisioning invites would render correctly.\n* **Verification of Resolution:** 1Password engineering tested the changes and validated that the functionality was restored, as well as verifying that requests for the affected endpoints were successful after the fix was deployed.\n\n## **What We Are Doing to Prevent Future Incidents**\n\n* **Improve automated tests:** We are enhancing our automated tests for the Provisioning Invite routes.\n* **Expand automatic change notifications:** Expanding coverage of automatic change notification rules for areas of code owned by the Provisioning team.\n\n## **Next Steps and Communication**\n\n* No action is required from our customers at this time. Existing invites do not need to be resent and may be accepted.\n* If you are still experiencing issues, please contact our support team at [support@1password.com](mailto:support@1password.com). \n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-09-23T22:07:03.833-04:00",
511
  "resolved_inferred": false,
512
  "started_at": "2025-09-23T17:24:26.152-04:00",
 
519
  "body": "We have confirmed resolution of this issue and this incident is now resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-09-19T14:17:59.181-04:00",
524
  "resolved_inferred": false,
525
  "started_at": "2025-09-18T16:19:16.670-04:00",
 
532
  "body": "Our provider has deployed a fix. Error rates have returned to normal. This incident is now resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-09-18T13:08:47.709-04:00",
537
  "resolved_inferred": false,
538
  "started_at": "2025-09-18T10:48:41.437-04:00",
 
545
  "body": "# Performance Degradation\n\n**Date of Incident:** 2025-09-03 \n**Time of Incident \\(UTC\\):** 11:06 - 12:07 \n**Service\\(s\\) Affected:** All APIs \n**Impact Duration:** 61 minutes\n\n## Summary\n\nFor 61 minutes on the morning of September 3rd, 2025, all 1Password APIs in the US/Global environment had degraded performance or returned an error for approximately 20% of requests. 92% of the impact was mitigated within 13 minutes at 11:19 by automation scaling up infrastructure. By 12:06 a manual restart of the remaining infrastructure completed mitigation. A permanent fix was implemented and deployed to prevent the issue from reoccurring.\n\n## Impact on Customers\n\n* **APIs:** High latency, or a 500 Internal Server Error.\n* **Number of Affected Customers:** 20% of all requests returned errors for 13 minutes, 1% thereafter.\n* **Geographic Regions Affected \\(if applicable\\):** 1Password USA/Global\n\n## What Happened?\n\n* **Timeline of Events \\(UTC\\):**\n\n * 11:05: A customer started a stream of an unusually high volume of requests to an API with sub-optimal performance.\n * 11:06: Some servers started consuming abnormally high memory, causing slow response times and high error rates.\n * 11:19: Automation scaled up infrastructure to service additional load\n * 11:30: Increased errors trigger escalation, on-call engineer begins investigation\n * 11:51: Engineers declare an incident and alert response teams\n * 12:02: Response team begins restarting affected servers.\n * 12:07: All servers completed restarts, and error rates returned to normal levels\n \n* **Root Cause Analysis:** A poorly performing cache operation was triggered repeatedly in a short period of time across multiple servers, leading directly to greatly delayed responses.\n\n## How Was It Resolved?\n\n* **Mitigation Steps:** Automatic instance scaling restored over 98% of operational capacity after 13 minutes. Full capacity was restored through manual intervention\n* **Resolution Steps:** We refactored the poorly performing query.\n* **Verification of Resolution:** We tested the affected API to confirm refactoring of query produced the desired performance improvement. We deployed the fix and monitored it for 24 hours to assert the issue was resolved.\n\n## What We Are Doing to Prevent Future Incidents\n\n* We are auditing services for sub-optimal query performance.\n\n## Next Steps and Communication\n\n* No action is required from our customers at this time.\n\n\u200c\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely,\n\nThe 1Password Team",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "minor",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-09-03T07:00:00.000-04:00",
550
  "resolved_inferred": false,
551
  "started_at": "2025-09-03T07:00:00.000-04:00",
 
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2025-08-18T18:53:58.892-04:00",
563
  "resolved_inferred": false,
564
  "started_at": "2025-08-18T17:36:12.219-04:00",
 
571
  "body": "## **Incident Postmortem - Sign-in Service Degradation**\n\n* **Date of Incident:** 2025-08-05\n* **Time of Incident \\(UTC\\):** 20:20 - 21:20\n* **Service\\(s\\) Affected:** Sign-in, Web Application, Command Line Interface \\(CLI\\), Single Sign On \\(SSO\\), API\u2019s\n* **Impact Duration:** 1 hour\n\n### **Summary**\n\nOn August 5, 2025, 1Password experienced a service degradation that impacted customers' ability to sign in and access the web application. The incident was triggered during a planned architectural improvement when a misconfigured rollback attempt caused an overload of traffic and a subsequent database connection bottleneck. The issue was resolved by correcting the misconfiguration and restarting the web application servers, fully restoring service.\n\n### **Impact on Customers**\n\nDuring the service disruption, some customers experienced degraded performance when accessing their 1Password vaults and signing in.\n\n* **Sign-in Issues**: Customers may have experienced sign-in slowness or timeouts.\n* **Error Messages**: Customers may have seen error messages when attempting to sign in, such as \"Can't sign in\", \"Failed to determine sign in methods for email\", or \"Upstream connect error\".\n* **Vault Access**: Some customers experienced degraded performance when accessing their 1Password vaults.\n* **Geographic Regions Affected:** USA/Global\n\n### **What Happened?**\n\nThe incident was part of ongoing improvements to the 1Password infrastructure and was not the result of a security incident. Customer data was not affected.\n\n**Timeline of Events \\(UTC\\):**\n\n* **17:12**: A planned, phased rollout of an architectural improvement to authentication systems begins.\n* **18:20**: Engineers monitoring the rollout begin to observe higher latency during sign-in for a small subset of accounts.\n* **20:17**: A rollback of the change is initiated. An error in the rollback configuration sends a high volume of traffic to the new code path, causing a database connection bottleneck. Engineers observing the deployment immediately observe service impact.\u00a0\n* **20:21**: A corrective action is deployed to revert the system to its previous state before the misconfigured rollback.\n* **20:39**: While impact is still being observed, a failover from the primary database to a secondary database is initiated. This action has no effect.\u00a0\n* **20:58**: A restart of the service that manages incoming traffic to our services is initiated to reset connections.\n* **21:13**: A rolling restart of the web application servers is initiated.\n* **21:20**: Service is fully restored for all customers.\n\n**Root Cause Analysis:** The root cause was an error in the configuration of an attempted rollback. This misconfiguration incorrectly routed a high volume of sign-in traffic through a new, slower code path, which created a bottleneck of connections to our primary database and made the web application unresponsive.\n\n### **How Was It Resolved?**\n\n**Resolution Steps:** The issue was fully resolved through two key actions:\n\n1. The rollback misconfiguration was identified and corrected, which stopped traffic from flowing to the problematic new code.\n2. A rolling restart of the web application servers was performed to clear the backlog of stuck database connections.\n\n**Verification of Resolution:** Monitoring systems were closely observed for 30 minutes to ensure error rates returned to normal.\n\n### **What We Are Doing to Prevent Future Incidents**\n\nWe are working to implement the following improvements:\n\n* **Improve configuration testing**: We will improve testing procedures of configuration updates and their rollbacks prior to being pushed to production.\n* **Improve our deployment tooling**: We will add additional validation to our traffic management tools to prevent similar configuration errors.\n* **Review our incident response procedures**: We have updated the runbook used to respond to this type of incident with guidance that will enable faster recovery.\n* **Enhance our monitors**: We will add more specific alerts that will help us more quickly distinguish between different application tiers, allowing for faster diagnosis and time to resolution.\n\n### **Next Steps and Communication**\n\nNo action is required from our customers. 1Password applications are designed to be resilient, with local copies of vault data always available on customer devices, even without a connection to the 1Password service.\n\nIf you are still experiencing issues, please contact our support team.\n\nWe are committed to providing a reliable and stable service, and we are taking the necessary steps to learn from this event and prevent it from happening again. Thank you for your understanding.\n\nSincerely, The 1Password Team",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-08-05T17:59:54.829-04:00",
576
  "resolved_inferred": false,
577
  "started_at": "2025-08-05T16:46:48.030-04:00",
api/v/3stepit.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "3stepit",
4
  "platform": "statuspage",
5
  "status_url": "https://status.3stepit.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "unknown",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "3stepit",
4
  "platform": "statuspage",
5
  "status_url": "https://status.3stepit.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "unknown",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/ably.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "ably",
4
  "platform": "statuspage",
5
  "status_url": "https://status.ably.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-28T13:33:07.563Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T12:08:59.848Z",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-20T20:24:39.725Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-20T19:29:36.560Z",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-20T19:10:12.011Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-20T19:07:30.168Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-02-17T10:32:02.145Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-02-17T10:19:49.762Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has now been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-02-14T06:05:15.720Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-02-14T05:57:02.135Z",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-01-21T19:52:33.695Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-01-21T18:11:23.300Z",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-12-11T18:59:46.298Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-11T18:36:15.932Z",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2025-12-05T09:18:05.254Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-12-05T08:59:03.822Z",
@@ -116,7 +116,7 @@
116
  "body": "The incident is now resolved. The elevated protocol adaptor error rate affected EU regions for 36 minutes from 11.25am-12.01pm UTC, for 15 minutes in US regions from 11.50am-12.05pm UTC, and for 14 minutes in AP regions from 11.48am-12.02pm UTC.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2025-11-25T12:11:34.496Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-11-25T11:38:38.898Z",
@@ -129,7 +129,7 @@
129
  "body": "# Summary of incident affecting the Ably production service on 28-29 October - investigation and conclusions\n\n## Overview\n\nThere was an incident affecting Ably's service between 28 and 29 October 2025, which affected the delivery of webhooks. The impact of the incident lasted from 1134 on 28 October to 0936 on 29 October \\(all times UTC\\). The incident occurred as a result of the deployment of new webhook functionality that was incompatible with many already-configured webhook rules.\n\nNow we have a good understanding of the underlying problem, the various factors that led to that having customer impact, and the effectiveness of our response in this case.\n\n## Background\n\nAbly operates a number of production clusters for its service around the globe. There is a main production cluster that services the majority of customer accounts, plus a small number of dedicated clusters for specific accounts. Each of the clusters has a presence in multiple regions in a globally federated system.\n\n### Ably integration rules\n\nAbly processes messages that are published on channels, and directs those to realtime subscribers on those channels, and also directs them to other targets as configured by integration rules. Multiple targets are supported for egress integration rules, including message queues \\(Kafka, AMQP\\) and generic HTTP endpoints \\(webhooks\\).\n\nRules are configured via a control plane which supports:\n\n* direct interactive \\(\"click-ops\"\\) configuration in the Ably dashboard;\n* a [Control API](https://ably.com/docs/api/control-api);\n* a [Terraform Provider](https://ably.com/integrations/ably-terraform-provider) which acts through the Control API.\n\nThe source of truth for integration rule definitions is Ably's core \"realtime\" platform, and the other services \\(the website and control API service\\) obtain access to that via an internal provisioning API.\n\nIntegration rule definitions comprise some attributes that are generic \\(such as `channelFilter` that specifies which channels the rule applies to\\), and some that are specific to each type of integration rule target \\(such as the target endpoint, credentials, and any protocol-specific attributes\\). Some generic attributes - ie attributes that are capable of having a meaning for multiple rule types - are not universally supported, since the evolution of rule features is based on adoption and priority. As a result, the schema for integration rule definitions contains multiple optional generic attributes as well as a wide range of type-specific attributes.\n\nOne generic feature is an option that enables a custom set of trust anchors \\(TLS certificates\\) to be configured for a rule; this is to support integrations that target TLS endpoints that have a self-signed certificate rather than certificates issued by a public Certificate Authority \\(CA\\). This feature is used by customers having self-hosted endpoints, either as part of development/CI infrastructure, or as internally-facing production services where the operational effort of maintaining a certificate from a public CA is not justified.\n\nAt the time of the incident custom trust anchors were supported for Apache Pulsar and Kafka rules, and support had just been added for webhooks.\n\n### Ably's service deployment process\n\nAbly adopts a staggered deployment approach whereby each change is deployed gradually, minimising the adverse impact of any regression that might exist in new software versions having escaped all prior test phases. Changes are typically deployed on a weekly basis; usually in the main \\(multi-tenanted\\) cluster this means that changes are deployed to the ap-southeast-2 \\(Sydney\\) region first, and error rates monitored, before deploying to the remaining regions starting the following day. However, if a deploy needs to be expedited for any reason, subsequent regions can be deployed after a change has been in ap-southeast-2 for only a few hours.\n\nMost monitoring is automated; metrics are gathered for a wide range of service health metrics, including the rates of logged error events, and the rate of error API responses. When error metrics exceed a threshold then on-call engineers are paged to investigate.\n\nSince the majority of Ably's infrastructure comprises immutable EC2 instances, any deploy consists of deploying new instances with the new software version in parallel with retirement of superseded instances. For a normal deploy this process happens over the course of several hours so that the number of instances being retired at any given time is small, minimising any impact of the update on existing traffic. If a deploy needs to be accelerated, such as if making an emergency rollback, then deployment would more typically involve deploying a full complement of replacement instances immediately, followed by termination of old instances at a rate that reflects the urgency of the operation. Immediate and abrupt termination of multiple instances simultaneously leads to a greater risk of loss of ephemeral channel state, so even in accelerated rollbacks the preference is for old instances to be terminated gradually so that there is an orderly shedding of load so as to avoid any data loss.\n\n## As it happened\n\nA change to add support for custom trust anchors was implemented, and this change was part of a set of changes deployed in a staggered deployment starting on 28 October. This happened in ap-southeast-2 from 1134 and, since this change set also included a fix for an unrelated problem, it was expedited and started in other regions from around 1500.\n\nStarting at 1940 on 28 October there was a handful of customer reports of a problem with webhook delivery. There were two independent customer reports of issues on 28 October and a handful of reports overnight.\n\nAt 0731 on 29 October Ably's customer support team escalated the problem reports to Ably's engineering team for investigation. At 0745 an incident was declared, on-call engineers were paged and investigation started.\n\nThe problem was determined to be a regression introduced in the previous day's deploy.\n\nAt 0746 a rollback process was initiated to revert the changes. Rollback was initiated first in ap-southeast-2. At 0811 rollback was initiated for all regions and dedicated clusters that had received the changes.\n\nThe rollback completed at 0936 and errors dropped to zero.\n\n## Investigation\n\nThe investigation aimed to understand:\n\n* the cause of failed webhook invocations;\n* how Ably's testing had failed to detect the regression;\n* how Ably's monitoring had failed to detect the regression;\n* the effectiveness of the response, including the time taken to respond following the first customer problem reports.\n\nThe conclusions of the investigation are summarised below.\n\n### The cause of failed webhook invocations\n\nThe new code that caused the problem was adding support for custom trust anchors for webhooks. This code would look in the rule configuration for a configured set of trust anchors and, if present, use those instead of the system set of trust anchors for public CAs. The problem was caused by the fact that a significant number of preexisting rule definitions already had an empty set of trust anchors configured. The new code then used that empty set instead of the default set and failed to verify the certificate chain for any TLS endpoint.\n\nThese failures were logged internally with a severity that classifies the event as a client configuration error rather than a system error.\n\nThe presence of the empty trust anchor set in existing rule definitions was due to a long-standing behaviour in the web \\(dashboard and control API\\) services that create and update rules via the realtime platform's provisioning API. When custom trust anchor support was first added for Pulsar rules \\(in November 2021\\), the set of custom trust anchors became a generic rule attribute; but the web service would configure an empty set instead of a true zero value when custom trust anchors were unset. This meant that any rules that had been created since November 2021, even for types that did not initially support custom trust anchors, would have an empty set configured.\n\nRemedial actions identified in this area are as follows.\n\n**Fix the immediate regression.** As an interim behaviour, interpret an empty custom trust anchor array as if custom trust anchors are unset \\(and so use the default trust anchors\\).\n\n**Correct web service behaviour.** Update the web service so that a true zero value is set instead of an empty array when custom anchors are not set.\n\n**Correct the configuration of existing rules.** Perform a database update for all existing rule definitions that have an empty array configured.\n\n### The failure of tests to detect the regression\n\nThe relevant tests are a combination of unit tests and integration tests within the test suite of the realtime platform.\n\nUnit test coverage includes test coverage of all webhook configuration options \\(and new tests were included with the deployed change\\), plus tests for different endpoint behaviours \\(HTTP 1 vs HTTP/2 for example\\). Unit tests mock different parts of the surrounding code and system in order to have tests that are as targeted as possible.\n\nIntegration tests include full end-to-end tests that create integration rules via the provisioning API that point to a range of endpoints existing as part of the CI system.\n\nThe reason that none of these tests identified the problem is that none used the configuration in the same way as the web service; in particular, any rule that did not have custom trust anchors would be configured with a null entry. There was no expectation in the tests that an empty set should be interpreted as having no custom configuration.\n\nThere was no integration test coverage of the end-to-end behaviour when rules are created via the web service.\n\nRemedial actions identified in this area are as follows.\n\n**Improve web service testing of integrations.** This should at least include:\n\n* create web service unit tests that verify that an unset custom trust anchor configuration results in a zero value being configured.\n* create web service integration tests that verify end-to-end behaviour involving creation of rules via the web service, with and without custom trust anchors set.\n\n### The failure of monitoring to detect the regression\n\nAbly monitors a wide range of service metrics and alerts relevant engineering teams when those metrics indicate a service problem. Monitored metrics include errors logged internally whilst servicing customer traffic, the rate of error responses to customer requests, and the rate of errors or failures in traffic that is generated by Ably specifically for service monitoring. For this last category, Ably operates a series of \"quality of service\", or QoS, traffic generators that exercise a range of service functionality, so certain classes of failure relating to deployment can be identified that would not be identifiable via CI.\n\nErrors - both those logged internally and customer-visible error responses - can be classified broadly into:\n\n* bad requests - that is, operations that fail because the arguments or parameters of the request are invalid. When these errors are associated with an error code, it is typically in the 4xx range - these include general bad requests, plus authentication and authorisation failures;\n* internal errors - that is, errors that arise performing some operation that ought to succeed, but fails because of an issue \\(eg an unexpected exception, a failure to communicate over the network, or an assertion failure\\). When these errors are associated with an error code, it is generally in the 5xx range.\n\nA high rate of internal errors - either in our internal logs, or in customer-visible responses - is an indication of a problem with the service. A high rate of bad requests is more typically a problem on the customer side; an application is attempting operations that cannot succeed.\n\nAll 5xx \\(internal error\\) metrics are monitored and alerts are generated when they exceed a threshold indicating a problem.\n\nMany 4xx \\(bad request\\) metrics are monitored but in most situations these do not generate alerts. This is for several reasons:\n\n* most are not an indication of a system problem; there is simply some invalid operation being attempted by a client;\n* all public endpoints are subject to a very high rate of spurious requests that fail authentication and authorisation checks, so the general rate of 4xx errors is high.\n\nSimilarly, problems with invocation of a webhook \\(or other rule target\\) are usually a result of misconfiguration of the rule, or unavailability of the target endpoint, and these are classified with a 4xx status code. There is a material background level of such errors.\n\nGiven the very high rate of background 4xx errors on external endpoints, it is generally difficult to identify any pattern on those endpoints that is indicative of a system problem.\n\nNotwithstanding this, all Ably Enterprise accounts have alerts set up both for 4xx and 5xx error metrics. 4xx alerts do not generally page an engineer out-of-hours, but both engineering and customer success teams get notified when there is an unexpected elevated rate of 4xx errors for an Enterprise customer. The configuration of those accounts within Ably's monitoring and alerting systems is added when that customer is onboarded as an enterprise customer.\n\nIn this incident the overall increase in rule invocation failures was not significant in comparison with the normal ambient background error rate so, based on those metrics, there was no clear signal of there being a problem, and it was not sufficient to cross the alerting threshold on any existing enterprise accounts. Many customers with the highest usage volumes had rules created before November 2021, which were unaffected by the problem.\n\nAt the time of the incident, QoS monitoring simulated traffic for some integrations but not webhooks.\n\nRemedial actions identified in this area are as follows.\n\n**Improve the ability in metrics and alerts for integration rules to discriminate between Ably problems and end-user problems.** Although most errors are a result of configuration problems, or problems in end-user infrastructure, it is still clearly possible for Ably regressions to also generate errors. We need to have more intelligent metrics and alerts that identify such occasions without creating an unsustainable number of false-positives. One possibility is to create alerts based on individual metrics labelled by rule type, to ensure that an increase in error rate for an individual rule type is alerted, even if that increase is not a material fraction of errors across all rule types. Another possibility is to correlate error levels with deploy events, or with software versions, so if a variation in error rate is correlated with a code change it is more likely to trigger an alert.\n\n**Add webhook tests to QoS monitoring.** Continuous testing in a production setting of simulated traffic should be extended to include webhooks.\n\n### The effectiveness of the response\n\nFrom the first customer impact of this issue to the final resolution was 22 hours. This is far too long.\n\nAbly's response in this incident led to delays at multiple stages:\n\n* from the time of the problematic code being deployed to the first reported issue was around 8 hours;\n* from the first report to raising an incident was around 12 hours;\n* the full rollback, from the time that an incident was declared, was nearly 2 hours.\n\nOf course, had there been suitable alerting for the production problem we would have reacted sooner; but this timeline reflects the fact that even with the information we did have, the response was slow. This was due to a combination of factors:\n\n* the reports received were all received outside of business hours and, given that the customers raising those reports were not enterprise customers, there was no out-of-hours process to review them;\n* there was some delay before the support team correlated multiple reports to conclude that there was a problem with the delivery of webhooks;\n* the rollback process was comparatively slow, deliberately avoiding a more disruptive abrupt rollback since the issue had impact for a relatively small number of customers.\n\nThe remedial actions in this area are as follows.\n\n**Review processes for handling and escalating issue reports out-of-hours.** Customers on lower support tiers can legitimately expect slower response times to deal with any individual issues or questions they have, but when an Ably problem arises that affects them there is no means for the relevant response team to be made aware. We will review our processes with the aim of improving support in these situations.\n\n## Conclusion\n\nThe service issues were the direct result of a regression in the Ably service - specifically, an incompatibility between a new feature \\(custom trust anchors for webhooks\\) and the existing state of rule configurations.\n\nThe cause of the extended duration of the incident was that the classification and rate of failed delivery events resulted in no alert being generated, which meant that Ably was not aware of the ongoing problem until it was reported by customers. Although it is difficult to monitor 4xx error rates effectively, because of the high background level of such errors, there is clearly a need to improve on the current situation where Ably regressions can go undetected. There was significant additional delay in triggering a response because the reports were received on a support channel that was not monitored out of business hours.\n\nOnce alerted to the problem, Ably initiated the response quickly, but the operational nature of the rollback meant that it took nearly two hours until it was completed.\n\nWe take service continuity very seriously, and this incident represents another opportunity to learn and improve the level of service we are committed to providing for our customers. We are sorry for the disruption that was experienced in this instance, and are committed to identifying and implementing remedial actions so that we eliminate the risk of similar failures in the future.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-10-29T09:42:56.242Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-10-29T08:57:58.445Z",
@@ -142,7 +142,7 @@
142
  "body": "Customers may be experiencing connectivity issues affecting our website (ably.com), customer dashboards, the Control API (control.ably.net), the Ably blog and documentation.\n\nOur realtime services are not affected by this issue at this time.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-10-09T14:10:08.000Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-10-09T14:10:08.000Z",
@@ -155,7 +155,7 @@
155
  "body": "The incident has been resolved",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-08-13T13:25:12.428Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-08-13T12:47:25.642Z",
 
3
  "slug": "ably",
4
  "platform": "statuspage",
5
  "status_url": "https://status.ably.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-28T13:33:07.563Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T12:08:59.848Z",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-20T20:24:39.725Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-20T19:29:36.560Z",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-20T19:10:12.011Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-20T19:07:30.168Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-02-17T10:32:02.145Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-02-17T10:19:49.762Z",
 
64
  "body": "This incident has now been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-02-14T06:05:15.720Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-02-14T05:57:02.135Z",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-01-21T19:52:33.695Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-01-21T18:11:23.300Z",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-12-11T18:59:46.298Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-11T18:36:15.932Z",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2025-12-05T09:18:05.254Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-12-05T08:59:03.822Z",
 
116
  "body": "The incident is now resolved. The elevated protocol adaptor error rate affected EU regions for 36 minutes from 11.25am-12.01pm UTC, for 15 minutes in US regions from 11.50am-12.05pm UTC, and for 14 minutes in AP regions from 11.48am-12.02pm UTC.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2025-11-25T12:11:34.496Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-11-25T11:38:38.898Z",
 
129
  "body": "# Summary of incident affecting the Ably production service on 28-29 October - investigation and conclusions\n\n## Overview\n\nThere was an incident affecting Ably's service between 28 and 29 October 2025, which affected the delivery of webhooks. The impact of the incident lasted from 1134 on 28 October to 0936 on 29 October \\(all times UTC\\). The incident occurred as a result of the deployment of new webhook functionality that was incompatible with many already-configured webhook rules.\n\nNow we have a good understanding of the underlying problem, the various factors that led to that having customer impact, and the effectiveness of our response in this case.\n\n## Background\n\nAbly operates a number of production clusters for its service around the globe. There is a main production cluster that services the majority of customer accounts, plus a small number of dedicated clusters for specific accounts. Each of the clusters has a presence in multiple regions in a globally federated system.\n\n### Ably integration rules\n\nAbly processes messages that are published on channels, and directs those to realtime subscribers on those channels, and also directs them to other targets as configured by integration rules. Multiple targets are supported for egress integration rules, including message queues \\(Kafka, AMQP\\) and generic HTTP endpoints \\(webhooks\\).\n\nRules are configured via a control plane which supports:\n\n* direct interactive \\(\"click-ops\"\\) configuration in the Ably dashboard;\n* a [Control API](https://ably.com/docs/api/control-api);\n* a [Terraform Provider](https://ably.com/integrations/ably-terraform-provider) which acts through the Control API.\n\nThe source of truth for integration rule definitions is Ably's core \"realtime\" platform, and the other services \\(the website and control API service\\) obtain access to that via an internal provisioning API.\n\nIntegration rule definitions comprise some attributes that are generic \\(such as `channelFilter` that specifies which channels the rule applies to\\), and some that are specific to each type of integration rule target \\(such as the target endpoint, credentials, and any protocol-specific attributes\\). Some generic attributes - ie attributes that are capable of having a meaning for multiple rule types - are not universally supported, since the evolution of rule features is based on adoption and priority. As a result, the schema for integration rule definitions contains multiple optional generic attributes as well as a wide range of type-specific attributes.\n\nOne generic feature is an option that enables a custom set of trust anchors \\(TLS certificates\\) to be configured for a rule; this is to support integrations that target TLS endpoints that have a self-signed certificate rather than certificates issued by a public Certificate Authority \\(CA\\). This feature is used by customers having self-hosted endpoints, either as part of development/CI infrastructure, or as internally-facing production services where the operational effort of maintaining a certificate from a public CA is not justified.\n\nAt the time of the incident custom trust anchors were supported for Apache Pulsar and Kafka rules, and support had just been added for webhooks.\n\n### Ably's service deployment process\n\nAbly adopts a staggered deployment approach whereby each change is deployed gradually, minimising the adverse impact of any regression that might exist in new software versions having escaped all prior test phases. Changes are typically deployed on a weekly basis; usually in the main \\(multi-tenanted\\) cluster this means that changes are deployed to the ap-southeast-2 \\(Sydney\\) region first, and error rates monitored, before deploying to the remaining regions starting the following day. However, if a deploy needs to be expedited for any reason, subsequent regions can be deployed after a change has been in ap-southeast-2 for only a few hours.\n\nMost monitoring is automated; metrics are gathered for a wide range of service health metrics, including the rates of logged error events, and the rate of error API responses. When error metrics exceed a threshold then on-call engineers are paged to investigate.\n\nSince the majority of Ably's infrastructure comprises immutable EC2 instances, any deploy consists of deploying new instances with the new software version in parallel with retirement of superseded instances. For a normal deploy this process happens over the course of several hours so that the number of instances being retired at any given time is small, minimising any impact of the update on existing traffic. If a deploy needs to be accelerated, such as if making an emergency rollback, then deployment would more typically involve deploying a full complement of replacement instances immediately, followed by termination of old instances at a rate that reflects the urgency of the operation. Immediate and abrupt termination of multiple instances simultaneously leads to a greater risk of loss of ephemeral channel state, so even in accelerated rollbacks the preference is for old instances to be terminated gradually so that there is an orderly shedding of load so as to avoid any data loss.\n\n## As it happened\n\nA change to add support for custom trust anchors was implemented, and this change was part of a set of changes deployed in a staggered deployment starting on 28 October. This happened in ap-southeast-2 from 1134 and, since this change set also included a fix for an unrelated problem, it was expedited and started in other regions from around 1500.\n\nStarting at 1940 on 28 October there was a handful of customer reports of a problem with webhook delivery. There were two independent customer reports of issues on 28 October and a handful of reports overnight.\n\nAt 0731 on 29 October Ably's customer support team escalated the problem reports to Ably's engineering team for investigation. At 0745 an incident was declared, on-call engineers were paged and investigation started.\n\nThe problem was determined to be a regression introduced in the previous day's deploy.\n\nAt 0746 a rollback process was initiated to revert the changes. Rollback was initiated first in ap-southeast-2. At 0811 rollback was initiated for all regions and dedicated clusters that had received the changes.\n\nThe rollback completed at 0936 and errors dropped to zero.\n\n## Investigation\n\nThe investigation aimed to understand:\n\n* the cause of failed webhook invocations;\n* how Ably's testing had failed to detect the regression;\n* how Ably's monitoring had failed to detect the regression;\n* the effectiveness of the response, including the time taken to respond following the first customer problem reports.\n\nThe conclusions of the investigation are summarised below.\n\n### The cause of failed webhook invocations\n\nThe new code that caused the problem was adding support for custom trust anchors for webhooks. This code would look in the rule configuration for a configured set of trust anchors and, if present, use those instead of the system set of trust anchors for public CAs. The problem was caused by the fact that a significant number of preexisting rule definitions already had an empty set of trust anchors configured. The new code then used that empty set instead of the default set and failed to verify the certificate chain for any TLS endpoint.\n\nThese failures were logged internally with a severity that classifies the event as a client configuration error rather than a system error.\n\nThe presence of the empty trust anchor set in existing rule definitions was due to a long-standing behaviour in the web \\(dashboard and control API\\) services that create and update rules via the realtime platform's provisioning API. When custom trust anchor support was first added for Pulsar rules \\(in November 2021\\), the set of custom trust anchors became a generic rule attribute; but the web service would configure an empty set instead of a true zero value when custom trust anchors were unset. This meant that any rules that had been created since November 2021, even for types that did not initially support custom trust anchors, would have an empty set configured.\n\nRemedial actions identified in this area are as follows.\n\n**Fix the immediate regression.** As an interim behaviour, interpret an empty custom trust anchor array as if custom trust anchors are unset \\(and so use the default trust anchors\\).\n\n**Correct web service behaviour.** Update the web service so that a true zero value is set instead of an empty array when custom anchors are not set.\n\n**Correct the configuration of existing rules.** Perform a database update for all existing rule definitions that have an empty array configured.\n\n### The failure of tests to detect the regression\n\nThe relevant tests are a combination of unit tests and integration tests within the test suite of the realtime platform.\n\nUnit test coverage includes test coverage of all webhook configuration options \\(and new tests were included with the deployed change\\), plus tests for different endpoint behaviours \\(HTTP 1 vs HTTP/2 for example\\). Unit tests mock different parts of the surrounding code and system in order to have tests that are as targeted as possible.\n\nIntegration tests include full end-to-end tests that create integration rules via the provisioning API that point to a range of endpoints existing as part of the CI system.\n\nThe reason that none of these tests identified the problem is that none used the configuration in the same way as the web service; in particular, any rule that did not have custom trust anchors would be configured with a null entry. There was no expectation in the tests that an empty set should be interpreted as having no custom configuration.\n\nThere was no integration test coverage of the end-to-end behaviour when rules are created via the web service.\n\nRemedial actions identified in this area are as follows.\n\n**Improve web service testing of integrations.** This should at least include:\n\n* create web service unit tests that verify that an unset custom trust anchor configuration results in a zero value being configured.\n* create web service integration tests that verify end-to-end behaviour involving creation of rules via the web service, with and without custom trust anchors set.\n\n### The failure of monitoring to detect the regression\n\nAbly monitors a wide range of service metrics and alerts relevant engineering teams when those metrics indicate a service problem. Monitored metrics include errors logged internally whilst servicing customer traffic, the rate of error responses to customer requests, and the rate of errors or failures in traffic that is generated by Ably specifically for service monitoring. For this last category, Ably operates a series of \"quality of service\", or QoS, traffic generators that exercise a range of service functionality, so certain classes of failure relating to deployment can be identified that would not be identifiable via CI.\n\nErrors - both those logged internally and customer-visible error responses - can be classified broadly into:\n\n* bad requests - that is, operations that fail because the arguments or parameters of the request are invalid. When these errors are associated with an error code, it is typically in the 4xx range - these include general bad requests, plus authentication and authorisation failures;\n* internal errors - that is, errors that arise performing some operation that ought to succeed, but fails because of an issue \\(eg an unexpected exception, a failure to communicate over the network, or an assertion failure\\). When these errors are associated with an error code, it is generally in the 5xx range.\n\nA high rate of internal errors - either in our internal logs, or in customer-visible responses - is an indication of a problem with the service. A high rate of bad requests is more typically a problem on the customer side; an application is attempting operations that cannot succeed.\n\nAll 5xx \\(internal error\\) metrics are monitored and alerts are generated when they exceed a threshold indicating a problem.\n\nMany 4xx \\(bad request\\) metrics are monitored but in most situations these do not generate alerts. This is for several reasons:\n\n* most are not an indication of a system problem; there is simply some invalid operation being attempted by a client;\n* all public endpoints are subject to a very high rate of spurious requests that fail authentication and authorisation checks, so the general rate of 4xx errors is high.\n\nSimilarly, problems with invocation of a webhook \\(or other rule target\\) are usually a result of misconfiguration of the rule, or unavailability of the target endpoint, and these are classified with a 4xx status code. There is a material background level of such errors.\n\nGiven the very high rate of background 4xx errors on external endpoints, it is generally difficult to identify any pattern on those endpoints that is indicative of a system problem.\n\nNotwithstanding this, all Ably Enterprise accounts have alerts set up both for 4xx and 5xx error metrics. 4xx alerts do not generally page an engineer out-of-hours, but both engineering and customer success teams get notified when there is an unexpected elevated rate of 4xx errors for an Enterprise customer. The configuration of those accounts within Ably's monitoring and alerting systems is added when that customer is onboarded as an enterprise customer.\n\nIn this incident the overall increase in rule invocation failures was not significant in comparison with the normal ambient background error rate so, based on those metrics, there was no clear signal of there being a problem, and it was not sufficient to cross the alerting threshold on any existing enterprise accounts. Many customers with the highest usage volumes had rules created before November 2021, which were unaffected by the problem.\n\nAt the time of the incident, QoS monitoring simulated traffic for some integrations but not webhooks.\n\nRemedial actions identified in this area are as follows.\n\n**Improve the ability in metrics and alerts for integration rules to discriminate between Ably problems and end-user problems.** Although most errors are a result of configuration problems, or problems in end-user infrastructure, it is still clearly possible for Ably regressions to also generate errors. We need to have more intelligent metrics and alerts that identify such occasions without creating an unsustainable number of false-positives. One possibility is to create alerts based on individual metrics labelled by rule type, to ensure that an increase in error rate for an individual rule type is alerted, even if that increase is not a material fraction of errors across all rule types. Another possibility is to correlate error levels with deploy events, or with software versions, so if a variation in error rate is correlated with a code change it is more likely to trigger an alert.\n\n**Add webhook tests to QoS monitoring.** Continuous testing in a production setting of simulated traffic should be extended to include webhooks.\n\n### The effectiveness of the response\n\nFrom the first customer impact of this issue to the final resolution was 22 hours. This is far too long.\n\nAbly's response in this incident led to delays at multiple stages:\n\n* from the time of the problematic code being deployed to the first reported issue was around 8 hours;\n* from the first report to raising an incident was around 12 hours;\n* the full rollback, from the time that an incident was declared, was nearly 2 hours.\n\nOf course, had there been suitable alerting for the production problem we would have reacted sooner; but this timeline reflects the fact that even with the information we did have, the response was slow. This was due to a combination of factors:\n\n* the reports received were all received outside of business hours and, given that the customers raising those reports were not enterprise customers, there was no out-of-hours process to review them;\n* there was some delay before the support team correlated multiple reports to conclude that there was a problem with the delivery of webhooks;\n* the rollback process was comparatively slow, deliberately avoiding a more disruptive abrupt rollback since the issue had impact for a relatively small number of customers.\n\nThe remedial actions in this area are as follows.\n\n**Review processes for handling and escalating issue reports out-of-hours.** Customers on lower support tiers can legitimately expect slower response times to deal with any individual issues or questions they have, but when an Ably problem arises that affects them there is no means for the relevant response team to be made aware. We will review our processes with the aim of improving support in these situations.\n\n## Conclusion\n\nThe service issues were the direct result of a regression in the Ably service - specifically, an incompatibility between a new feature \\(custom trust anchors for webhooks\\) and the existing state of rule configurations.\n\nThe cause of the extended duration of the incident was that the classification and rate of failed delivery events resulted in no alert being generated, which meant that Ably was not aware of the ongoing problem until it was reported by customers. Although it is difficult to monitor 4xx error rates effectively, because of the high background level of such errors, there is clearly a need to improve on the current situation where Ably regressions can go undetected. There was significant additional delay in triggering a response because the reports were received on a support channel that was not monitored out of business hours.\n\nOnce alerted to the problem, Ably initiated the response quickly, but the operational nature of the rollback meant that it took nearly two hours until it was completed.\n\nWe take service continuity very seriously, and this incident represents another opportunity to learn and improve the level of service we are committed to providing for our customers. We are sorry for the disruption that was experienced in this instance, and are committed to identifying and implementing remedial actions so that we eliminate the risk of similar failures in the future.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-10-29T09:42:56.242Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-10-29T08:57:58.445Z",
 
142
  "body": "Customers may be experiencing connectivity issues affecting our website (ably.com), customer dashboards, the Control API (control.ably.net), the Ably blog and documentation.\n\nOur realtime services are not affected by this issue at this time.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-10-09T14:10:08.000Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-10-09T14:10:08.000Z",
 
155
  "body": "The incident has been resolved",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-08-13T13:25:12.428Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-08-13T12:47:25.642Z",
api/v/abnormal-security.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "abnormal-security",
4
  "platform": "statuspage",
5
  "status_url": "https://abnormalsecurity.statuspage.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Starting at 08:50 UTC, Abnormal experienced a service disruption affecting AI Security Mailbox notifications for US and EU customers. Throughout the incident, the AI Security Mailbox continued to function as expected and customer security protection was not impacted; however, affected customers did not receive notifications during the incident window. Abnormal worked with its email delivery provider to reinstate the account, and AI Security Mailbox notifications are now being sent as expected. All notifications from the incident window will be processed. If you experience any further issues, please reach out to Abnormal Support at support@abnormalsecurity.com.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-01T11:15:08.000-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T09:40:09.000-07:00",
@@ -25,7 +25,7 @@
25
  "body": "Starting at 13:15 UTC, Abnormal experienced a service disruption affecting Inbound Email Security and Inline detection and remediation for US customers, resulting in elevated processing time. During this window, some messages experienced delayed detection and remediation. Engineers restored the live processing queue and inline remediation error rates recovered as of 14:18 UTC.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-09-01T07:38:06.436-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-09-01T07:38:06.392-07:00",
@@ -38,7 +38,7 @@
38
  "body": "The engineering team has resolved the primary issue affecting Account Takeover case details in the Gov region. Case details and timeline data are now loading as expected. The remaining minor issues will be addressed separately. Abnormal considers this incident resolved. If you have any further questions, please reach out to support at support@abnormalsecurity.com.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-03T18:22:42.380-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-03T11:50:35.634-07:00",
@@ -51,7 +51,7 @@
51
  "body": "Between 22:10 UTC and 22:50 UTC on July 27, 2026, Abnormal experienced a service disruption affecting Inbound Email Security, Inline, and Graymail processing for Google Workspace customers in both US and EU regions. During this time, inbound email processing was temporarily interrupted, which may have caused delays in email detection and remediation. The engineering team has resolved the issue, and all services have been fully restored. All emails from the impacted window have been successfully reprocessed. If you experience any further issues, please reach out to the support team at support@abnormalsecurity.com.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-27T16:10:10.640-07:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-27T16:10:10.597-07:00",
@@ -64,7 +64,7 @@
64
  "body": "As of 04:44 UTC on July 8, 2026, all services have fully recovered and are now live processing traffic for US and EU tenant customers. Abnormal will reprocess all messages received during the impact window to ensure full security analysis is applied. If you experience any continued issues, please reach out to the support team at support@abnormalsecurity.com.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "critical",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-07T21:44:51.664-07:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-07T15:58:51.315-07:00",
@@ -77,7 +77,7 @@
77
  "body": "Between 16:45 UTC and 17:25 UTC on June 5, 2026, Abnormal experienced message remediation delays affecting Inbound Email Security for GOV customers. During this time, some emails may have experienced delayed remediation. The Abnormal engineering team actively worked to address the issue, and service was fully restored as of 17:25 UTC. All emails from the impacted window have since been reprocessed. If you experience any further issues, please reach out to our support team at support@abnormalsecurity.com.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-06-05T11:03:42.271-07:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-05T11:03:42.204-07:00",
@@ -90,7 +90,7 @@
90
  "body": "Between 20:00 UTC and 21:22 UTC on June 4, 2026, Abnormal experienced a service disruption impacting inbound email ingestion for all inline US customers. During this time, inbound emails sent to customers may not have been ingested or processed. The Abnormal engineering team identified and resolved the root cause, and service was confirmed recovering as of 21:22 UTC. Emails affected during the incident window have been reprocessed. If you experience any further issues, please reach out to our support team at support@abnormalsecurity.com.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-06-04T15:07:09.115-07:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-04T15:07:09.071-07:00",
@@ -103,7 +103,7 @@
103
  "body": "Starting at 17:45 UTC on June 2, 2026, Abnormal experienced a service disruption affecting email detection and remediation for Inbound Email Security customers in the EU region. Additionally, between 18:00 UTC and 19:00 UTC, US customers experienced degraded AI Security Mailbox functionality. As of 19:20 UTC, all services have been restored and live traffic is processing normally across both regions. Abnormal is continuing to work through retry queues to reprocess any emails from the impacted window. If you experience any further issues, please reach out to our support team at support@abnormalsecurity.com.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "major",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-06-02T11:43:52.927-07:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-02T11:08:36.794-07:00",
@@ -116,7 +116,7 @@
116
  "body": "Microsoft services have fully recovered from the degraded M365 sign-in audit log delivery, and Abnormal services have also recovered as of 09:41 UTC on May 30, 2026. Abnormal engineering has initiated a reprocess to ensure all Account Takeover detections from the impacted time window are properly processed. No sign-in data was lost during this event. If you experience any further issues, please reach out to Abnormal support at support@abnormalsecurity.com.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-05-30T09:14:27.080-07:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-05-29T08:25:25.028-07:00",
@@ -129,7 +129,7 @@
129
  "body": "Starting at 22:00 UTC on May 18, 2026, Abnormal identified an increase in legitimate emails being incorrectly flagged as malicious and remediated, impacting Inbound Email Security and AI Security Mailbox. The engineering team identified and disabled the rule responsible for falsely flagging these emails at 01:03 UTC on May 19, 2026. Messages affected during the impact window will be reprocessed.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-05-18T16:24:46.000-07:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-18T16:24:46.000-07:00",
@@ -142,7 +142,7 @@
142
  "body": "Between 00:19 UTC and 00:49 UTC, Abnormal experienced message remediation delays affecting Inbound Email Security for US customers. During this approximately 30-minute window, email remediation was temporarily delayed due to a backend database issue. The engineering team stopped the contributing process and remediation services recovered. All messages from the impacted window have since been reprocessed.\n\nIf you experience any further issues, please reach out to our support team at support@abnormalsecurity.com",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-05-14T18:07:36.453-07:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-14T18:07:36.403-07:00",
@@ -155,7 +155,7 @@
155
  "body": "Between approximately May 2, 2026, and May 4, 2026 at 18:45 UTC, Abnormal experienced a service disruption affecting Security Orchestration, Automation and Response (SOAR) API functionality, Portal data retrieval, and Threat Log display for US customers. During this time, customers utilizing SOAR API integrations may have experienced errors when attempting to query messages, attachments, and threat data. The Abnormal engineering team has deployed a fix and confirmed that SOAR API is functioning as expected. All affected services have been restored to normal operation. If you experience any further issues, please reach out to the Abnormal support team at support@abnormalsecurity.com.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-05-04T11:58:34.927-07:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-04T10:21:09.205-07:00",
@@ -168,7 +168,7 @@
168
  "body": "Between 00:30 UTC and 08:10 UTC on April 28, 2026, Abnormal experienced an issue impacting email detection and scoring accuracy, which may have resulted in some legitimate emails being incorrectly flagged. Abnormal engineering identified the root cause, implemented a fix, and confirmed that all email detection and scoring services have been fully restored. All messages received during the impact window will be replayed to ensure complete email protection coverage. If you experience any further issues, please reach out to the support team at support@abnormalsecurity.com.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-04-28T00:09:08.000-07:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-27T22:25:30.609-07:00",
@@ -181,7 +181,7 @@
181
  "body": "Starting at approximately 19:00 UTC on April 8, 2026, Abnormal received reports of customers being unable to access the Customer Support Portal. Some customers experienced intermittent or complete inaccessibility when attempting to log in or navigate the Portal. The Abnormal engineering team identified and resolved the underlying cause. As of 16:40 UTC on April 9, 2026, Customer Support Portal access has been fully restored and customers are able to successfully log in.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-04-09T10:05:10.168-07:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-09T08:15:45.239-07:00",
@@ -194,7 +194,7 @@
194
  "body": "Starting at 13:30 UTC on April 8, 2026, Abnormal experienced an issue with the email-based support case submission process due to a vendor-caused outage. Customers who submitted support requests by emailing support@abnormalsecurity.com or support@abnormal.ai may have experienced failures when attempting to create new cases. The vendor has confirmed that service has been restored, and Abnormal has verified that emails are now flowing as expected. Customers may resume submitting support requests via email.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-04-08T17:24:12.200-07:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-08T13:15:50.500-07:00",
@@ -207,7 +207,7 @@
207
  "body": "Between 09:53 UTC on April 4, 2026 and 17:38 UTC on April 6, 2026, Abnormal experienced an issue within the Gov Portal affecting the AI Security Mailbox Analyzed tab and remediation information cards on the message details page. During this time, Gov customers may have experienced failures when loading the AI Security Mailbox Analyzed tab, and remediation details may have appeared incomplete or failed to display on the message details page. The Abnormal engineering team identified and resolved the underlying issue, and full functionality has been restored. If you experience any further issues, please reach out to the support team at support@abnormalsecurity.com.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-04-08T08:56:25.510-07:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-08T08:56:25.473-07:00",
@@ -220,7 +220,7 @@
220
  "body": "Between approximately 16:00 UTC and 23:50 UTC on March 26, 2026, Abnormal experienced a service disruption impacting AI Security Mailbox report processing for US and EU customers. During this time, new reports submitted to AI Security Mailbox may not have been processed as expected. Abnormal engineers deployed a fix at 23:50 UTC and confirmed that services are now processing in real time. Any reports submitted during the impacted window are currently being reprocessed and are expected to be fully completed within the next few hours. If you experience any further issues, please reach out to the Abnormal support team at support@abnormalsecurity.com.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "major",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-03-26T17:14:59.090-07:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-26T16:03:45.801-07:00",
@@ -233,7 +233,7 @@
233
  "body": "Starting around 22:23 UTC on March 16, 2026, Abnormal experienced a service disruption impacting Inbound Email Security detection and remediation for some US customers. During this time, inline email processing was also affected, and some emails may not have been properly detected or remediated. Abnormal's engineering team actively worked to address the issue, and all services were fully restored as of 23:56 UTC. Detection and remediation are now operating as expected for US customers. If you experience any further issues, please reach out to Abnormal's support team at support@abnormalsecurity.com.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-03-16T17:00:55.004-07:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-16T16:21:02.350-07:00",
@@ -246,7 +246,7 @@
246
  "body": "Starting around 14:40 UTC, Abnormal experienced an issue with the EU Portal being inaccessible and displaying an error to EU customers. Email detection and remediation services were not impacted during this time and continued to operate normally. Access to the Abnormal Portal for EU customers has been restored as of 15:01 UTC. If you experience any further issues, please reach out to the Abnormal support team at support@abnormalsecurity.com.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "major",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-03-16T08:05:00.543-07:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-16T07:58:04.332-07:00",
@@ -259,7 +259,7 @@
259
  "body": "Between 18:00 UTC and 20:40 UTC on March 12, 2026, Abnormal identified an issue where messages flagged as attack, spam, or borderline experienced delays in appearing within the Threat Log for Gov customers. Inbound Email Security detection and remediation remained fully functional throughout the incident, and all threats continued to be identified and acted upon as expected. Abnormal engineers redeployed the affected services and confirmed recovery as of 20:40 UTC. All messages during the incident window were queued and have been processed. If you experience any further issues, please reach out to Abnormal support at support@abnormalsecurity.com.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-03-12T13:56:23.155-07:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-12T13:31:20.161-07:00",
@@ -272,7 +272,7 @@
272
  "body": "Between February 23, 2026 at 19:55 UTC and February 24, 2026 at 03:30 UTC, Abnormal experienced an issue impacting Threat Log visibility for GovCloud customers. During this time, newly detected threats did not appear in the Threat Log, and the Email Details page displayed \"content unavailable\" for previously flagged messages. Inbound email processing, threat detection, and remediation were not impacted throughout the duration of this incident. Abnormal engineers have confirmed that Threat Log services are now processing in real time and full visibility has been restored. If you have any questions or concerns, please contact support at support@abnormalsecurity.com.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-02-23T19:38:47.615-08:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-02-23T19:23:51.376-08:00",
@@ -285,7 +285,7 @@
285
  "body": "Between 14:28 UTC and 15:00 UTC on February 12, Abnormal experienced issues with customers being able to access the Abnormal Portal. During this time, customers may have experienced the inability to log into the Portal. Service has been fully restored as of 15:00 UTC for customers in US and EU regions. If you experience any further issues, please reach out to support@abnormalsecurity.com.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "critical",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-02-12T07:04:27.912-08:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-02-12T06:57:28.660-08:00",
@@ -298,7 +298,7 @@
298
  "body": "Between 16:22 UTC on February 11 and 01:17 UTC on February 12, government customers may have experienced Account Takeover messages not being properly flagged for security threats. Abnormal's engineering team has resolved the issue and service is confirmed as fully functional. If customers experience any further issues, please reach out to support@abnormalsecurity.com",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "critical",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-02-11T17:32:24.000-08:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-02-11T16:56:10.000-08:00",
@@ -311,7 +311,7 @@
311
  "body": "Between 19:28 UTC and 20:15 UTC, Abnormal experienced service degradation with the Portal. US customers might have experienced issues logging in and navigating the Abnormal Portal during this time. EU customers were not impacted. Abnormal mitigated the root cause and services have been confirmed as fully restored. If you experience any further issues please reach out to support@abnormalsecurity.com",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-02-11T12:26:37.453-08:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-02-11T11:56:41.000-08:00",
@@ -324,7 +324,7 @@
324
  "body": "Between 00:56 UTC and 16:00 UTC on February 10, 2026, Abnormal experienced a service disruption affecting email threat detection, AI Security Mailbox, and graymail processing for Government customers. During this time, some malicious and spam emails may not have been properly flagged or processed. Abnormal engineers restored service as of 16:00 UTC for email threat detection, AI Security Mailbox, and graymail processing for Government customers. If customers experience any further issues please reach out to support@abnormalsecurity.com for further assistance.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "critical",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-02-10T08:07:21.940-08:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-02-10T07:21:45.000-08:00",
@@ -337,7 +337,7 @@
337
  "body": "As of 03:30 UTC on January 23, Abnormal's Inbound Email Security services have fully recovered from the processing delays due to the widespread Microsoft outage. Microsoft has confirmed that they have fully resolved the infrastructure issue that was impacting multiple services globally. All email processing has returned to normal performance levels. If you experience any further issues or need assistance, please reach out to Abnormal's support team at support@abnormalsecurity.com.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "critical",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-01-23T09:54:53.183-08:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-01-22T12:32:40.000-08:00",
@@ -350,7 +350,7 @@
350
  "body": "As of 18:33 UTC, Abnormal has fully restored all impacted services. Portal performance has returned to normal levels, and customers can now successfully access threat logs and retrieve threat data through Security Orchestration, Automation and Response integrations without errors. All delayed threat log data has been processed and is now available in customer portals. If customers continue to experience any issues, please contact support at support@abnormalsecurity.com.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-01-21T10:44:39.542-08:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-01-21T09:52:52.100-08:00",
@@ -363,7 +363,7 @@
363
  "body": "As of 23:40 UTC on January 16, 2026, the Account Takeover event issue affecting FedRAMP customers has been fully resolved. All Account Takeover services are now operating normally. Abnormal's core email protection services remained fully operational throughout this incident and continued to protect against threats. If customers have any questions or concerns, please contact support at support@abnormalsecurity.com.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-01-15T16:05:08.499-08:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-01-15T12:39:05.793-08:00",
@@ -376,7 +376,7 @@
376
  "body": "Between 16:40 UTC and 17:00 UTC, Abnormal experienced a service degradation with the Abnormal Portal affecting Fedramp customers. During this time, Fedramp users experienced errors when trying to load and navigate the portal, along with delays with pages loading. Remediation and detection services remained fully operational throughout the incident window.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "none",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-01-15T09:11:05.000-08:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-01-15T09:11:05.000-08:00",
@@ -389,7 +389,7 @@
389
  "body": "Between 15:35 UTC and 16:37 UTC, customers experienced issues with the Abnormal Portal which caused slowness and failures when trying to load and navigate the portal. Email remediation and detection services remained fully operational during this time. Abnormal Portal services are now fully recovered and all functionality has been restored. If customers experience any further issues, please contact Abnormal support at support@abnormalsecurity.com.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-01-13T08:41:08.206-08:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-01-13T08:18:17.535-08:00",
@@ -402,7 +402,7 @@
402
  "body": "Between 20:04 UTC and 20:45 UTC, US customers experienced issues with the Abnormal Portal which caused difficulties loading and navigating the platform. During this time, some users may have encountered errors or delays when accessing portal features. Email detection and remediation services remained fully operational throughout this incident. Portal functionality has been restored and services are now available. If you experience any further issues pertaining to this incident, please contact us at support@abnormalsecurity.com.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-12-22T12:55:30.971-08:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-12-22T12:55:30.914-08:00",
@@ -415,7 +415,7 @@
415
  "body": "As of 12:40 UTC, Abnormal has implemented a fix and engineers are observing Security Orchestration, Automation Response traffic as expected. The service disruption affecting automated security workflows and response actions has been fully resolved. Please reach out to support@abnormalsecurity.com if you experience any further issues.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "critical",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-11-20T04:48:01.732-08:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-11-20T03:44:24.722-08:00",
@@ -428,7 +428,7 @@
428
  "body": "Abnormal's engineering team has fully resolved the Portal access issue. All customers can now successfully log in to the Portal, and services are operating normally. Email security protection remained fully operational throughout this incident. No further updates will be provided for this issue. If customers experience any further issues, please reach out to support@abnormalsecurity.com.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "major",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-11-06T16:20:59.764-08:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-11-06T12:46:01.871-08:00",
@@ -441,7 +441,7 @@
441
  "body": "All email security services remain stable and are operating normally. Engineers have initiated reprocessing of all messages sent during the incident window to ensure complete security coverage. If customers experience any further issues, please reach out to support@abnormalsecurity.com.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "major",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-10-20T17:49:43.608-07:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-10-20T00:48:09.407-07:00",
@@ -454,7 +454,7 @@
454
  "body": "Abnormal's email security services and portal access have been fully restored as of 16:35 UTC. Our engineering team is currently processing the backlog of messages from the affected timeframe, which is expected to complete within the next hour. If you experience any further issues, please reach out to support@abnormalsecurity.com.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "critical",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-10-14T10:15:02.134-07:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-10-14T09:13:01.000-07:00",
@@ -467,7 +467,7 @@
467
  "body": "Abnormal has successfully resolved the portal access issue that was affecting customers in Europe as of 21:30 UTC. Full portal functionality has been restored for all affected customers. Abnormal apologizes for any inconvenience this may have caused. If you continue to experience any issues accessing the portal, please contact support at support@abnormalsecurity.com.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "critical",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-09-19T14:54:45.149-07:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-19T13:34:46.632-07:00",
@@ -480,7 +480,7 @@
480
  "body": "Engineers identified and resolved a configuration issue that was preventing detection and remediation services from functioning properly for FedRamp customers. All services have been fully restored, and engineering teams are performing a replay of all impacted messages from the incident window to ensure complete threat detection and remediation coverage.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-09-15T11:55:12.447-07:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-15T11:00:04.255-07:00",
@@ -493,7 +493,7 @@
493
  "body": "Portal access has been fully restored for all US customers as of 07:30 pm PT on September 12, 2025. Detection and remediation services were not impacted as part of this issue, and email protection continued to operate normally throughout the incident. If customers experience any further issues with portal access, please reach out to support at support@abnormalsecurity.com.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-09-12T19:35:24.674-07:00",
498
  "resolved_inferred": false,
499
  "started_at": "2025-09-12T18:54:40.532-07:00",
@@ -506,7 +506,7 @@
506
  "body": "All impacted mailboxes have been fully recovered and email protection services are now fully functional. If customers experience any issues with mailbox protection services, please contact support at support@abnormalsecurity.com.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-09-09T20:41:19.233-07:00",
511
  "resolved_inferred": false,
512
  "started_at": "2025-09-09T15:16:16.915-07:00",
@@ -519,7 +519,7 @@
519
  "body": "As of 00:17 UTC on August 22nd, Abnormal's engineering team has fully resolved the login issues affecting customers in our Federal Risk and Authorization Management Program environment. All customers should now be able to access the Abnormal Security Portal normally. Email detection and remediation services remained fully operational throughout this incident. Abnormal apologizes for any inconvenience this issue may have caused. If you experience any further issues related to portal logins, please reach out to support@abnormalsecurity.com",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "major",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2025-08-21T17:46:55.465-07:00",
524
  "resolved_inferred": false,
525
  "started_at": "2025-08-21T15:31:32.201-07:00",
@@ -532,7 +532,7 @@
532
  "body": "On 2025-08-18 at 16:50 UTC, Abnormal experienced a degradation of the Abnormal Portal where some customers experienced intermittent access issues and slow response times on the threat log and search and response features. The issue has been fully resolved as of 17:50 UTC, and all portal functionality is now operating normally. There was no impact on email remediation during this incident. Abnormal apologizes for any inconvenience this issue caused customers. If you continue to experience any portal access issues, please contact Abnormal Support at support@abnormalsecurity.com.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2025-08-18T11:00:41.151-07:00",
537
  "resolved_inferred": false,
538
  "started_at": "2025-08-18T10:41:46.000-07:00",
@@ -545,7 +545,7 @@
545
  "body": "This incident has been fully resolved. As of 21:13 UTC, Abnormal has completed reprocessing all emails from the impacted timeframe for European customers using Inbound Email Security. All affected emails have now been properly analyzed and protected. Abnormal's services are fully operational. If you experience any issues, please contact support at support@abnormalsecurity.com.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "critical",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2025-08-14T15:52:28.089-07:00",
550
  "resolved_inferred": false,
551
  "started_at": "2025-08-14T06:31:07.007-07:00",
 
3
  "slug": "abnormal-security",
4
  "platform": "statuspage",
5
  "status_url": "https://abnormalsecurity.statuspage.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Starting at 08:50 UTC, Abnormal experienced a service disruption affecting AI Security Mailbox notifications for US and EU customers. Throughout the incident, the AI Security Mailbox continued to function as expected and customer security protection was not impacted; however, affected customers did not receive notifications during the incident window. Abnormal worked with its email delivery provider to reinstate the account, and AI Security Mailbox notifications are now being sent as expected. All notifications from the incident window will be processed. If you experience any further issues, please reach out to Abnormal Support at support@abnormalsecurity.com.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-01T11:15:08.000-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T09:40:09.000-07:00",
 
25
  "body": "Starting at 13:15 UTC, Abnormal experienced a service disruption affecting Inbound Email Security and Inline detection and remediation for US customers, resulting in elevated processing time. During this window, some messages experienced delayed detection and remediation. Engineers restored the live processing queue and inline remediation error rates recovered as of 14:18 UTC.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-09-01T07:38:06.436-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-09-01T07:38:06.392-07:00",
 
38
  "body": "The engineering team has resolved the primary issue affecting Account Takeover case details in the Gov region. Case details and timeline data are now loading as expected. The remaining minor issues will be addressed separately. Abnormal considers this incident resolved. If you have any further questions, please reach out to support at support@abnormalsecurity.com.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-03T18:22:42.380-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-03T11:50:35.634-07:00",
 
51
  "body": "Between 22:10 UTC and 22:50 UTC on July 27, 2026, Abnormal experienced a service disruption affecting Inbound Email Security, Inline, and Graymail processing for Google Workspace customers in both US and EU regions. During this time, inbound email processing was temporarily interrupted, which may have caused delays in email detection and remediation. The engineering team has resolved the issue, and all services have been fully restored. All emails from the impacted window have been successfully reprocessed. If you experience any further issues, please reach out to the support team at support@abnormalsecurity.com.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-27T16:10:10.640-07:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-27T16:10:10.597-07:00",
 
64
  "body": "As of 04:44 UTC on July 8, 2026, all services have fully recovered and are now live processing traffic for US and EU tenant customers. Abnormal will reprocess all messages received during the impact window to ensure full security analysis is applied. If you experience any continued issues, please reach out to the support team at support@abnormalsecurity.com.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "critical",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-07T21:44:51.664-07:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-07T15:58:51.315-07:00",
 
77
  "body": "Between 16:45 UTC and 17:25 UTC on June 5, 2026, Abnormal experienced message remediation delays affecting Inbound Email Security for GOV customers. During this time, some emails may have experienced delayed remediation. The Abnormal engineering team actively worked to address the issue, and service was fully restored as of 17:25 UTC. All emails from the impacted window have since been reprocessed. If you experience any further issues, please reach out to our support team at support@abnormalsecurity.com.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-06-05T11:03:42.271-07:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-05T11:03:42.204-07:00",
 
90
  "body": "Between 20:00 UTC and 21:22 UTC on June 4, 2026, Abnormal experienced a service disruption impacting inbound email ingestion for all inline US customers. During this time, inbound emails sent to customers may not have been ingested or processed. The Abnormal engineering team identified and resolved the root cause, and service was confirmed recovering as of 21:22 UTC. Emails affected during the incident window have been reprocessed. If you experience any further issues, please reach out to our support team at support@abnormalsecurity.com.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-06-04T15:07:09.115-07:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-04T15:07:09.071-07:00",
 
103
  "body": "Starting at 17:45 UTC on June 2, 2026, Abnormal experienced a service disruption affecting email detection and remediation for Inbound Email Security customers in the EU region. Additionally, between 18:00 UTC and 19:00 UTC, US customers experienced degraded AI Security Mailbox functionality. As of 19:20 UTC, all services have been restored and live traffic is processing normally across both regions. Abnormal is continuing to work through retry queues to reprocess any emails from the impacted window. If you experience any further issues, please reach out to our support team at support@abnormalsecurity.com.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "major",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-06-02T11:43:52.927-07:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-02T11:08:36.794-07:00",
 
116
  "body": "Microsoft services have fully recovered from the degraded M365 sign-in audit log delivery, and Abnormal services have also recovered as of 09:41 UTC on May 30, 2026. Abnormal engineering has initiated a reprocess to ensure all Account Takeover detections from the impacted time window are properly processed. No sign-in data was lost during this event. If you experience any further issues, please reach out to Abnormal support at support@abnormalsecurity.com.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-05-30T09:14:27.080-07:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-05-29T08:25:25.028-07:00",
 
129
  "body": "Starting at 22:00 UTC on May 18, 2026, Abnormal identified an increase in legitimate emails being incorrectly flagged as malicious and remediated, impacting Inbound Email Security and AI Security Mailbox. The engineering team identified and disabled the rule responsible for falsely flagging these emails at 01:03 UTC on May 19, 2026. Messages affected during the impact window will be reprocessed.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-05-18T16:24:46.000-07:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-18T16:24:46.000-07:00",
 
142
  "body": "Between 00:19 UTC and 00:49 UTC, Abnormal experienced message remediation delays affecting Inbound Email Security for US customers. During this approximately 30-minute window, email remediation was temporarily delayed due to a backend database issue. The engineering team stopped the contributing process and remediation services recovered. All messages from the impacted window have since been reprocessed.\n\nIf you experience any further issues, please reach out to our support team at support@abnormalsecurity.com",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-05-14T18:07:36.453-07:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-14T18:07:36.403-07:00",
 
155
  "body": "Between approximately May 2, 2026, and May 4, 2026 at 18:45 UTC, Abnormal experienced a service disruption affecting Security Orchestration, Automation and Response (SOAR) API functionality, Portal data retrieval, and Threat Log display for US customers. During this time, customers utilizing SOAR API integrations may have experienced errors when attempting to query messages, attachments, and threat data. The Abnormal engineering team has deployed a fix and confirmed that SOAR API is functioning as expected. All affected services have been restored to normal operation. If you experience any further issues, please reach out to the Abnormal support team at support@abnormalsecurity.com.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-05-04T11:58:34.927-07:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-04T10:21:09.205-07:00",
 
168
  "body": "Between 00:30 UTC and 08:10 UTC on April 28, 2026, Abnormal experienced an issue impacting email detection and scoring accuracy, which may have resulted in some legitimate emails being incorrectly flagged. Abnormal engineering identified the root cause, implemented a fix, and confirmed that all email detection and scoring services have been fully restored. All messages received during the impact window will be replayed to ensure complete email protection coverage. If you experience any further issues, please reach out to the support team at support@abnormalsecurity.com.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-04-28T00:09:08.000-07:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-27T22:25:30.609-07:00",
 
181
  "body": "Starting at approximately 19:00 UTC on April 8, 2026, Abnormal received reports of customers being unable to access the Customer Support Portal. Some customers experienced intermittent or complete inaccessibility when attempting to log in or navigate the Portal. The Abnormal engineering team identified and resolved the underlying cause. As of 16:40 UTC on April 9, 2026, Customer Support Portal access has been fully restored and customers are able to successfully log in.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-04-09T10:05:10.168-07:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-09T08:15:45.239-07:00",
 
194
  "body": "Starting at 13:30 UTC on April 8, 2026, Abnormal experienced an issue with the email-based support case submission process due to a vendor-caused outage. Customers who submitted support requests by emailing support@abnormalsecurity.com or support@abnormal.ai may have experienced failures when attempting to create new cases. The vendor has confirmed that service has been restored, and Abnormal has verified that emails are now flowing as expected. Customers may resume submitting support requests via email.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-04-08T17:24:12.200-07:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-08T13:15:50.500-07:00",
 
207
  "body": "Between 09:53 UTC on April 4, 2026 and 17:38 UTC on April 6, 2026, Abnormal experienced an issue within the Gov Portal affecting the AI Security Mailbox Analyzed tab and remediation information cards on the message details page. During this time, Gov customers may have experienced failures when loading the AI Security Mailbox Analyzed tab, and remediation details may have appeared incomplete or failed to display on the message details page. The Abnormal engineering team identified and resolved the underlying issue, and full functionality has been restored. If you experience any further issues, please reach out to the support team at support@abnormalsecurity.com.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-04-08T08:56:25.510-07:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-08T08:56:25.473-07:00",
 
220
  "body": "Between approximately 16:00 UTC and 23:50 UTC on March 26, 2026, Abnormal experienced a service disruption impacting AI Security Mailbox report processing for US and EU customers. During this time, new reports submitted to AI Security Mailbox may not have been processed as expected. Abnormal engineers deployed a fix at 23:50 UTC and confirmed that services are now processing in real time. Any reports submitted during the impacted window are currently being reprocessed and are expected to be fully completed within the next few hours. If you experience any further issues, please reach out to the Abnormal support team at support@abnormalsecurity.com.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "major",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-03-26T17:14:59.090-07:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-26T16:03:45.801-07:00",
 
233
  "body": "Starting around 22:23 UTC on March 16, 2026, Abnormal experienced a service disruption impacting Inbound Email Security detection and remediation for some US customers. During this time, inline email processing was also affected, and some emails may not have been properly detected or remediated. Abnormal's engineering team actively worked to address the issue, and all services were fully restored as of 23:56 UTC. Detection and remediation are now operating as expected for US customers. If you experience any further issues, please reach out to Abnormal's support team at support@abnormalsecurity.com.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-03-16T17:00:55.004-07:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-16T16:21:02.350-07:00",
 
246
  "body": "Starting around 14:40 UTC, Abnormal experienced an issue with the EU Portal being inaccessible and displaying an error to EU customers. Email detection and remediation services were not impacted during this time and continued to operate normally. Access to the Abnormal Portal for EU customers has been restored as of 15:01 UTC. If you experience any further issues, please reach out to the Abnormal support team at support@abnormalsecurity.com.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "major",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-03-16T08:05:00.543-07:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-16T07:58:04.332-07:00",
 
259
  "body": "Between 18:00 UTC and 20:40 UTC on March 12, 2026, Abnormal identified an issue where messages flagged as attack, spam, or borderline experienced delays in appearing within the Threat Log for Gov customers. Inbound Email Security detection and remediation remained fully functional throughout the incident, and all threats continued to be identified and acted upon as expected. Abnormal engineers redeployed the affected services and confirmed recovery as of 20:40 UTC. All messages during the incident window were queued and have been processed. If you experience any further issues, please reach out to Abnormal support at support@abnormalsecurity.com.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-03-12T13:56:23.155-07:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-12T13:31:20.161-07:00",
 
272
  "body": "Between February 23, 2026 at 19:55 UTC and February 24, 2026 at 03:30 UTC, Abnormal experienced an issue impacting Threat Log visibility for GovCloud customers. During this time, newly detected threats did not appear in the Threat Log, and the Email Details page displayed \"content unavailable\" for previously flagged messages. Inbound email processing, threat detection, and remediation were not impacted throughout the duration of this incident. Abnormal engineers have confirmed that Threat Log services are now processing in real time and full visibility has been restored. If you have any questions or concerns, please contact support at support@abnormalsecurity.com.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-02-23T19:38:47.615-08:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-02-23T19:23:51.376-08:00",
 
285
  "body": "Between 14:28 UTC and 15:00 UTC on February 12, Abnormal experienced issues with customers being able to access the Abnormal Portal. During this time, customers may have experienced the inability to log into the Portal. Service has been fully restored as of 15:00 UTC for customers in US and EU regions. If you experience any further issues, please reach out to support@abnormalsecurity.com.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "critical",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-02-12T07:04:27.912-08:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-02-12T06:57:28.660-08:00",
 
298
  "body": "Between 16:22 UTC on February 11 and 01:17 UTC on February 12, government customers may have experienced Account Takeover messages not being properly flagged for security threats. Abnormal's engineering team has resolved the issue and service is confirmed as fully functional. If customers experience any further issues, please reach out to support@abnormalsecurity.com",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "critical",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-02-11T17:32:24.000-08:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-02-11T16:56:10.000-08:00",
 
311
  "body": "Between 19:28 UTC and 20:15 UTC, Abnormal experienced service degradation with the Portal. US customers might have experienced issues logging in and navigating the Abnormal Portal during this time. EU customers were not impacted. Abnormal mitigated the root cause and services have been confirmed as fully restored. If you experience any further issues please reach out to support@abnormalsecurity.com",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-02-11T12:26:37.453-08:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-02-11T11:56:41.000-08:00",
 
324
  "body": "Between 00:56 UTC and 16:00 UTC on February 10, 2026, Abnormal experienced a service disruption affecting email threat detection, AI Security Mailbox, and graymail processing for Government customers. During this time, some malicious and spam emails may not have been properly flagged or processed. Abnormal engineers restored service as of 16:00 UTC for email threat detection, AI Security Mailbox, and graymail processing for Government customers. If customers experience any further issues please reach out to support@abnormalsecurity.com for further assistance.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "critical",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-02-10T08:07:21.940-08:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-02-10T07:21:45.000-08:00",
 
337
  "body": "As of 03:30 UTC on January 23, Abnormal's Inbound Email Security services have fully recovered from the processing delays due to the widespread Microsoft outage. Microsoft has confirmed that they have fully resolved the infrastructure issue that was impacting multiple services globally. All email processing has returned to normal performance levels. If you experience any further issues or need assistance, please reach out to Abnormal's support team at support@abnormalsecurity.com.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "critical",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-01-23T09:54:53.183-08:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-01-22T12:32:40.000-08:00",
 
350
  "body": "As of 18:33 UTC, Abnormal has fully restored all impacted services. Portal performance has returned to normal levels, and customers can now successfully access threat logs and retrieve threat data through Security Orchestration, Automation and Response integrations without errors. All delayed threat log data has been processed and is now available in customer portals. If customers continue to experience any issues, please contact support at support@abnormalsecurity.com.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-01-21T10:44:39.542-08:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-01-21T09:52:52.100-08:00",
 
363
  "body": "As of 23:40 UTC on January 16, 2026, the Account Takeover event issue affecting FedRAMP customers has been fully resolved. All Account Takeover services are now operating normally. Abnormal's core email protection services remained fully operational throughout this incident and continued to protect against threats. If customers have any questions or concerns, please contact support at support@abnormalsecurity.com.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-01-15T16:05:08.499-08:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-01-15T12:39:05.793-08:00",
 
376
  "body": "Between 16:40 UTC and 17:00 UTC, Abnormal experienced a service degradation with the Abnormal Portal affecting Fedramp customers. During this time, Fedramp users experienced errors when trying to load and navigate the portal, along with delays with pages loading. Remediation and detection services remained fully operational throughout the incident window.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "none",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-01-15T09:11:05.000-08:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-01-15T09:11:05.000-08:00",
 
389
  "body": "Between 15:35 UTC and 16:37 UTC, customers experienced issues with the Abnormal Portal which caused slowness and failures when trying to load and navigate the portal. Email remediation and detection services remained fully operational during this time. Abnormal Portal services are now fully recovered and all functionality has been restored. If customers experience any further issues, please contact Abnormal support at support@abnormalsecurity.com.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-01-13T08:41:08.206-08:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-01-13T08:18:17.535-08:00",
 
402
  "body": "Between 20:04 UTC and 20:45 UTC, US customers experienced issues with the Abnormal Portal which caused difficulties loading and navigating the platform. During this time, some users may have encountered errors or delays when accessing portal features. Email detection and remediation services remained fully operational throughout this incident. Portal functionality has been restored and services are now available. If you experience any further issues pertaining to this incident, please contact us at support@abnormalsecurity.com.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-12-22T12:55:30.971-08:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-12-22T12:55:30.914-08:00",
 
415
  "body": "As of 12:40 UTC, Abnormal has implemented a fix and engineers are observing Security Orchestration, Automation Response traffic as expected. The service disruption affecting automated security workflows and response actions has been fully resolved. Please reach out to support@abnormalsecurity.com if you experience any further issues.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "critical",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-11-20T04:48:01.732-08:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-11-20T03:44:24.722-08:00",
 
428
  "body": "Abnormal's engineering team has fully resolved the Portal access issue. All customers can now successfully log in to the Portal, and services are operating normally. Email security protection remained fully operational throughout this incident. No further updates will be provided for this issue. If customers experience any further issues, please reach out to support@abnormalsecurity.com.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "major",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-11-06T16:20:59.764-08:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-11-06T12:46:01.871-08:00",
 
441
  "body": "All email security services remain stable and are operating normally. Engineers have initiated reprocessing of all messages sent during the incident window to ensure complete security coverage. If customers experience any further issues, please reach out to support@abnormalsecurity.com.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "major",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-10-20T17:49:43.608-07:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-10-20T00:48:09.407-07:00",
 
454
  "body": "Abnormal's email security services and portal access have been fully restored as of 16:35 UTC. Our engineering team is currently processing the backlog of messages from the affected timeframe, which is expected to complete within the next hour. If you experience any further issues, please reach out to support@abnormalsecurity.com.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "critical",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-10-14T10:15:02.134-07:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-10-14T09:13:01.000-07:00",
 
467
  "body": "Abnormal has successfully resolved the portal access issue that was affecting customers in Europe as of 21:30 UTC. Full portal functionality has been restored for all affected customers. Abnormal apologizes for any inconvenience this may have caused. If you continue to experience any issues accessing the portal, please contact support at support@abnormalsecurity.com.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "critical",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-09-19T14:54:45.149-07:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-19T13:34:46.632-07:00",
 
480
  "body": "Engineers identified and resolved a configuration issue that was preventing detection and remediation services from functioning properly for FedRamp customers. All services have been fully restored, and engineering teams are performing a replay of all impacted messages from the incident window to ensure complete threat detection and remediation coverage.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-09-15T11:55:12.447-07:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-15T11:00:04.255-07:00",
 
493
  "body": "Portal access has been fully restored for all US customers as of 07:30 pm PT on September 12, 2025. Detection and remediation services were not impacted as part of this issue, and email protection continued to operate normally throughout the incident. If customers experience any further issues with portal access, please reach out to support at support@abnormalsecurity.com.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-09-12T19:35:24.674-07:00",
498
  "resolved_inferred": false,
499
  "started_at": "2025-09-12T18:54:40.532-07:00",
 
506
  "body": "All impacted mailboxes have been fully recovered and email protection services are now fully functional. If customers experience any issues with mailbox protection services, please contact support at support@abnormalsecurity.com.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-09-09T20:41:19.233-07:00",
511
  "resolved_inferred": false,
512
  "started_at": "2025-09-09T15:16:16.915-07:00",
 
519
  "body": "As of 00:17 UTC on August 22nd, Abnormal's engineering team has fully resolved the login issues affecting customers in our Federal Risk and Authorization Management Program environment. All customers should now be able to access the Abnormal Security Portal normally. Email detection and remediation services remained fully operational throughout this incident. Abnormal apologizes for any inconvenience this issue may have caused. If you experience any further issues related to portal logins, please reach out to support@abnormalsecurity.com",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "major",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-08-21T17:46:55.465-07:00",
524
  "resolved_inferred": false,
525
  "started_at": "2025-08-21T15:31:32.201-07:00",
 
532
  "body": "On 2025-08-18 at 16:50 UTC, Abnormal experienced a degradation of the Abnormal Portal where some customers experienced intermittent access issues and slow response times on the threat log and search and response features. The issue has been fully resolved as of 17:50 UTC, and all portal functionality is now operating normally. There was no impact on email remediation during this incident. Abnormal apologizes for any inconvenience this issue caused customers. If you continue to experience any portal access issues, please contact Abnormal Support at support@abnormalsecurity.com.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-08-18T11:00:41.151-07:00",
537
  "resolved_inferred": false,
538
  "started_at": "2025-08-18T10:41:46.000-07:00",
 
545
  "body": "This incident has been fully resolved. As of 21:13 UTC, Abnormal has completed reprocessing all emails from the impacted timeframe for European customers using Inbound Email Security. All affected emails have now been properly analyzed and protected. Abnormal's services are fully operational. If you experience any issues, please contact support at support@abnormalsecurity.com.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "critical",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-08-14T15:52:28.089-07:00",
550
  "resolved_inferred": false,
551
  "started_at": "2025-08-14T06:31:07.007-07:00",
api/v/acquia.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "acquia",
4
  "platform": "statuspage",
5
  "status_url": "https://status.acquia.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "The service interruption impacting the Acquia Task system has been fully resolved. AWS US-WEST-2 operations have stabilized, and all queued tasks and system functions are operating normally.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-04T02:18:51.438Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T23:19:58.731Z",
@@ -22,21 +22,23 @@
22
  "url": "https://stspg.io/v80txq618pg9"
23
  },
24
  {
25
- "body": "We've resolved the issue addressing customers use of Site Studio.\u00a0 We're continuing to monitor the service to ensure stability",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
- "last_seen": "2026-09-04T09:06:33Z",
 
 
29
  "started_at": "2026-09-03T23:04:11.328Z",
30
- "state": "monitoring",
31
  "title": "Multiple customers are currently affected by what appears to be an outage impacting the Site Studio endpoint",
32
- "updated_at": "2026-09-04T04:34:56.887Z",
33
  "url": "https://stspg.io/w32x9vnv014z"
34
  },
35
  {
36
  "body": "This incident has been resolved. Our upstream search infrastructure partner, SearchStax, has successfully implemented the fix, and Pulse Performance Graphs are now displaying as expected. Core search functionality was unaffected throughout this incident. We apologize for any inconvenience caused and thank you for your patience.",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "minor",
39
- "last_seen": "2026-09-04T09:06:33Z",
40
  "resolved_at": "2026-09-04T02:04:42.869Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-09-03T16:27:23.205Z",
@@ -49,7 +51,7 @@
49
  "body": "We've resolve the problem causing an issue with some customers ability to log into DAM. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
50
  "first_seen": "2026-09-04T07:06:16Z",
51
  "impact": "critical",
52
- "last_seen": "2026-09-04T09:06:33Z",
53
  "resolved_at": "2026-09-03T16:24:58.769Z",
54
  "resolved_inferred": false,
55
  "started_at": "2026-09-03T15:05:24.973Z",
@@ -62,7 +64,7 @@
62
  "body": "The issue impacting access to the Pipelines UI and Dashboard for MEO customers has been fully resolved.\r\nA fix was deployed and verification was completed to confirm that the Pipelines Dashboard is fully operational and performing normally.",
63
  "first_seen": "2026-09-04T07:06:16Z",
64
  "impact": "none",
65
- "last_seen": "2026-09-04T09:06:33Z",
66
  "resolved_at": "2026-09-03T00:13:18.597Z",
67
  "resolved_inferred": false,
68
  "started_at": "2026-09-02T21:39:29.077Z",
@@ -75,7 +77,7 @@
75
  "body": "We've resolved the issue causing degraded file processing for customers hosted in the EU and have completed processing work that accumulated during the incident. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
76
  "first_seen": "2026-09-04T07:06:16Z",
77
  "impact": "minor",
78
- "last_seen": "2026-09-04T09:06:33Z",
79
  "resolved_at": "2026-08-31T17:34:08.530Z",
80
  "resolved_inferred": false,
81
  "started_at": "2026-08-31T16:28:17.484Z",
@@ -88,7 +90,7 @@
88
  "body": "The issue affecting Edge Standard customers has been resolved. Akamai has addressed the vendor API issue, and security and performance metrics are now available in the Edge Standard UI",
89
  "first_seen": "2026-09-04T07:06:16Z",
90
  "impact": "minor",
91
- "last_seen": "2026-09-04T09:06:33Z",
92
  "resolved_at": "2026-08-24T11:05:27.821Z",
93
  "resolved_inferred": false,
94
  "started_at": "2026-08-24T09:29:44.425Z",
@@ -101,7 +103,7 @@
101
  "body": "We can confirm that the issue was confirmed mitigated at 20:42 UTC on August 18, 2026 and the service has resumed normal operation.",
102
  "first_seen": "2026-09-04T07:06:16Z",
103
  "impact": "minor",
104
- "last_seen": "2026-09-04T09:06:33Z",
105
  "resolved_at": "2026-08-19T22:13:09.531Z",
106
  "resolved_inferred": false,
107
  "started_at": "2026-08-17T21:24:57.304Z",
@@ -114,7 +116,7 @@
114
  "body": "The log download issue affecting Acquia Cloud Next and MEO customers was resolved on Aug 11 09:38 UTC, and all systems are fully operational.",
115
  "first_seen": "2026-09-04T07:06:16Z",
116
  "impact": "major",
117
- "last_seen": "2026-09-04T09:06:33Z",
118
  "resolved_at": "2026-08-12T09:27:30.470Z",
119
  "resolved_inferred": false,
120
  "started_at": "2026-08-11T07:40:11.926Z",
@@ -127,7 +129,7 @@
127
  "body": "The underlying cause of this service interruption has been addressed. All services are operational at this time.",
128
  "first_seen": "2026-09-04T07:06:16Z",
129
  "impact": "major",
130
- "last_seen": "2026-09-04T09:06:33Z",
131
  "resolved_at": "2026-08-10T19:44:51.818Z",
132
  "resolved_inferred": false,
133
  "started_at": "2026-08-10T18:29:13.357Z",
@@ -140,7 +142,7 @@
140
  "body": "The underlying cause of this service interruption has been addressed. All services are operational at this time.",
141
  "first_seen": "2026-09-04T07:06:16Z",
142
  "impact": "minor",
143
- "last_seen": "2026-09-04T09:06:33Z",
144
  "resolved_at": "2026-08-06T22:48:56.050Z",
145
  "resolved_inferred": false,
146
  "started_at": "2026-08-06T21:54:59.185Z",
@@ -153,7 +155,7 @@
153
  "body": "The issue affecting Acquia Cloud Pipelines has been resolved. Pipeline processing has returned to normal operations, and all previously queued jobs have been handled. Please note that if any of your queued jobs failed with a \"system failure\" message during the incident, they can now be safely re-run. We appreciate your patience while we worked to restore service.",
154
  "first_seen": "2026-09-04T07:06:16Z",
155
  "impact": "critical",
156
- "last_seen": "2026-09-04T09:06:33Z",
157
  "resolved_at": "2026-08-04T16:21:44.669Z",
158
  "resolved_inferred": false,
159
  "started_at": "2026-08-04T14:45:30.862Z",
@@ -166,7 +168,7 @@
166
  "body": "The issue affecting related and popular search functionality and Pulse monitoring has been fully resolved. All systems are operational. We appreciate your patience during this incident.",
167
  "first_seen": "2026-09-04T07:06:16Z",
168
  "impact": "major",
169
- "last_seen": "2026-09-04T09:06:33Z",
170
  "resolved_at": "2026-07-23T19:35:11.495Z",
171
  "resolved_inferred": false,
172
  "started_at": "2026-07-23T16:48:13.177Z",
@@ -179,7 +181,7 @@
179
  "body": "This incident has been resolved.",
180
  "first_seen": "2026-09-04T07:06:16Z",
181
  "impact": "none",
182
- "last_seen": "2026-09-04T09:06:33Z",
183
  "resolved_at": "2026-07-23T19:38:51.379Z",
184
  "resolved_inferred": false,
185
  "started_at": "2026-07-23T16:12:54.046Z",
@@ -192,7 +194,7 @@
192
  "body": "We've resolved the issue affecting the availability of some sites. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "major",
195
- "last_seen": "2026-09-04T09:06:33Z",
196
  "resolved_at": "2026-07-22T01:21:56.231Z",
197
  "resolved_inferred": false,
198
  "started_at": "2026-07-21T23:08:40.700Z",
@@ -205,7 +207,7 @@
205
  "body": "The issue impacting Acquia Pipelines is now completely resolved. Git connectivity and pipeline processing have returned to normal operations, and we do not anticipate any further impact.",
206
  "first_seen": "2026-09-04T07:06:16Z",
207
  "impact": "minor",
208
- "last_seen": "2026-09-04T09:06:33Z",
209
  "resolved_at": "2026-07-21T12:37:49.198Z",
210
  "resolved_inferred": false,
211
  "started_at": "2026-07-21T11:39:26.101Z",
@@ -218,7 +220,7 @@
218
  "body": "The issue impacting CDN provisioning for Edge Standard has been fully resolved. New domain configurations are now processing successfully, and we have confirmed stability across the environment. No further impact is expected.\r\nWe apologise for any inconvenience caused and appreciate your patience while we worked through this.",
219
  "first_seen": "2026-09-04T07:06:16Z",
220
  "impact": "minor",
221
- "last_seen": "2026-09-04T09:06:33Z",
222
  "resolved_at": "2026-07-17T20:06:17.592Z",
223
  "resolved_inferred": false,
224
  "started_at": "2026-07-17T09:41:22.219Z",
@@ -231,7 +233,7 @@
231
  "body": "The underlying cause of this interruption has been addressed. All affected services have been restored. All services are operational at this time.",
232
  "first_seen": "2026-09-04T07:06:16Z",
233
  "impact": "major",
234
- "last_seen": "2026-09-04T09:06:33Z",
235
  "resolved_at": "2026-06-22T21:54:48.409Z",
236
  "resolved_inferred": false,
237
  "started_at": "2026-06-22T14:59:09.557Z",
@@ -244,7 +246,7 @@
244
  "body": "The underlying cause of this interruption has been addressed. All affected services have been restored. All services are operational at this time.",
245
  "first_seen": "2026-09-04T07:06:16Z",
246
  "impact": "minor",
247
- "last_seen": "2026-09-04T09:06:33Z",
248
  "resolved_at": "2026-06-12T07:05:21.764Z",
249
  "resolved_inferred": false,
250
  "started_at": "2026-06-11T14:02:06.405Z",
@@ -257,7 +259,7 @@
257
  "body": "The login issues affecting Acquia Campaign Studio and Campaign Factory have been completely resolved, and all systems are fully operational.",
258
  "first_seen": "2026-09-04T07:06:16Z",
259
  "impact": "minor",
260
- "last_seen": "2026-09-04T09:06:33Z",
261
  "resolved_at": "2026-06-01T08:49:17.252Z",
262
  "resolved_inferred": false,
263
  "started_at": "2026-06-01T05:21:33.486Z",
@@ -270,7 +272,7 @@
270
  "body": "The issue with our upstream provider has been fully resolved, and all affected services have been restored to normal operations. Thank you for your patience while we worked to address this issue.",
271
  "first_seen": "2026-09-04T07:06:16Z",
272
  "impact": "major",
273
- "last_seen": "2026-09-04T09:06:33Z",
274
  "resolved_at": "2026-05-09T13:54:11.219Z",
275
  "resolved_inferred": false,
276
  "started_at": "2026-05-08T00:16:50.607Z",
@@ -283,7 +285,7 @@
283
  "body": "We have resolved the issue causing degraded Portals performance for some customers. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
284
  "first_seen": "2026-09-04T07:06:16Z",
285
  "impact": "minor",
286
- "last_seen": "2026-09-04T09:06:33Z",
287
  "resolved_at": "2026-05-06T00:33:29.781Z",
288
  "resolved_inferred": false,
289
  "started_at": "2026-05-05T19:43:22.102Z",
@@ -296,7 +298,7 @@
296
  "body": "We've detected a service interruption affecting the stability for your application. The issue was quickly identified and resolved. Everything is up and running now.",
297
  "first_seen": "2026-09-04T07:06:16Z",
298
  "impact": "none",
299
- "last_seen": "2026-09-04T09:06:33Z",
300
  "resolved_at": "2026-05-01T22:11:24.014Z",
301
  "resolved_inferred": false,
302
  "started_at": "2026-05-01T22:11:23.964Z",
@@ -309,7 +311,7 @@
309
  "body": "We've detected a service interruption affecting the shared load balancers for certain customer applications. All services are operational at this time.",
310
  "first_seen": "2026-09-04T07:06:16Z",
311
  "impact": "none",
312
- "last_seen": "2026-09-04T09:06:33Z",
313
  "resolved_at": "2026-04-30T22:54:41.000Z",
314
  "resolved_inferred": false,
315
  "started_at": "2026-04-30T22:54:40.973Z",
@@ -322,7 +324,7 @@
322
  "body": "The underlying cause of this issue has been addressed. All affected services have been restored. All services are operational at this time.",
323
  "first_seen": "2026-09-04T07:06:16Z",
324
  "impact": "minor",
325
- "last_seen": "2026-09-04T09:06:33Z",
326
  "resolved_at": "2026-04-30T00:30:51.717Z",
327
  "resolved_inferred": false,
328
  "started_at": "2026-04-29T15:33:33.213Z",
@@ -335,7 +337,7 @@
335
  "body": "The issue impacting code deployments for a subset of customers on our Cloud Platform has now been resolved. Our engineering team has implemented a fix and all code deployment functionalities are now restored.",
336
  "first_seen": "2026-09-04T07:06:16Z",
337
  "impact": "minor",
338
- "last_seen": "2026-09-04T09:06:33Z",
339
  "resolved_at": "2026-04-22T06:33:38.288Z",
340
  "resolved_inferred": false,
341
  "started_at": "2026-04-21T16:41:30.881Z",
@@ -348,7 +350,7 @@
348
  "body": "The issue impacting code deployments for a subset of customers on our Cloud Platform has now been resolved. Our engineering team has implemented a fix and all code deployment functionalities are now restored.",
349
  "first_seen": "2026-09-04T07:06:16Z",
350
  "impact": "major",
351
- "last_seen": "2026-09-04T09:06:33Z",
352
  "resolved_at": "2026-04-21T10:01:53.889Z",
353
  "resolved_inferred": false,
354
  "started_at": "2026-04-21T04:08:30.038Z",
@@ -361,7 +363,7 @@
361
  "body": "The issue impacting Two-Factor Authentication (TFA) and preventing logins to the Acquia Cloud UI has been fully resolved, and all systems are now fully operational.\r\nIf you continue to experience any lingering issues, please reach out by filing a support ticket. Thank you for your patience during this interruption.",
362
  "first_seen": "2026-09-04T07:06:16Z",
363
  "impact": "critical",
364
- "last_seen": "2026-09-04T09:06:33Z",
365
  "resolved_at": "2026-04-20T07:12:30.830Z",
366
  "resolved_inferred": false,
367
  "started_at": "2026-04-20T05:39:45.365Z",
@@ -374,7 +376,7 @@
374
  "body": "Acquia has resolved the issue impacting code deployments for a subset of customers on our Cloud Platform. Users should no longer experience rejected git push commands, as full deployment functionality has been completely restored. We sincerely apologize for the inconvenience and appreciate your patience while we worked to fix this.",
375
  "first_seen": "2026-09-04T07:06:16Z",
376
  "impact": "minor",
377
- "last_seen": "2026-09-04T09:06:33Z",
378
  "resolved_at": "2026-04-17T20:22:32.552Z",
379
  "resolved_inferred": false,
380
  "started_at": "2026-04-17T17:32:37.000Z",
@@ -387,7 +389,7 @@
387
  "body": "Acquia has resolved the performance degradation affecting Log Streaming services on the Acquia Cloud Next platform. Log Streaming functionality has been fully restored, and customers should now see their logs streaming normally. We appreciate your patience and apologize for any inconvenience this may have caused.",
388
  "first_seen": "2026-09-04T07:06:16Z",
389
  "impact": "minor",
390
- "last_seen": "2026-09-04T09:06:33Z",
391
  "resolved_at": "2026-04-10T20:24:17.406Z",
392
  "resolved_inferred": false,
393
  "started_at": "2026-04-10T18:32:55.000Z",
@@ -400,7 +402,7 @@
400
  "body": "The issue impacting multiple sites has been resolved, and affected sites are now accessible.We will continue to review this incident internally. If you experience any further issues, please reach out via your existing support channels or respond to your open support ticket.Thank you for your patience.open support ticket.We will share further updates as more information becomes available.restore stability as quickly as possible.We will continue to provide updates as more information becomes available.",
401
  "first_seen": "2026-09-04T07:06:16Z",
402
  "impact": "major",
403
- "last_seen": "2026-09-04T09:06:33Z",
404
  "resolved_at": "2026-04-10T04:49:52.589Z",
405
  "resolved_inferred": false,
406
  "started_at": "2026-04-10T02:05:23.515Z",
@@ -413,7 +415,7 @@
413
  "body": "We have completed processing the accumulated work. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
414
  "first_seen": "2026-09-04T07:06:16Z",
415
  "impact": "minor",
416
- "last_seen": "2026-09-04T09:06:33Z",
417
  "resolved_at": "2026-04-09T20:47:53.730Z",
418
  "resolved_inferred": false,
419
  "started_at": "2026-04-09T13:12:50.041Z",
@@ -426,7 +428,7 @@
426
  "body": "The issue impacting accessibility across all Campaign Studio instances has been fully resolved. Our internal engineering team has implemented a fix, and all systems are now operating normally.",
427
  "first_seen": "2026-09-04T07:06:16Z",
428
  "impact": "critical",
429
- "last_seen": "2026-09-04T09:06:33Z",
430
  "resolved_at": "2026-03-25T15:50:04.027Z",
431
  "resolved_inferred": false,
432
  "started_at": "2026-03-25T13:55:14.654Z",
@@ -439,7 +441,7 @@
439
  "body": "The resource contention issue within our GCP US environment has been successfully resolved.\r\n\r\nOur engineering team has proactively rerun the majority of the stopped and failed input connectors and data refresh workflows. We are currently monitoring the final batch of these workflows to ensure they process completely and that all systems return to normal operation.\r\n\r\nThank you for your patience while our team worked to restore service.",
440
  "first_seen": "2026-09-04T07:06:16Z",
441
  "impact": "minor",
442
- "last_seen": "2026-09-04T09:06:33Z",
443
  "resolved_at": "2026-03-19T16:54:29.352Z",
444
  "resolved_inferred": false,
445
  "started_at": "2026-03-19T15:18:31.471Z",
@@ -452,7 +454,7 @@
452
  "body": "Acquia has successfully addressed the service interruption impacting a specific load balancer pair. Following a period of monitoring, all associated applications are confirmed to be stable and operating normally. Thank you for your patience and understanding while we worked to restore full service.",
453
  "first_seen": "2026-09-04T07:06:16Z",
454
  "impact": "critical",
455
- "last_seen": "2026-09-04T09:06:33Z",
456
  "resolved_at": "2026-03-14T12:05:01.673Z",
457
  "resolved_inferred": false,
458
  "started_at": "2026-03-13T01:04:10.797Z",
@@ -465,7 +467,7 @@
465
  "body": "Acquia has resolved the issue impacting the performance and accessibility of Acquia CDP in the AWS US region (hub2.agilone.com). Normal operations have been fully restored. We apologize for the inconvenience and appreciate your patience during this time.",
466
  "first_seen": "2026-09-04T07:06:16Z",
467
  "impact": "major",
468
- "last_seen": "2026-09-04T09:06:33Z",
469
  "resolved_at": "2026-02-26T18:52:29.632Z",
470
  "resolved_inferred": false,
471
  "started_at": "2026-02-26T18:18:47.252Z",
@@ -478,7 +480,7 @@
478
  "body": "The underlying cause of this service interruption has been addressed. All affected services have been restored. All services are operational at this time.",
479
  "first_seen": "2026-09-04T07:06:16Z",
480
  "impact": "major",
481
- "last_seen": "2026-09-04T09:06:33Z",
482
  "resolved_at": "2026-02-26T04:56:48.352Z",
483
  "resolved_inferred": false,
484
  "started_at": "2026-02-26T02:39:23.715Z",
@@ -491,7 +493,7 @@
491
  "body": "The issue affecting metrics reporting within the Cloud Platform user interface is resolved, and all systems are now operating normally. Connectivity with the backend metrics provider has been restored, with metrics ingestion working correctly and performance charts loading as expected in the Cloud UI. Throughout this incident, hosted applications and websites remained fully operational and were not affected.",
492
  "first_seen": "2026-09-04T07:06:16Z",
493
  "impact": "none",
494
- "last_seen": "2026-09-04T09:06:33Z",
495
  "resolved_at": "2026-01-29T10:33:15.218Z",
496
  "resolved_inferred": false,
497
  "started_at": "2026-01-29T04:24:38.939Z",
@@ -504,7 +506,7 @@
504
  "body": "Acquia has resolved the recent service interruption affecting some Applications across Acquia Cloud Next & Acquia Source platforms. All services are now operating normally, and we are no longer observing any related issues. Thank you for your patience and understanding while we worked to restore full service.",
505
  "first_seen": "2026-09-04T07:06:16Z",
506
  "impact": "major",
507
- "last_seen": "2026-09-04T09:06:33Z",
508
  "resolved_at": "2026-01-15T12:59:41.708Z",
509
  "resolved_inferred": false,
510
  "started_at": "2026-01-15T11:56:48.370Z",
@@ -517,7 +519,7 @@
517
  "body": "We've resolved the issue causing preview generation to be delayed for some customers. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
518
  "first_seen": "2026-09-04T07:06:16Z",
519
  "impact": "none",
520
- "last_seen": "2026-09-04T09:06:33Z",
521
  "resolved_at": "2025-12-22T17:12:11.813Z",
522
  "resolved_inferred": false,
523
  "started_at": "2025-12-19T20:55:47.867Z",
@@ -530,7 +532,7 @@
530
  "body": "Acquia has addressed the root cause of the interruption to Acquia Search services, restoring full functionality.",
531
  "first_seen": "2026-09-04T07:06:16Z",
532
  "impact": "major",
533
- "last_seen": "2026-09-04T09:06:33Z",
534
  "resolved_at": "2025-12-17T21:12:50.600Z",
535
  "resolved_inferred": false,
536
  "started_at": "2025-12-17T15:07:42.833Z",
@@ -543,7 +545,7 @@
543
  "body": "Acquia has addressed the root cause of the interruption to Acquia Search services, restoring full functionality.",
544
  "first_seen": "2026-09-04T07:06:16Z",
545
  "impact": "major",
546
- "last_seen": "2026-09-04T09:06:33Z",
547
  "resolved_at": "2025-12-16T23:14:04.762Z",
548
  "resolved_inferred": false,
549
  "started_at": "2025-12-16T18:26:54.000Z",
@@ -556,7 +558,7 @@
556
  "body": "Snowflake partial outage impacting Acquia Customer Data Platform (CDP) tenants hosted on AWS EU Prod has been fully resolved. All services are now operating normally, and we have observed stable performance since mitigation steps were completed at 15:59 UTC. No further issues have been detected, and all impacted processes have fully recovered.",
557
  "first_seen": "2026-09-04T07:06:16Z",
558
  "impact": "major",
559
- "last_seen": "2026-09-04T09:06:33Z",
560
  "resolved_at": "2025-12-16T18:39:41.265Z",
561
  "resolved_inferred": false,
562
  "started_at": "2025-12-16T05:59:13.009Z",
@@ -569,7 +571,7 @@
569
  "body": "Earlier today, an outage affecting Cloudflare services (including their status page, dashboard, and API) caused temporary access issues for Acquia-hosted websites and related services. During the disruption, some users were unable to reach their sites.\r\n\r\nCloudflare has since resolved the issue, and normal service has been fully restored. We will continue to monitor for any further impact.",
570
  "first_seen": "2026-09-04T07:06:16Z",
571
  "impact": "none",
572
- "last_seen": "2026-09-04T09:06:33Z",
573
  "resolved_at": "2025-12-05T09:25:09.275Z",
574
  "resolved_inferred": false,
575
  "started_at": "2025-12-05T09:25:09.232Z",
@@ -582,7 +584,7 @@
582
  "body": "We've resolved the issue causing increased error rates in the API (v2) and within DAM. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
583
  "first_seen": "2026-09-04T07:06:16Z",
584
  "impact": "minor",
585
- "last_seen": "2026-09-04T09:06:33Z",
586
  "resolved_at": "2025-12-04T14:51:57.810Z",
587
  "resolved_inferred": false,
588
  "started_at": "2025-12-04T14:44:41.199Z",
@@ -595,7 +597,7 @@
595
  "body": "The underlying cause of the service interruption affecting the Acquia Site Studio API endpoints has been addressed. All impacted Acquia services have been restored, and all services are now fully operational.",
596
  "first_seen": "2026-09-04T07:06:16Z",
597
  "impact": "major",
598
- "last_seen": "2026-09-04T09:06:33Z",
599
  "resolved_at": "2025-12-01T16:16:50.311Z",
600
  "resolved_inferred": false,
601
  "started_at": "2025-12-01T11:22:53.921Z",
@@ -608,7 +610,7 @@
608
  "body": "The underlying cause of this Acquia Source service interruption has been addressed. All affected Acquia Source services have been restored. All services are operational at this time.",
609
  "first_seen": "2026-09-04T07:06:16Z",
610
  "impact": "major",
611
- "last_seen": "2026-09-04T09:06:33Z",
612
  "resolved_at": "2025-11-18T18:11:47.868Z",
613
  "resolved_inferred": false,
614
  "started_at": "2025-11-18T13:52:04.000Z",
@@ -621,7 +623,7 @@
621
  "body": "The underlying cause of this service interruption has been addressed. All affected Services offered by Acquia Edge powered by Cloudflare has been resolved, and according to our upstream partner, Cloudflare services are currently operating normally with no elevated errors or latency being observed across their network.",
622
  "first_seen": "2026-09-04T07:06:16Z",
623
  "impact": "critical",
624
- "last_seen": "2026-09-04T09:06:33Z",
625
  "resolved_at": "2025-11-18T18:07:31.979Z",
626
  "resolved_inferred": false,
627
  "started_at": "2025-11-18T12:11:19.528Z",
@@ -634,7 +636,7 @@
634
  "body": "The underlying cause of this service interruption has been addressed. All affected services have been restored and operational now.",
635
  "first_seen": "2026-09-04T07:06:16Z",
636
  "impact": "major",
637
- "last_seen": "2026-09-04T09:06:33Z",
638
  "resolved_at": "2025-11-13T18:25:45.260Z",
639
  "resolved_inferred": false,
640
  "started_at": "2025-11-13T15:01:56.000Z",
@@ -647,7 +649,7 @@
647
  "body": "Update: The hotfix addressing the image editing issue for Acquia Source customers has been successfully released and tested.\r\nThe issue, which was introduced in version 2.19.0 as part of a canvas update, is now fully resolved.\r\nCustomers can now return to normal operations and no longer need to use the previously suggested workaround. Our team will continue to monitor the platform closely.",
648
  "first_seen": "2026-09-04T07:06:16Z",
649
  "impact": "minor",
650
- "last_seen": "2026-09-04T09:06:33Z",
651
  "resolved_at": "2025-10-30T08:36:30.732Z",
652
  "resolved_inferred": false,
653
  "started_at": "2025-10-28T12:06:26.000Z",
 
3
  "slug": "acquia",
4
  "platform": "statuspage",
5
  "status_url": "https://status.acquia.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "The service interruption impacting the Acquia Task system has been fully resolved. AWS US-WEST-2 operations have stabilized, and all queued tasks and system functions are operating normally.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-04T02:18:51.438Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T23:19:58.731Z",
 
22
  "url": "https://stspg.io/v80txq618pg9"
23
  },
24
  {
25
+ "body": "The issue impacting Site Studio endpoints has been fully resolved, and all systems are operational now.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
+ "resolved_at": "2026-09-04T09:39:11.352Z",
30
+ "resolved_inferred": false,
31
  "started_at": "2026-09-03T23:04:11.328Z",
32
+ "state": "resolved",
33
  "title": "Multiple customers are currently affected by what appears to be an outage impacting the Site Studio endpoint",
34
+ "updated_at": "2026-09-04T09:39:11.369Z",
35
  "url": "https://stspg.io/w32x9vnv014z"
36
  },
37
  {
38
  "body": "This incident has been resolved. Our upstream search infrastructure partner, SearchStax, has successfully implemented the fix, and Pulse Performance Graphs are now displaying as expected. Core search functionality was unaffected throughout this incident. We apologize for any inconvenience caused and thank you for your patience.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-09-04T02:04:42.869Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-09-03T16:27:23.205Z",
 
51
  "body": "We've resolve the problem causing an issue with some customers ability to log into DAM. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-09-03T16:24:58.769Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-09-03T15:05:24.973Z",
 
64
  "body": "The issue impacting access to the Pipelines UI and Dashboard for MEO customers has been fully resolved.\r\nA fix was deployed and verification was completed to confirm that the Pipelines Dashboard is fully operational and performing normally.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-09-03T00:13:18.597Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-09-02T21:39:29.077Z",
 
77
  "body": "We've resolved the issue causing degraded file processing for customers hosted in the EU and have completed processing work that accumulated during the incident. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-08-31T17:34:08.530Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-31T16:28:17.484Z",
 
90
  "body": "The issue affecting Edge Standard customers has been resolved. Akamai has addressed the vendor API issue, and security and performance metrics are now available in the Edge Standard UI",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-08-24T11:05:27.821Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-24T09:29:44.425Z",
 
103
  "body": "We can confirm that the issue was confirmed mitigated at 20:42 UTC on August 18, 2026 and the service has resumed normal operation.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-08-19T22:13:09.531Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-17T21:24:57.304Z",
 
116
  "body": "The log download issue affecting Acquia Cloud Next and MEO customers was resolved on Aug 11 09:38 UTC, and all systems are fully operational.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-08-12T09:27:30.470Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-11T07:40:11.926Z",
 
129
  "body": "The underlying cause of this service interruption has been addressed. All services are operational at this time.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-08-10T19:44:51.818Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-10T18:29:13.357Z",
 
142
  "body": "The underlying cause of this service interruption has been addressed. All services are operational at this time.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-08-06T22:48:56.050Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-06T21:54:59.185Z",
 
155
  "body": "The issue affecting Acquia Cloud Pipelines has been resolved. Pipeline processing has returned to normal operations, and all previously queued jobs have been handled. Please note that if any of your queued jobs failed with a \"system failure\" message during the incident, they can now be safely re-run. We appreciate your patience while we worked to restore service.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-08-04T16:21:44.669Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-08-04T14:45:30.862Z",
 
168
  "body": "The issue affecting related and popular search functionality and Pulse monitoring has been fully resolved. All systems are operational. We appreciate your patience during this incident.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-07-23T19:35:11.495Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-23T16:48:13.177Z",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-07-23T19:38:51.379Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-23T16:12:54.046Z",
 
194
  "body": "We've resolved the issue affecting the availability of some sites. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-07-22T01:21:56.231Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-21T23:08:40.700Z",
 
207
  "body": "The issue impacting Acquia Pipelines is now completely resolved. Git connectivity and pipeline processing have returned to normal operations, and we do not anticipate any further impact.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-07-21T12:37:49.198Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-21T11:39:26.101Z",
 
220
  "body": "The issue impacting CDN provisioning for Edge Standard has been fully resolved. New domain configurations are now processing successfully, and we have confirmed stability across the environment. No further impact is expected.\r\nWe apologise for any inconvenience caused and appreciate your patience while we worked through this.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-07-17T20:06:17.592Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-07-17T09:41:22.219Z",
 
233
  "body": "The underlying cause of this interruption has been addressed. All affected services have been restored. All services are operational at this time.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-06-22T21:54:48.409Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-06-22T14:59:09.557Z",
 
246
  "body": "The underlying cause of this interruption has been addressed. All affected services have been restored. All services are operational at this time.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-06-12T07:05:21.764Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-06-11T14:02:06.405Z",
 
259
  "body": "The login issues affecting Acquia Campaign Studio and Campaign Factory have been completely resolved, and all systems are fully operational.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-06-01T08:49:17.252Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-06-01T05:21:33.486Z",
 
272
  "body": "The issue with our upstream provider has been fully resolved, and all affected services have been restored to normal operations. Thank you for your patience while we worked to address this issue.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-05-09T13:54:11.219Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-05-08T00:16:50.607Z",
 
285
  "body": "We have resolved the issue causing degraded Portals performance for some customers. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-05-06T00:33:29.781Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-05-05T19:43:22.102Z",
 
298
  "body": "We've detected a service interruption affecting the stability for your application. The issue was quickly identified and resolved. Everything is up and running now.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-05-01T22:11:24.014Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-05-01T22:11:23.964Z",
 
311
  "body": "We've detected a service interruption affecting the shared load balancers for certain customer applications. All services are operational at this time.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "none",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-04-30T22:54:41.000Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-04-30T22:54:40.973Z",
 
324
  "body": "The underlying cause of this issue has been addressed. All affected services have been restored. All services are operational at this time.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-04-30T00:30:51.717Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-04-29T15:33:33.213Z",
 
337
  "body": "The issue impacting code deployments for a subset of customers on our Cloud Platform has now been resolved. Our engineering team has implemented a fix and all code deployment functionalities are now restored.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-04-22T06:33:38.288Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-04-21T16:41:30.881Z",
 
350
  "body": "The issue impacting code deployments for a subset of customers on our Cloud Platform has now been resolved. Our engineering team has implemented a fix and all code deployment functionalities are now restored.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-04-21T10:01:53.889Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-04-21T04:08:30.038Z",
 
363
  "body": "The issue impacting Two-Factor Authentication (TFA) and preventing logins to the Acquia Cloud UI has been fully resolved, and all systems are now fully operational.\r\nIf you continue to experience any lingering issues, please reach out by filing a support ticket. Thank you for your patience during this interruption.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "critical",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-04-20T07:12:30.830Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-04-20T05:39:45.365Z",
 
376
  "body": "Acquia has resolved the issue impacting code deployments for a subset of customers on our Cloud Platform. Users should no longer experience rejected git push commands, as full deployment functionality has been completely restored. We sincerely apologize for the inconvenience and appreciate your patience while we worked to fix this.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-04-17T20:22:32.552Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-04-17T17:32:37.000Z",
 
389
  "body": "Acquia has resolved the performance degradation affecting Log Streaming services on the Acquia Cloud Next platform. Log Streaming functionality has been fully restored, and customers should now see their logs streaming normally. We appreciate your patience and apologize for any inconvenience this may have caused.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-04-10T20:24:17.406Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-04-10T18:32:55.000Z",
 
402
  "body": "The issue impacting multiple sites has been resolved, and affected sites are now accessible.We will continue to review this incident internally. If you experience any further issues, please reach out via your existing support channels or respond to your open support ticket.Thank you for your patience.open support ticket.We will share further updates as more information becomes available.restore stability as quickly as possible.We will continue to provide updates as more information becomes available.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-04-10T04:49:52.589Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-04-10T02:05:23.515Z",
 
415
  "body": "We have completed processing the accumulated work. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-04-09T20:47:53.730Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-04-09T13:12:50.041Z",
 
428
  "body": "The issue impacting accessibility across all Campaign Studio instances has been fully resolved. Our internal engineering team has implemented a fix, and all systems are now operating normally.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "critical",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-03-25T15:50:04.027Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-03-25T13:55:14.654Z",
 
441
  "body": "The resource contention issue within our GCP US environment has been successfully resolved.\r\n\r\nOur engineering team has proactively rerun the majority of the stopped and failed input connectors and data refresh workflows. We are currently monitoring the final batch of these workflows to ensure they process completely and that all systems return to normal operation.\r\n\r\nThank you for your patience while our team worked to restore service.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-03-19T16:54:29.352Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-03-19T15:18:31.471Z",
 
454
  "body": "Acquia has successfully addressed the service interruption impacting a specific load balancer pair. Following a period of monitoring, all associated applications are confirmed to be stable and operating normally. Thank you for your patience and understanding while we worked to restore full service.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "critical",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-03-14T12:05:01.673Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-03-13T01:04:10.797Z",
 
467
  "body": "Acquia has resolved the issue impacting the performance and accessibility of Acquia CDP in the AWS US region (hub2.agilone.com). Normal operations have been fully restored. We apologize for the inconvenience and appreciate your patience during this time.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-02-26T18:52:29.632Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-02-26T18:18:47.252Z",
 
480
  "body": "The underlying cause of this service interruption has been addressed. All affected services have been restored. All services are operational at this time.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-02-26T04:56:48.352Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-02-26T02:39:23.715Z",
 
493
  "body": "The issue affecting metrics reporting within the Cloud Platform user interface is resolved, and all systems are now operating normally. Connectivity with the backend metrics provider has been restored, with metrics ingestion working correctly and performance charts loading as expected in the Cloud UI. Throughout this incident, hosted applications and websites remained fully operational and were not affected.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2026-01-29T10:33:15.218Z",
498
  "resolved_inferred": false,
499
  "started_at": "2026-01-29T04:24:38.939Z",
 
506
  "body": "Acquia has resolved the recent service interruption affecting some Applications across Acquia Cloud Next & Acquia Source platforms. All services are now operating normally, and we are no longer observing any related issues. Thank you for your patience and understanding while we worked to restore full service.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2026-01-15T12:59:41.708Z",
511
  "resolved_inferred": false,
512
  "started_at": "2026-01-15T11:56:48.370Z",
 
519
  "body": "We've resolved the issue causing preview generation to be delayed for some customers. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "none",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-12-22T17:12:11.813Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-12-19T20:55:47.867Z",
 
532
  "body": "Acquia has addressed the root cause of the interruption to Acquia Search services, restoring full functionality.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-12-17T21:12:50.600Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-12-17T15:07:42.833Z",
 
545
  "body": "Acquia has addressed the root cause of the interruption to Acquia Search services, restoring full functionality.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-12-16T23:14:04.762Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-12-16T18:26:54.000Z",
 
558
  "body": "Snowflake partial outage impacting Acquia Customer Data Platform (CDP) tenants hosted on AWS EU Prod has been fully resolved. All services are now operating normally, and we have observed stable performance since mitigation steps were completed at 15:59 UTC. No further issues have been detected, and all impacted processes have fully recovered.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2025-12-16T18:39:41.265Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-12-16T05:59:13.009Z",
 
571
  "body": "Earlier today, an outage affecting Cloudflare services (including their status page, dashboard, and API) caused temporary access issues for Acquia-hosted websites and related services. During the disruption, some users were unable to reach their sites.\r\n\r\nCloudflare has since resolved the issue, and normal service has been fully restored. We will continue to monitor for any further impact.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-12-05T09:25:09.275Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-12-05T09:25:09.232Z",
 
584
  "body": "We've resolved the issue causing increased error rates in the API (v2) and within DAM. Contact Customer Support for help on Acquia DAM Community if you continue to experience any ongoing issues.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2025-12-04T14:51:57.810Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-12-04T14:44:41.199Z",
 
597
  "body": "The underlying cause of the service interruption affecting the Acquia Site Studio API endpoints has been addressed. All impacted Acquia services have been restored, and all services are now fully operational.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "major",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2025-12-01T16:16:50.311Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-12-01T11:22:53.921Z",
 
610
  "body": "The underlying cause of this Acquia Source service interruption has been addressed. All affected Acquia Source services have been restored. All services are operational at this time.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "major",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2025-11-18T18:11:47.868Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-11-18T13:52:04.000Z",
 
623
  "body": "The underlying cause of this service interruption has been addressed. All affected Services offered by Acquia Edge powered by Cloudflare has been resolved, and according to our upstream partner, Cloudflare services are currently operating normally with no elevated errors or latency being observed across their network.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "critical",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2025-11-18T18:07:31.979Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-11-18T12:11:19.528Z",
 
636
  "body": "The underlying cause of this service interruption has been addressed. All affected services have been restored and operational now.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "major",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2025-11-13T18:25:45.260Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-11-13T15:01:56.000Z",
 
649
  "body": "Update: The hotfix addressing the image editing issue for Acquia Source customers has been successfully released and tested.\r\nThe issue, which was introduced in version 2.19.0 as part of a canvas update, is now fully resolved.\r\nCustomers can now return to normal operations and no longer need to use the previously suggested workaround. Our team will continue to monitor the platform closely.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2025-10-30T08:36:30.732Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-10-28T12:06:26.000Z",
api/v/actionstep.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "actionstep",
4
  "platform": "statuspage",
5
  "status_url": "https://status.actionstep.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This issue has now been fixed, and our Engineering team has confirmed that the Actionstep Practice Management platform is now stable and fully operational again.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-28T16:18:51.487+12:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T12:17:47.187+12:00",
@@ -25,7 +25,7 @@
25
  "body": "The issues affecting the Actionstep Practice Management platform have now been resolved. Engineering team confirmed that the services are now fully functional.\n\nWe apologise for any inconvenience this may have caused.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-28T11:45:25.920+12:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-28T11:30:28.050+12:00",
@@ -38,7 +38,7 @@
38
  "body": "The issues affecting the Actionstep Practice Management platform have now been resolved, and our technical teams have confirmed that all services are now fully functional.\n\nWe would like to apologise for any inconvenience this may have caused.\n\nRegards,\nThe Actionstep Team",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-27T15:13:13.772+12:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-27T14:50:48.000+12:00",
@@ -51,7 +51,7 @@
51
  "body": "**Resolved** - Between 00:15\u201301:00 NZST, some Actionstep users were unable to log in to the website. The issue affected users on UK servers, particularly eu-west-1.actionstep.com.\n\nImpact: Login access only. No customer data was affected.\n\nCause: Currently investigating\n\nWorking Solution: Clearing cookies and cache or restarting your machine has shown to resolve the issue.\n\nFor further help, log a ticket at [https://support.actionstep.com](https://support.actionstep.com/)",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-11T01:11:30.000+12:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-11T00:00:41.000+12:00",
@@ -64,7 +64,7 @@
64
  "body": "Between 19:39\u201322:00 NZST, some Actionstep users were unable to log in to the website. The issue affected users on certain ISPs, particularly Virgin Media.\n\nImpact: Login access only. No customer data was affected or moved.\n\nCause: Likely network or routing changes on the affected ISPs impacting access to the Actionstep login page. Affected customers should contact their ISP to check for recent changes.\n\nData location clarification: No customer data is stored in AP Southeast 2. That region only serves the login page. Once you select your system tile, you're redirected to the data centre where your system actually resides (UK region for UK customers). Your data has not moved and remains stored in your designated region.\n\nWorkaround: If you're still affected, use a mobile hotspot to reach the login page and sign in, then switch back to your normal Wi-Fi once logged in.\n\nFor further help, log a ticket at https://support.actionstep.com",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-31T06:00:00.000+12:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-31T02:23:52.367+12:00",
@@ -77,7 +77,7 @@
77
  "body": "We are communicating to provide further information on the issues that affected the Actionstep Gmail Add-on platform which started the 1st of June, 2026 and confirm that the issue is now resolved.\n\nWhat happened:\nThe Gmail Add-on was running on the deprecated Google Apps Script Rhino runtime. Google ended support for the Rhino runtime, which caused the add-on to fail before any app logic could execute.\n\nWhat we did:\nOur team migrated the Apps Script project to the V8 runtime, created a new deployment version, and redeployed the Gmail Add-on. The add-on is now fully operational.\n\nWhat we're doing to prevent this:\nWe have reviewed our runtime dependencies to ensure we are not relying on deprecated infrastructure going forward.\n\nWe apologise for any disruption this caused and thank you for your patience.\n\nRegards,\nActionstep Support Team",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-06-04T12:31:20.408+12:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-03T13:38:49.308+12:00",
@@ -90,7 +90,7 @@
90
  "body": "The root cause of this issue has now been resolved. \n\nIf you are still experiencing performance degradation and seeing 500 errors, please reach out to support@actionstep.com.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-05-22T18:22:44.539+12:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-05-22T13:25:41.017+12:00",
@@ -103,7 +103,7 @@
103
  "body": "Xero has resolved the issue impacting customers. Xero is now stable and customers should be able to use the platform normally.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-05-11T12:50:04.094+12:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-05-11T11:53:46.504+12:00",
@@ -116,7 +116,7 @@
116
  "body": "We are communicating to provide further information on the outage that affected the Actionstep platform and confirm that the issue is now resolved.\n\nThis outage started from 9:15am NZT, and prevented user access to the system. Some customers who managed to log in experienced error messages and periods of instability and slowness.\n\nIt is important to confirm that no data was lost, and the issue related to access to platform only.\n\nOur team investigated the issue as the sole priority and released an urgent fix at 9:51am NZT which restored platform access and brought system performance back to normal levels.\n\nThe Actionstep team appreciate the impact that this outage may have had on your business, and we want to reiterate our commitment to improving the experience of all customers who use the platform.\n\nWe have identified the root cause of the issue and implemented steps to prevent it from occurring again in future.\n\nRegards,\nActionstep Support Team",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-03-17T10:00:26.541+13:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-03-17T09:42:40.000+13:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved. Staging systems are now accessible and back online.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-03-11T21:04:01.000+13:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-03-11T18:07:52.558+13:00",
@@ -142,7 +142,7 @@
142
  "body": "We are pleased to report that Microsoft have resolved the issues that were impacting users who rely on Microsoft Authenticator for multi-factor authentication (MFA) when signing in to Actionstep Practice Management and Legal Accounting.\n\nThank you for your patience during this Microsoft service outage.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-01-23T19:41:30.875+13:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-01-23T09:26:14.000+13:00",
@@ -155,7 +155,7 @@
155
  "body": "**Post-Incident Summary:** United Kingdom \u2013 External Connectivity Issue \u2013 December 4, 2025\n\n**Incident Overview** \nOn December 4, 2025, some customers in the United Kingdom \u2013 primarily those using Sky Broadband \u2013 experienced difficulty accessing the Actionstep login page. This login page \\(also known as the Launchpad\\) is hosted in the ap-southeast-2 region; however, no customer data for UK systems is stored or processed in this region. Once a user selects their system, they are directed to the appropriate UK/region-specific server where their data resides.\n\nOur investigation confirmed that this incident was caused entirely by a Sky ISP routing/connectivity issue preventing requests from reaching a wide variety of services hosted in ap-southeast-2. Actionstep also contacted AWS, who confirmed we were one of hundreds of services affected by the Sky outage. There was no issue with the Actionstep platform, AWS infrastructure, or our regional hosting.\n\nThe issue began at approximately 2:30 pm GMT on December 4, 2025, and normal access was fully restored by December 9, 2025\n\n**Impact** \nCustomers in the UK using Sky Broadband were intermittently or completely unable to reach the Actionstep login page due to Sky\u2019s network routing issue.\n\nCustomers using other ISPs, or those switching to an alternative connection such as mobile data, were able to access Actionstep normally.\n\nAt all times, the Actionstep platform itself remained operational.\n\n**Resolution** \nOnce Sky resolved their connectivity issue, normal access to the Actionstep login page was restored.\n\nThroughout the incident, Actionstep systems continued to perform normally, and users connecting from unaffected networks experienced no disruption.\n\n**Next Steps** \nNo Actionstep changes are required, as the root cause was external to our systems and infrastructure.\n\nIf customers encounter similar symptoms in the future, we recommend testing an alternative connection \\(such as a mobile hotspot\\) and contacting their ISP to confirm whether a localised network issue is occurring.\n\n**Acknowledgement** \nWe recognise that this caused inconvenience for affected customers and appreciate everyone\u2019s patience while Sky resolved their network routing issue. Ensuring reliable access to Actionstep remains our priority.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-12-06T04:43:53.000+13:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-05T03:30:01.000+13:00",
@@ -168,7 +168,7 @@
168
  "body": "We are communicating to provide further information on the outage that affected the Actionstep system on 11/11/2025 and confirm that the issue is now resolved.\n\nThis outage started at 8:30 am EST and prevented user access to the system. Some customers who managed to log in experienced error messages and periods of instability and slowness.\n\nIt is important to confirm that no data was lost, and the issue is related to platform performance only.\n\nOur team investigated the issue as the sole priority and released an urgent fix at 11:20 am EST, which restored platform access and brought system performance back to normal levels.\n\nThe Actionstep team appreciates the impact that this outage may have had on your business, and we want to reiterate our commitment to improving the experience of all customers who use the platform.\n\nWe have identified the root cause of the issue and implemented steps to prevent it from occurring again in the future.\n\nRegards,\nActionstep Support Team",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-11-12T05:30:49.414+13:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-12T05:20:18.064+13:00",
@@ -181,7 +181,7 @@
181
  "body": "**Post-Incident Summary: US \u2013 Actionstep Payments Outage \u2013 October 17, 2024**\n\n### Incident Overview\n\nOn October 17, 2024, Actionstep experienced a service outage affecting the Actionstep Payments platform in the US. A configuration update inadvertently restricted access to a required system resource, which caused payment processing and related services to become temporarily unavailable.\n\n### Impact\n\nUS-based customers were unable to process payments or access related payment features for approximately one hour.\n\n### Resolution\n\nThe engineering team identified the configuration issue, restored access to the affected resource, and confirmed that all payment services were operating normally. Service was fully restored once functionality was verified across multiple customer accounts.\n\n### Next Steps\n\nWe are strengthening our change control and rollout processes to ensure configuration updates are thoroughly tested and deployed safely, with improved monitoring and communication to detect and address issues more quickly.\n\n### Acknowledgement\n\nWe sincerely apologize for the disruption this caused to our US customers. Maintaining reliable and uninterrupted access to Actionstep Payments remains a priority.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2025-11-07T05:22:39.661+13:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-11-07T04:58:03.012+13:00",
@@ -194,7 +194,7 @@
194
  "body": "**Post-Incident Summary: EU-West-1 \\(UK\\) \u2013 System Outage \u2013 October 17, 2024**\n\n### Incident Overview\n\nOn October 17, 2024, Actionstep experienced a service outage affecting customers in the UK region \\(EU-West-1\\). A configuration update inadvertently restricted access to a required system resource, which caused login failures and prevented users from accessing the platform.\n\n### Impact\n\nAll UK-based customers were unable to log in or use Actionstep for about one hour. Internal testing environments in the same region were also affected.\n\n### Resolution\n\nThe engineering team identified the configuration issue, restored access to the affected resource, and confirmed that all systems were operating normally. Service was fully restored once access was verified across multiple customer accounts.\n\n### Next Steps\n\nWe are improving our change control and rollout processes to ensure configuration updates are tested and deployed safely, with enhanced communication and monitoring to detect issues earlier.\n\n### Acknowledgement\n\nWe sincerely apologize for the disruption this caused to our UK customers. Ensuring consistent access and reliability remains our highest priority.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "critical",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2025-11-06T22:26:52.620+13:00",
199
  "resolved_inferred": false,
200
  "started_at": "2025-11-06T21:45:55.000+13:00",
@@ -207,7 +207,7 @@
207
  "body": "**Post-Incident Summary:** Microsoft Dependency Disruption \u2013 Global \u2013 October 29, 2025 \n\n**Incident Overview** \nOn October 29, 2025, a widespread outage affecting Microsoft\u2019s Azure Front Door service caused latency, timeouts, and service errors across Microsoft 365 and Azure platforms. This impacted Actionstep features that rely on Microsoft services. \n\n**Impact** \nDuring the incident, some users experienced difficulty accessing Microsoft-related functionality, including the Outlook Add-in, OneDrive integrations, and Office 365 email services. Service availability improved as Microsoft began recovery efforts, though intermittent issues persisted for some users. \n\n**Resolution** \nMicrosoft reloaded configurations and rebalanced traffic across its network to restore full operational capacity. As of 23:20\u202fUTC, Microsoft reported significant progress, and Actionstep services dependent on Microsoft systems have largely returned to normal operation. \n\n**Next Steps** \nActionstep will continue monitoring Microsoft\u2019s recovery and ensure all integrations remain stable. We are also reviewing dependency monitoring to improve early detection of third-party disruptions. \n\n**Acknowledgement** \nWe appreciate your patience during this incident and apologize for the inconvenience. Ensuring reliable access to all integrated services remains a top priority for Actionstep.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2025-10-30T11:55:00.221+13:00",
212
  "resolved_inferred": false,
213
  "started_at": "2025-10-30T05:50:29.191+13:00",
@@ -220,7 +220,7 @@
220
  "body": "On November 6, 2025, Actionstep\u2019s main website \\([actionstep.com](http://actionstep.com)\\) became temporarily unavailable during a scheduled maintenance activity. The maintenance affected only the public website and did not impact access to the Actionstep application.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2025-10-22T12:40:39.116+13:00",
225
  "resolved_inferred": false,
226
  "started_at": "2025-10-22T12:05:55.203+13:00",
@@ -233,7 +233,7 @@
233
  "body": "**Post-Incident Summary: North America \\(US-East-1\\) \u2013 AWS Outage Impact \u2013 October 20, 2025**\n\n**Incident Overview** \nOn October 20, 2025, Actionstep services in the US-East-1 region were affected by a widespread outage within Amazon Web Services \\(AWS\\). This incident originated from AWS infrastructure and impacted many cloud-based platforms globally, not just Actionstep. As a result, customers experienced degraded performance and intermittent downtime across the Practice Management and Legal Accounting platforms.\n\n**Impact** \nThe outage occurred between approximately **9:39 a.m. and 2:19 p.m. MDT**. During this period, some customers in North America experienced slow performance, timeouts, and temporary unavailability of certain features. The issue was entirely due to an AWS infrastructure failure and was not caused by Actionstep systems or changes.\n\n**Resolution** \nAWS restored functionality in the affected region, after which Actionstep systems automatically recovered. Our engineering team closely monitored the recovery process and validated all environments to confirm full stability and normal operation. \n \nFor more information about this outage, please see the AWS website: [Service health - Oct 20, 2025 | AWS Health Dashboard | Global](https://health.aws.amazon.com/health/status)\n\n**Next Steps** \nWe are reviewing our communication and monitoring processes to ensure faster updates and improved transparency during third-party service disruptions. We are also exploring additional resilience measures to minimize the impact of future upstream provider outages.\n\n**Acknowledgement** \nWe understand the disruption this caused and apologize for the impact on your firm\u2019s operations. While this incident originated outside of Actionstep\u2019s control, we remain committed to maintaining system reliability and ensuring clear, timely communication during any service interruption.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "critical",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2025-10-21T09:19:47.950+13:00",
238
  "resolved_inferred": false,
239
  "started_at": "2025-10-21T04:39:35.092+13:00",
@@ -246,7 +246,7 @@
246
  "body": "**Post-Incident Summary: Global \u2013 Third-Party Communication Outage \u2013 October 20, 2025**\n\n**Incident Overview** \nOn October 20, 2025, a widespread AWS outage in the US-East-1 region affected several third-party platforms, including Freshdesk and Intercom. As a result, Actionstep\u2019s Support and Accounting teams were unable to send or receive tickets, live chats, or email communications during the disruption.\n\n**Impact** \nThe issue occurred between approximately **9:38 a.m. and 10:04 a.m. MDT**. During this time, customers were unable to contact Actionstep Support or Accounting through normal channels. The outage originated from AWS infrastructure supporting Freshdesk and Intercom and did not involve any Actionstep systems.\n\n**Resolution** \nFreshdesk restored services once AWS resolved the underlying issue. Actionstep teams verified full functionality and resumed normal support operations immediately after recovery.\n\n**Next Steps** \nWe are reviewing backup communication options and evaluating redundancy for critical customer communication tools to ensure we can continue providing updates and assistance during future third-party outages.\n\n**Acknowledgement** \nWe understand the inconvenience this caused and apologize for the disruption to your ability to reach our teams. Maintaining reliable communication and support availability is a top priority, and we are taking steps to strengthen our resilience against external service interruptions.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2025-10-21T05:04:30.222+13:00",
251
  "resolved_inferred": false,
252
  "started_at": "2025-10-21T04:38:40.000+13:00",
@@ -259,7 +259,7 @@
259
  "body": "### **Post-Incident Summary: Staging Environment Outage \u2013 October 13, 2025**\n\n**Incident Overview** \nOn October 13, 2025, Actionstep\u2019s Staging environment experienced a temporary service interruption following a system update that affected how application services processed requests.\n\n**Impact** \nBetween 11:29 \u2013 12:20 UTC and again 22:16 \u2013 22:33 UTC, users accessing the Staging environment encountered errors and were unable to complete normal testing or pre-release activities.\n\n**Resolution** \nThe engineering team identified the update as the cause and restored service by rolling back to a stable configuration. Functionality was verified and all systems in Staging returned to normal operation.\n\n**Next Steps** \nWe are refining our deployment and testing procedures to ensure updates to non-production environments are validated without impacting users. Additional automated checks and pre-deployment reviews will be implemented.\n\n**Acknowledgement** \nWe apologize for the disruption this caused. Maintaining reliable and predictable environments for testing and validation remains a key priority.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "critical",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2025-10-14T11:50:28.279+13:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-10-14T11:40:07.452+13:00",
@@ -272,7 +272,7 @@
272
  "body": "### **Post-Incident Summary: Production Environment Outage \u2013 October 13, 2025**\n\n**Incident Overview** \nOn October 13, 2025, Actionstep experienced two brief service interruptions in the Production environment caused by a system update that affected how application services processed requests.\n\n**Impact** \nCustomers across all regions experienced temporary unavailability between 11:29 \u2013 12:20 UTC and 22:16 \u2013 22:33 UTC. During these times, users were unable to access or perform actions within the platform.\n\n**Resolution** \nThe engineering team identified the cause and restored service by rolling back the recent update to a stable version. The corrected configuration was rebuilt, tested, and redeployed to confirm full restoration of normal operations.\n\n**Next Steps** \nWe are enhancing our testing and deployment processes to prevent similar issues. This includes improved validation of system updates, additional automated testing before release, and refined monitoring to detect issues earlier.\n\n**Acknowledgement** \nWe sincerely apologize for the disruption and appreciate your patience. Maintaining a stable and reliable platform remains our highest priority.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "critical",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2025-10-14T01:27:32.210+13:00",
277
  "resolved_inferred": false,
278
  "started_at": "2025-10-14T00:33:09.000+13:00",
@@ -285,7 +285,7 @@
285
  "body": "We are communicating to provide further information on the issue affecting Reports, document generation, email assignment, and invoice finalization on the eu-west-1 platform on October 3, 2025, and confirm that the issue is now resolved.\n\nThis issue impacted the ability to run reports, finalize invoices, and assign emails via Gmail/Outlook add-ins from 09:00 BST to 10:15 BST, and resulted in tasks being stuck in processing without completion.\n\nIt is important to confirm that no data was lost, and the issue is related to platform performance only.\nOur team investigated the issue as the sole priority during the day and released an urgent fix at 10:15 BST, which restored all functionality to normal operations.\n\nThe Actionstep team appreciates the impact that this issue may have had on your business, and we want to reiterate our commitment to improving the experience of all customers who use the platform.\n\nWe have identified the root cause of the issue and implemented steps to prevent it from occurring again in the future.\n\nRegards,\nActionstep Support Team",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2025-10-03T22:22:24.069+13:00",
290
  "resolved_inferred": false,
291
  "started_at": "2025-10-03T21:26:18.672+13:00",
@@ -298,7 +298,7 @@
298
  "body": "**Post-Incident Summary: North America Feature Outage \u2013 September 19, 2025**\n\n**Incident Overview** \nOn September 19, 2025, Actionstep experienced an outage affecting several features in North America, including document, contact, and custom data management, as well as integrations such as Outlook, Word, and Zapier. Customers encountered 403 error messages during this time.\n\n**Impact** \nThe issue occurred between 11:45 a.m. MDT and 1:00 p.m. MDT. During this period, customers in North America were unable to reliably use the affected features.\n\n**Resolution** \nOur engineering team identified the root cause and worked with our partners to remediate the issue. Full functionality was restored by 1:00 p.m. MDT.\n\n**Next Steps** \nWe are implementing additional safeguards in our change management and quality assurance processes to ensure this type of disruption does not occur again.\n\n**Acknowledgement** \nWe understand the disruption this caused and apologize for the impact on your firm\u2019s operations. Maintaining system stability and reliability is our top priority, and we are taking steps to strengthen our controls and prevent recurrence.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "major",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2025-09-20T07:24:42.549+12:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-09-20T05:45:51.000+12:00",
@@ -311,7 +311,7 @@
311
  "body": "We are providing additional information about the issue affecting Actionstep Practice Management on August 15, 2025, and confirming that the problem has now been resolved.\n\nThe issues began at 11:51AM MDT and were resolved by 12:10PM MDT.\n\nIt is important to confirm that no data was lost and that the issue was related solely to platform performance.\n\nOur team prioritized investigating the problem and restored functionality to normal operations.\n\nThe Actionstep team understands the impact this issue may have had on your business, and we want to reaffirm our commitment to enhancing the experience for all customers using the platform.\n\nRegards,\nActionstep Support Team",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2025-08-16T06:16:12.650+12:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-08-16T06:03:01.926+12:00",
@@ -324,7 +324,7 @@
324
  "body": "We recently experienced a service interruption on our eu-west-1 server on the 5th of August 2025 that caused degraded performance for some customers. The issue was related to unusually high levels of API activity on one of our servers, which impacted system stability.\n\nWe isolated the source of the high traffic and moved it to a separate environment to restore performance. We are also reviewing our current rate-limiting and monitoring systems to help prevent similar issues in the future.\n\nWe apologise for any inconvenience this caused and thank you for your understanding as we continue to improve the reliability of our service.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2025-08-06T03:21:48.821+12:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-08-06T02:15:26.000+12:00",
 
3
  "slug": "actionstep",
4
  "platform": "statuspage",
5
  "status_url": "https://status.actionstep.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This issue has now been fixed, and our Engineering team has confirmed that the Actionstep Practice Management platform is now stable and fully operational again.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-28T16:18:51.487+12:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T12:17:47.187+12:00",
 
25
  "body": "The issues affecting the Actionstep Practice Management platform have now been resolved. Engineering team confirmed that the services are now fully functional.\n\nWe apologise for any inconvenience this may have caused.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-28T11:45:25.920+12:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-28T11:30:28.050+12:00",
 
38
  "body": "The issues affecting the Actionstep Practice Management platform have now been resolved, and our technical teams have confirmed that all services are now fully functional.\n\nWe would like to apologise for any inconvenience this may have caused.\n\nRegards,\nThe Actionstep Team",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-27T15:13:13.772+12:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-27T14:50:48.000+12:00",
 
51
  "body": "**Resolved** - Between 00:15\u201301:00 NZST, some Actionstep users were unable to log in to the website. The issue affected users on UK servers, particularly eu-west-1.actionstep.com.\n\nImpact: Login access only. No customer data was affected.\n\nCause: Currently investigating\n\nWorking Solution: Clearing cookies and cache or restarting your machine has shown to resolve the issue.\n\nFor further help, log a ticket at [https://support.actionstep.com](https://support.actionstep.com/)",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-11T01:11:30.000+12:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-11T00:00:41.000+12:00",
 
64
  "body": "Between 19:39\u201322:00 NZST, some Actionstep users were unable to log in to the website. The issue affected users on certain ISPs, particularly Virgin Media.\n\nImpact: Login access only. No customer data was affected or moved.\n\nCause: Likely network or routing changes on the affected ISPs impacting access to the Actionstep login page. Affected customers should contact their ISP to check for recent changes.\n\nData location clarification: No customer data is stored in AP Southeast 2. That region only serves the login page. Once you select your system tile, you're redirected to the data centre where your system actually resides (UK region for UK customers). Your data has not moved and remains stored in your designated region.\n\nWorkaround: If you're still affected, use a mobile hotspot to reach the login page and sign in, then switch back to your normal Wi-Fi once logged in.\n\nFor further help, log a ticket at https://support.actionstep.com",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-31T06:00:00.000+12:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-31T02:23:52.367+12:00",
 
77
  "body": "We are communicating to provide further information on the issues that affected the Actionstep Gmail Add-on platform which started the 1st of June, 2026 and confirm that the issue is now resolved.\n\nWhat happened:\nThe Gmail Add-on was running on the deprecated Google Apps Script Rhino runtime. Google ended support for the Rhino runtime, which caused the add-on to fail before any app logic could execute.\n\nWhat we did:\nOur team migrated the Apps Script project to the V8 runtime, created a new deployment version, and redeployed the Gmail Add-on. The add-on is now fully operational.\n\nWhat we're doing to prevent this:\nWe have reviewed our runtime dependencies to ensure we are not relying on deprecated infrastructure going forward.\n\nWe apologise for any disruption this caused and thank you for your patience.\n\nRegards,\nActionstep Support Team",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-06-04T12:31:20.408+12:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-03T13:38:49.308+12:00",
 
90
  "body": "The root cause of this issue has now been resolved. \n\nIf you are still experiencing performance degradation and seeing 500 errors, please reach out to support@actionstep.com.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-05-22T18:22:44.539+12:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-05-22T13:25:41.017+12:00",
 
103
  "body": "Xero has resolved the issue impacting customers. Xero is now stable and customers should be able to use the platform normally.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-05-11T12:50:04.094+12:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-05-11T11:53:46.504+12:00",
 
116
  "body": "We are communicating to provide further information on the outage that affected the Actionstep platform and confirm that the issue is now resolved.\n\nThis outage started from 9:15am NZT, and prevented user access to the system. Some customers who managed to log in experienced error messages and periods of instability and slowness.\n\nIt is important to confirm that no data was lost, and the issue related to access to platform only.\n\nOur team investigated the issue as the sole priority and released an urgent fix at 9:51am NZT which restored platform access and brought system performance back to normal levels.\n\nThe Actionstep team appreciate the impact that this outage may have had on your business, and we want to reiterate our commitment to improving the experience of all customers who use the platform.\n\nWe have identified the root cause of the issue and implemented steps to prevent it from occurring again in future.\n\nRegards,\nActionstep Support Team",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-03-17T10:00:26.541+13:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-03-17T09:42:40.000+13:00",
 
129
  "body": "This incident has been resolved. Staging systems are now accessible and back online.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-03-11T21:04:01.000+13:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-03-11T18:07:52.558+13:00",
 
142
  "body": "We are pleased to report that Microsoft have resolved the issues that were impacting users who rely on Microsoft Authenticator for multi-factor authentication (MFA) when signing in to Actionstep Practice Management and Legal Accounting.\n\nThank you for your patience during this Microsoft service outage.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-01-23T19:41:30.875+13:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-01-23T09:26:14.000+13:00",
 
155
  "body": "**Post-Incident Summary:** United Kingdom \u2013 External Connectivity Issue \u2013 December 4, 2025\n\n**Incident Overview** \nOn December 4, 2025, some customers in the United Kingdom \u2013 primarily those using Sky Broadband \u2013 experienced difficulty accessing the Actionstep login page. This login page \\(also known as the Launchpad\\) is hosted in the ap-southeast-2 region; however, no customer data for UK systems is stored or processed in this region. Once a user selects their system, they are directed to the appropriate UK/region-specific server where their data resides.\n\nOur investigation confirmed that this incident was caused entirely by a Sky ISP routing/connectivity issue preventing requests from reaching a wide variety of services hosted in ap-southeast-2. Actionstep also contacted AWS, who confirmed we were one of hundreds of services affected by the Sky outage. There was no issue with the Actionstep platform, AWS infrastructure, or our regional hosting.\n\nThe issue began at approximately 2:30 pm GMT on December 4, 2025, and normal access was fully restored by December 9, 2025\n\n**Impact** \nCustomers in the UK using Sky Broadband were intermittently or completely unable to reach the Actionstep login page due to Sky\u2019s network routing issue.\n\nCustomers using other ISPs, or those switching to an alternative connection such as mobile data, were able to access Actionstep normally.\n\nAt all times, the Actionstep platform itself remained operational.\n\n**Resolution** \nOnce Sky resolved their connectivity issue, normal access to the Actionstep login page was restored.\n\nThroughout the incident, Actionstep systems continued to perform normally, and users connecting from unaffected networks experienced no disruption.\n\n**Next Steps** \nNo Actionstep changes are required, as the root cause was external to our systems and infrastructure.\n\nIf customers encounter similar symptoms in the future, we recommend testing an alternative connection \\(such as a mobile hotspot\\) and contacting their ISP to confirm whether a localised network issue is occurring.\n\n**Acknowledgement** \nWe recognise that this caused inconvenience for affected customers and appreciate everyone\u2019s patience while Sky resolved their network routing issue. Ensuring reliable access to Actionstep remains our priority.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-12-06T04:43:53.000+13:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-05T03:30:01.000+13:00",
 
168
  "body": "We are communicating to provide further information on the outage that affected the Actionstep system on 11/11/2025 and confirm that the issue is now resolved.\n\nThis outage started at 8:30 am EST and prevented user access to the system. Some customers who managed to log in experienced error messages and periods of instability and slowness.\n\nIt is important to confirm that no data was lost, and the issue is related to platform performance only.\n\nOur team investigated the issue as the sole priority and released an urgent fix at 11:20 am EST, which restored platform access and brought system performance back to normal levels.\n\nThe Actionstep team appreciates the impact that this outage may have had on your business, and we want to reiterate our commitment to improving the experience of all customers who use the platform.\n\nWe have identified the root cause of the issue and implemented steps to prevent it from occurring again in the future.\n\nRegards,\nActionstep Support Team",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-11-12T05:30:49.414+13:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-12T05:20:18.064+13:00",
 
181
  "body": "**Post-Incident Summary: US \u2013 Actionstep Payments Outage \u2013 October 17, 2024**\n\n### Incident Overview\n\nOn October 17, 2024, Actionstep experienced a service outage affecting the Actionstep Payments platform in the US. A configuration update inadvertently restricted access to a required system resource, which caused payment processing and related services to become temporarily unavailable.\n\n### Impact\n\nUS-based customers were unable to process payments or access related payment features for approximately one hour.\n\n### Resolution\n\nThe engineering team identified the configuration issue, restored access to the affected resource, and confirmed that all payment services were operating normally. Service was fully restored once functionality was verified across multiple customer accounts.\n\n### Next Steps\n\nWe are strengthening our change control and rollout processes to ensure configuration updates are thoroughly tested and deployed safely, with improved monitoring and communication to detect and address issues more quickly.\n\n### Acknowledgement\n\nWe sincerely apologize for the disruption this caused to our US customers. Maintaining reliable and uninterrupted access to Actionstep Payments remains a priority.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2025-11-07T05:22:39.661+13:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-11-07T04:58:03.012+13:00",
 
194
  "body": "**Post-Incident Summary: EU-West-1 \\(UK\\) \u2013 System Outage \u2013 October 17, 2024**\n\n### Incident Overview\n\nOn October 17, 2024, Actionstep experienced a service outage affecting customers in the UK region \\(EU-West-1\\). A configuration update inadvertently restricted access to a required system resource, which caused login failures and prevented users from accessing the platform.\n\n### Impact\n\nAll UK-based customers were unable to log in or use Actionstep for about one hour. Internal testing environments in the same region were also affected.\n\n### Resolution\n\nThe engineering team identified the configuration issue, restored access to the affected resource, and confirmed that all systems were operating normally. Service was fully restored once access was verified across multiple customer accounts.\n\n### Next Steps\n\nWe are improving our change control and rollout processes to ensure configuration updates are tested and deployed safely, with enhanced communication and monitoring to detect issues earlier.\n\n### Acknowledgement\n\nWe sincerely apologize for the disruption this caused to our UK customers. Ensuring consistent access and reliability remains our highest priority.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "critical",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2025-11-06T22:26:52.620+13:00",
199
  "resolved_inferred": false,
200
  "started_at": "2025-11-06T21:45:55.000+13:00",
 
207
  "body": "**Post-Incident Summary:** Microsoft Dependency Disruption \u2013 Global \u2013 October 29, 2025 \n\n**Incident Overview** \nOn October 29, 2025, a widespread outage affecting Microsoft\u2019s Azure Front Door service caused latency, timeouts, and service errors across Microsoft 365 and Azure platforms. This impacted Actionstep features that rely on Microsoft services. \n\n**Impact** \nDuring the incident, some users experienced difficulty accessing Microsoft-related functionality, including the Outlook Add-in, OneDrive integrations, and Office 365 email services. Service availability improved as Microsoft began recovery efforts, though intermittent issues persisted for some users. \n\n**Resolution** \nMicrosoft reloaded configurations and rebalanced traffic across its network to restore full operational capacity. As of 23:20\u202fUTC, Microsoft reported significant progress, and Actionstep services dependent on Microsoft systems have largely returned to normal operation. \n\n**Next Steps** \nActionstep will continue monitoring Microsoft\u2019s recovery and ensure all integrations remain stable. We are also reviewing dependency monitoring to improve early detection of third-party disruptions. \n\n**Acknowledgement** \nWe appreciate your patience during this incident and apologize for the inconvenience. Ensuring reliable access to all integrated services remains a top priority for Actionstep.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2025-10-30T11:55:00.221+13:00",
212
  "resolved_inferred": false,
213
  "started_at": "2025-10-30T05:50:29.191+13:00",
 
220
  "body": "On November 6, 2025, Actionstep\u2019s main website \\([actionstep.com](http://actionstep.com)\\) became temporarily unavailable during a scheduled maintenance activity. The maintenance affected only the public website and did not impact access to the Actionstep application.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2025-10-22T12:40:39.116+13:00",
225
  "resolved_inferred": false,
226
  "started_at": "2025-10-22T12:05:55.203+13:00",
 
233
  "body": "**Post-Incident Summary: North America \\(US-East-1\\) \u2013 AWS Outage Impact \u2013 October 20, 2025**\n\n**Incident Overview** \nOn October 20, 2025, Actionstep services in the US-East-1 region were affected by a widespread outage within Amazon Web Services \\(AWS\\). This incident originated from AWS infrastructure and impacted many cloud-based platforms globally, not just Actionstep. As a result, customers experienced degraded performance and intermittent downtime across the Practice Management and Legal Accounting platforms.\n\n**Impact** \nThe outage occurred between approximately **9:39 a.m. and 2:19 p.m. MDT**. During this period, some customers in North America experienced slow performance, timeouts, and temporary unavailability of certain features. The issue was entirely due to an AWS infrastructure failure and was not caused by Actionstep systems or changes.\n\n**Resolution** \nAWS restored functionality in the affected region, after which Actionstep systems automatically recovered. Our engineering team closely monitored the recovery process and validated all environments to confirm full stability and normal operation. \n \nFor more information about this outage, please see the AWS website: [Service health - Oct 20, 2025 | AWS Health Dashboard | Global](https://health.aws.amazon.com/health/status)\n\n**Next Steps** \nWe are reviewing our communication and monitoring processes to ensure faster updates and improved transparency during third-party service disruptions. We are also exploring additional resilience measures to minimize the impact of future upstream provider outages.\n\n**Acknowledgement** \nWe understand the disruption this caused and apologize for the impact on your firm\u2019s operations. While this incident originated outside of Actionstep\u2019s control, we remain committed to maintaining system reliability and ensuring clear, timely communication during any service interruption.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "critical",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2025-10-21T09:19:47.950+13:00",
238
  "resolved_inferred": false,
239
  "started_at": "2025-10-21T04:39:35.092+13:00",
 
246
  "body": "**Post-Incident Summary: Global \u2013 Third-Party Communication Outage \u2013 October 20, 2025**\n\n**Incident Overview** \nOn October 20, 2025, a widespread AWS outage in the US-East-1 region affected several third-party platforms, including Freshdesk and Intercom. As a result, Actionstep\u2019s Support and Accounting teams were unable to send or receive tickets, live chats, or email communications during the disruption.\n\n**Impact** \nThe issue occurred between approximately **9:38 a.m. and 10:04 a.m. MDT**. During this time, customers were unable to contact Actionstep Support or Accounting through normal channels. The outage originated from AWS infrastructure supporting Freshdesk and Intercom and did not involve any Actionstep systems.\n\n**Resolution** \nFreshdesk restored services once AWS resolved the underlying issue. Actionstep teams verified full functionality and resumed normal support operations immediately after recovery.\n\n**Next Steps** \nWe are reviewing backup communication options and evaluating redundancy for critical customer communication tools to ensure we can continue providing updates and assistance during future third-party outages.\n\n**Acknowledgement** \nWe understand the inconvenience this caused and apologize for the disruption to your ability to reach our teams. Maintaining reliable communication and support availability is a top priority, and we are taking steps to strengthen our resilience against external service interruptions.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2025-10-21T05:04:30.222+13:00",
251
  "resolved_inferred": false,
252
  "started_at": "2025-10-21T04:38:40.000+13:00",
 
259
  "body": "### **Post-Incident Summary: Staging Environment Outage \u2013 October 13, 2025**\n\n**Incident Overview** \nOn October 13, 2025, Actionstep\u2019s Staging environment experienced a temporary service interruption following a system update that affected how application services processed requests.\n\n**Impact** \nBetween 11:29 \u2013 12:20 UTC and again 22:16 \u2013 22:33 UTC, users accessing the Staging environment encountered errors and were unable to complete normal testing or pre-release activities.\n\n**Resolution** \nThe engineering team identified the update as the cause and restored service by rolling back to a stable configuration. Functionality was verified and all systems in Staging returned to normal operation.\n\n**Next Steps** \nWe are refining our deployment and testing procedures to ensure updates to non-production environments are validated without impacting users. Additional automated checks and pre-deployment reviews will be implemented.\n\n**Acknowledgement** \nWe apologize for the disruption this caused. Maintaining reliable and predictable environments for testing and validation remains a key priority.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "critical",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2025-10-14T11:50:28.279+13:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-10-14T11:40:07.452+13:00",
 
272
  "body": "### **Post-Incident Summary: Production Environment Outage \u2013 October 13, 2025**\n\n**Incident Overview** \nOn October 13, 2025, Actionstep experienced two brief service interruptions in the Production environment caused by a system update that affected how application services processed requests.\n\n**Impact** \nCustomers across all regions experienced temporary unavailability between 11:29 \u2013 12:20 UTC and 22:16 \u2013 22:33 UTC. During these times, users were unable to access or perform actions within the platform.\n\n**Resolution** \nThe engineering team identified the cause and restored service by rolling back the recent update to a stable version. The corrected configuration was rebuilt, tested, and redeployed to confirm full restoration of normal operations.\n\n**Next Steps** \nWe are enhancing our testing and deployment processes to prevent similar issues. This includes improved validation of system updates, additional automated testing before release, and refined monitoring to detect issues earlier.\n\n**Acknowledgement** \nWe sincerely apologize for the disruption and appreciate your patience. Maintaining a stable and reliable platform remains our highest priority.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "critical",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2025-10-14T01:27:32.210+13:00",
277
  "resolved_inferred": false,
278
  "started_at": "2025-10-14T00:33:09.000+13:00",
 
285
  "body": "We are communicating to provide further information on the issue affecting Reports, document generation, email assignment, and invoice finalization on the eu-west-1 platform on October 3, 2025, and confirm that the issue is now resolved.\n\nThis issue impacted the ability to run reports, finalize invoices, and assign emails via Gmail/Outlook add-ins from 09:00 BST to 10:15 BST, and resulted in tasks being stuck in processing without completion.\n\nIt is important to confirm that no data was lost, and the issue is related to platform performance only.\nOur team investigated the issue as the sole priority during the day and released an urgent fix at 10:15 BST, which restored all functionality to normal operations.\n\nThe Actionstep team appreciates the impact that this issue may have had on your business, and we want to reiterate our commitment to improving the experience of all customers who use the platform.\n\nWe have identified the root cause of the issue and implemented steps to prevent it from occurring again in the future.\n\nRegards,\nActionstep Support Team",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2025-10-03T22:22:24.069+13:00",
290
  "resolved_inferred": false,
291
  "started_at": "2025-10-03T21:26:18.672+13:00",
 
298
  "body": "**Post-Incident Summary: North America Feature Outage \u2013 September 19, 2025**\n\n**Incident Overview** \nOn September 19, 2025, Actionstep experienced an outage affecting several features in North America, including document, contact, and custom data management, as well as integrations such as Outlook, Word, and Zapier. Customers encountered 403 error messages during this time.\n\n**Impact** \nThe issue occurred between 11:45 a.m. MDT and 1:00 p.m. MDT. During this period, customers in North America were unable to reliably use the affected features.\n\n**Resolution** \nOur engineering team identified the root cause and worked with our partners to remediate the issue. Full functionality was restored by 1:00 p.m. MDT.\n\n**Next Steps** \nWe are implementing additional safeguards in our change management and quality assurance processes to ensure this type of disruption does not occur again.\n\n**Acknowledgement** \nWe understand the disruption this caused and apologize for the impact on your firm\u2019s operations. Maintaining system stability and reliability is our top priority, and we are taking steps to strengthen our controls and prevent recurrence.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "major",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2025-09-20T07:24:42.549+12:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-09-20T05:45:51.000+12:00",
 
311
  "body": "We are providing additional information about the issue affecting Actionstep Practice Management on August 15, 2025, and confirming that the problem has now been resolved.\n\nThe issues began at 11:51AM MDT and were resolved by 12:10PM MDT.\n\nIt is important to confirm that no data was lost and that the issue was related solely to platform performance.\n\nOur team prioritized investigating the problem and restored functionality to normal operations.\n\nThe Actionstep team understands the impact this issue may have had on your business, and we want to reaffirm our commitment to enhancing the experience for all customers using the platform.\n\nRegards,\nActionstep Support Team",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2025-08-16T06:16:12.650+12:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-08-16T06:03:01.926+12:00",
 
324
  "body": "We recently experienced a service interruption on our eu-west-1 server on the 5th of August 2025 that caused degraded performance for some customers. The issue was related to unusually high levels of API activity on one of our servers, which impacted system stability.\n\nWe isolated the source of the high traffic and moved it to a separate environment to restore performance. We are also reviewing our current rate-limiting and monitoring systems to help prevent similar issues in the future.\n\nWe apologise for any inconvenience this caused and thank you for your understanding as we continue to improve the reliability of our service.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2025-08-06T03:21:48.821+12:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-08-06T02:15:26.000+12:00",
api/v/activecampaign.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "activecampaign",
4
  "platform": "statuspage",
5
  "status_url": "https://status.activecampaign.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-28T14:16:25.097-05:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T13:48:25.278-05:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-10T11:59:28.519-05:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-10T09:14:44.666-05:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-06T06:40:41.073-05:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-05T05:59:01.092-05:00",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-03T16:24:16.195-05:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-03T14:34:10.486-05:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-30T18:16:42.747-05:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-30T17:23:12.776-05:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "critical",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-07-27T16:15:08.095-05:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-27T14:53:03.779-05:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-07-15T11:02:37.487-05:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-10T01:57:43.982-05:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-09T21:01:51.711-05:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-09T19:49:18.228-05:00",
@@ -116,7 +116,7 @@
116
  "body": "Engineers have implemented a fix. all regions are now fully operational again.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-06-26T18:09:12.753-05:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-26T17:38:13.000-05:00",
@@ -129,7 +129,7 @@
129
  "body": "We believe this issue is resolved at this time. If customers are continuing to experience issues loading the pages in question, they should contact support.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-06-23T08:52:54.356-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-18T18:19:46.000-05:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident was resolved about 1:29pm CT. No further impact has been observed.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-06-01T16:29:10.424-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-06-01T09:07:18.187-05:00",
@@ -155,7 +155,7 @@
155
  "body": "Engineers have successfully deployed the fix across all systems. Testing confirms that the option to edit advanced searches and segmentations within the Contacts section is now fully restored and operating normally.\n\nThis incident is now resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-05-19T06:44:16.503-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-19T04:15:53.539-05:00",
@@ -168,7 +168,7 @@
168
  "body": "Engineers have released a fix to address the issues impacting the platform. Normal service has been restored for all impacted users.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-04-28T11:24:23.776-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-28T06:04:28.000-05:00",
@@ -181,7 +181,7 @@
181
  "body": "this incident is now resolved. customers should see their automations load.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-04-13T16:12:00.176-05:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-13T15:07:11.966-05:00",
@@ -194,7 +194,7 @@
194
  "body": "Campaign delays in the EU region have been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-03-26T20:01:16.468-05:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-03-26T12:57:51.080-05:00",
@@ -207,7 +207,7 @@
207
  "body": "Engineers have verified the fix in our production environment",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-03-26T10:29:57.094-05:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-03-26T06:56:23.115-05:00",
@@ -220,7 +220,7 @@
220
  "body": "The issues affecting service connectivity have been resolved. Following a coordinated effort with our infrastructure partners, all systems are now fully operational and performing as expected",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-03-05T17:28:06.984-06:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-05T16:43:50.786-06:00",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-02-18T15:55:24.457-06:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-02-18T15:00:09.165-06:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-02-16T09:29:28.966-06:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-02-13T13:02:25.000-06:00",
@@ -259,7 +259,7 @@
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "major",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-02-17T04:47:50.603-06:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-02-10T10:40:31.000-06:00",
@@ -272,7 +272,7 @@
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-01-30T12:10:15.052-06:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-01-30T11:48:53.651-06:00",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-01-09T19:01:39.918-06:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-09T09:59:17.518-06:00",
@@ -298,7 +298,7 @@
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-01-04T18:51:44.041-06:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-01-04T18:19:28.325-06:00",
@@ -311,7 +311,7 @@
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2025-12-27T11:28:21.597-06:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-12-27T11:00:19.306-06:00",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2025-12-14T18:56:05.136-06:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-12-13T09:42:15.663-06:00",
@@ -337,7 +337,7 @@
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2025-12-13T09:39:02.230-06:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-12-11T12:59:46.690-06:00",
@@ -350,7 +350,7 @@
350
  "body": "All landing pages are loading as expected.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "none",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2025-11-20T12:06:05.916-06:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-11-20T11:28:30.486-06:00",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2025-11-17T14:24:07.765-06:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-11-17T13:54:53.181-06:00",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-11-06T17:50:01.130-06:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-11-06T14:47:12.449-06:00",
@@ -389,7 +389,7 @@
389
  "body": "Engineering and support has confirmed that the issue is resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-11-05T07:24:18.453-06:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-11-05T04:59:28.578-06:00",
@@ -402,7 +402,7 @@
402
  "body": "All services should be functioning normally at this time.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-11-04T12:04:53.447-06:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-11-04T10:41:50.039-06:00",
@@ -415,7 +415,7 @@
415
  "body": "Engineers have identified the cause of the login verification email issue and have implemented a solution.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "major",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-10-27T22:39:26.576-05:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-10-27T21:56:24.625-05:00",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-10-21T06:38:43.168-05:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-10-20T04:52:00.774-05:00",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-09-12T14:44:59.938-05:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-09-12T13:09:15.996-05:00",
@@ -454,7 +454,7 @@
454
  "body": "The issue has been addressed and there should be no further delays in automations and/or email campaign sending.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-09-09T17:58:34.850-05:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-09-09T17:15:11.942-05:00",
@@ -467,7 +467,7 @@
467
  "body": "Our monitoring shows all systems operating normally. The issue has been fully resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-09-05T12:56:35.263-05:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-05T11:21:22.594-05:00",
@@ -480,7 +480,7 @@
480
  "body": "This incident has been resolved",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "minor",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-09-03T20:49:24.458-05:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-03T19:28:55.794-05:00",
@@ -493,7 +493,7 @@
493
  "body": "Engineers have resolved the issue and service to connected emails has been restored.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-08-12T04:45:27.663-05:00",
498
  "resolved_inferred": false,
499
  "started_at": "2025-08-12T04:29:48.000-05:00",
@@ -506,7 +506,7 @@
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "minor",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-08-04T17:49:37.903-05:00",
511
  "resolved_inferred": false,
512
  "started_at": "2025-08-04T15:30:01.637-05:00",
 
3
  "slug": "activecampaign",
4
  "platform": "statuspage",
5
  "status_url": "https://status.activecampaign.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-28T14:16:25.097-05:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T13:48:25.278-05:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-10T11:59:28.519-05:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-10T09:14:44.666-05:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-06T06:40:41.073-05:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-05T05:59:01.092-05:00",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-03T16:24:16.195-05:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-03T14:34:10.486-05:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-30T18:16:42.747-05:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-30T17:23:12.776-05:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "critical",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-07-27T16:15:08.095-05:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-27T14:53:03.779-05:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-07-15T11:02:37.487-05:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-10T01:57:43.982-05:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-09T21:01:51.711-05:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-09T19:49:18.228-05:00",
 
116
  "body": "Engineers have implemented a fix. all regions are now fully operational again.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-06-26T18:09:12.753-05:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-26T17:38:13.000-05:00",
 
129
  "body": "We believe this issue is resolved at this time. If customers are continuing to experience issues loading the pages in question, they should contact support.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-06-23T08:52:54.356-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-18T18:19:46.000-05:00",
 
142
  "body": "This incident was resolved about 1:29pm CT. No further impact has been observed.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-06-01T16:29:10.424-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-06-01T09:07:18.187-05:00",
 
155
  "body": "Engineers have successfully deployed the fix across all systems. Testing confirms that the option to edit advanced searches and segmentations within the Contacts section is now fully restored and operating normally.\n\nThis incident is now resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-05-19T06:44:16.503-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-19T04:15:53.539-05:00",
 
168
  "body": "Engineers have released a fix to address the issues impacting the platform. Normal service has been restored for all impacted users.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-04-28T11:24:23.776-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-28T06:04:28.000-05:00",
 
181
  "body": "this incident is now resolved. customers should see their automations load.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-04-13T16:12:00.176-05:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-13T15:07:11.966-05:00",
 
194
  "body": "Campaign delays in the EU region have been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-03-26T20:01:16.468-05:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-03-26T12:57:51.080-05:00",
 
207
  "body": "Engineers have verified the fix in our production environment",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-03-26T10:29:57.094-05:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-03-26T06:56:23.115-05:00",
 
220
  "body": "The issues affecting service connectivity have been resolved. Following a coordinated effort with our infrastructure partners, all systems are now fully operational and performing as expected",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-03-05T17:28:06.984-06:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-05T16:43:50.786-06:00",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-02-18T15:55:24.457-06:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-02-18T15:00:09.165-06:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-02-16T09:29:28.966-06:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-02-13T13:02:25.000-06:00",
 
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "major",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-02-17T04:47:50.603-06:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-02-10T10:40:31.000-06:00",
 
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-01-30T12:10:15.052-06:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-01-30T11:48:53.651-06:00",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-01-09T19:01:39.918-06:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-09T09:59:17.518-06:00",
 
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-01-04T18:51:44.041-06:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-01-04T18:19:28.325-06:00",
 
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2025-12-27T11:28:21.597-06:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-12-27T11:00:19.306-06:00",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2025-12-14T18:56:05.136-06:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-12-13T09:42:15.663-06:00",
 
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2025-12-13T09:39:02.230-06:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-12-11T12:59:46.690-06:00",
 
350
  "body": "All landing pages are loading as expected.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "none",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2025-11-20T12:06:05.916-06:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-11-20T11:28:30.486-06:00",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2025-11-17T14:24:07.765-06:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-11-17T13:54:53.181-06:00",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-11-06T17:50:01.130-06:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-11-06T14:47:12.449-06:00",
 
389
  "body": "Engineering and support has confirmed that the issue is resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-11-05T07:24:18.453-06:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-11-05T04:59:28.578-06:00",
 
402
  "body": "All services should be functioning normally at this time.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-11-04T12:04:53.447-06:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-11-04T10:41:50.039-06:00",
 
415
  "body": "Engineers have identified the cause of the login verification email issue and have implemented a solution.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "major",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-10-27T22:39:26.576-05:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-10-27T21:56:24.625-05:00",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-10-21T06:38:43.168-05:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-10-20T04:52:00.774-05:00",
 
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-09-12T14:44:59.938-05:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-09-12T13:09:15.996-05:00",
 
454
  "body": "The issue has been addressed and there should be no further delays in automations and/or email campaign sending.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-09-09T17:58:34.850-05:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-09-09T17:15:11.942-05:00",
 
467
  "body": "Our monitoring shows all systems operating normally. The issue has been fully resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-09-05T12:56:35.263-05:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-05T11:21:22.594-05:00",
 
480
  "body": "This incident has been resolved",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "minor",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-09-03T20:49:24.458-05:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-03T19:28:55.794-05:00",
 
493
  "body": "Engineers have resolved the issue and service to connected emails has been restored.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-08-12T04:45:27.663-05:00",
498
  "resolved_inferred": false,
499
  "started_at": "2025-08-12T04:29:48.000-05:00",
 
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "minor",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-08-04T17:49:37.903-05:00",
511
  "resolved_inferred": false,
512
  "started_at": "2025-08-04T15:30:01.637-05:00",
api/v/ada.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "ada",
4
  "platform": "statuspage",
5
  "status_url": "https://status.ada.support",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-01T14:05:01.353-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T12:37:40.797-04:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-27T11:39:56.280-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-27T10:49:19.000-04:00",
@@ -38,7 +38,7 @@
38
  "body": "Query performance in US2 has returned to normal baseline levels and all affected endpoints. Conversation View, transcripts, conversation search, and analytics dashboards are responding at expected speeds.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-25T16:35:47.632-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-25T16:24:50.282-04:00",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved. Timing for conversations appearing in the conversations view has returned to normal. Thank you for your patience.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-24T12:23:28.018-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-24T11:12:48.515-04:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-08-21T11:09:25.710-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-21T09:11:54.778-04:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-08-11T10:25:24.029-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-11T09:22:59.181-04:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-07-24T15:32:11.423-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-24T06:41:35.187-04:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-21T11:41:34.074-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-21T10:29:11.672-04:00",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-07-16T21:48:01.885-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-16T20:48:39.897-04:00",
@@ -129,7 +129,7 @@
129
  "body": "WorkOS fix is now effective, and we have stopped monitoring the issue.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-07-16T07:49:39.924-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-07-16T06:41:35.964-04:00",
@@ -142,7 +142,7 @@
142
  "body": "A fix has been deployed, and queued Zendesk Emails are being sent out now.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-07-14T09:51:42.512-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-07-14T09:31:45.953-04:00",
@@ -155,7 +155,7 @@
155
  "body": "The team was able to identify the root cause and a fix is in place.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-07-13T15:56:31.244-04:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-07-12T07:45:13.809-04:00",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-07-10T15:12:50.051-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-10T12:46:48.261-04:00",
@@ -181,7 +181,7 @@
181
  "body": "The incident have been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-07-09T00:55:10.471-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-09T00:44:49.553-04:00",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-07-07T10:28:05.712-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-07T07:54:58.552-04:00",
@@ -207,7 +207,7 @@
207
  "body": "Identified and resolved an issue affecting some internal background data processing. Our team corrected it and confirmed all systems have returned to normal operation.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-07-06T18:38:43.759-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-06T17:33:00.000-04:00",
@@ -220,7 +220,7 @@
220
  "body": "The incident has been resolved",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-05-26T18:15:53.709-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-05-26T16:58:29.586-04:00",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-05-25T12:04:16.138-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-05-25T10:28:50.696-04:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "critical",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-05-21T20:22:51.674-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-05-21T18:28:09.942-04:00",
@@ -259,7 +259,7 @@
259
  "body": "The certificate rotation issue has been fully resolved. Error rates have returned to normal levels and services are operating as expected. No further impact is anticipated",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-05-11T10:49:49.000-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-05-10T15:55:10.212-04:00",
@@ -272,7 +272,7 @@
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-05-05T17:50:48.014-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-05-05T17:01:49.250-04:00",
@@ -285,7 +285,7 @@
285
  "body": "Based on our Engineering Team's investigation, we have determined the scope of this issue is limited to a very small number of clients and affected conversations. We are continuing to work on the issue, but moving forward will be communicating on this issue on an individual basis.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-05-01T14:37:07.094-04:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-05-01T12:32:47.211-04:00",
@@ -298,7 +298,7 @@
298
  "body": "We have resolved an issue that caused an increase in emergency handoffs for a subset of customers.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-04-28T16:30:42.903-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-04-28T15:57:32.000-04:00",
@@ -311,7 +311,7 @@
311
  "body": "We have identified the root cause of the language detection issue affecting non-English responses. Improvements are actively in progress and will be delivered as part of our ongoing engineering work.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-04-24T13:00:38.433-04:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-04-24T11:06:03.532-04:00",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-04-09T18:39:52.778-04:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-04-09T18:12:04.000-04:00",
@@ -337,7 +337,7 @@
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "major",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-04-07T15:35:36.933-04:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-04-07T11:37:19.445-04:00",
@@ -350,7 +350,7 @@
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-04-07T18:07:04.000-04:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-04-07T11:27:14.000-04:00",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-04-06T21:10:08.968-04:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-04-06T19:37:38.348-04:00",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-04-03T13:53:32.449-04:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-04-03T12:38:45.037-04:00",
@@ -389,7 +389,7 @@
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-04-03T14:40:48.735-04:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-04-03T12:32:00.864-04:00",
@@ -402,7 +402,7 @@
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-04-01T10:01:44.660-04:00",
407
  "resolved_inferred": false,
408
  "started_at": "2026-04-01T09:13:35.470-04:00",
@@ -415,7 +415,7 @@
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-03-25T16:42:03.244-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2026-03-25T13:46:45.694-04:00",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2026-03-24T17:02:18.394-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2026-03-24T11:29:33.852-04:00",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "major",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2026-03-05T19:03:10.249-05:00",
446
  "resolved_inferred": false,
447
  "started_at": "2026-03-05T18:51:44.922-05:00",
@@ -454,7 +454,7 @@
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2026-02-08T17:04:05.545-05:00",
459
  "resolved_inferred": false,
460
  "started_at": "2026-02-08T12:16:11.479-05:00",
@@ -467,7 +467,7 @@
467
  "body": "This incident has been resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2026-02-05T15:30:20.766-05:00",
472
  "resolved_inferred": false,
473
  "started_at": "2026-02-05T11:50:57.264-05:00",
@@ -480,7 +480,7 @@
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "minor",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2026-02-03T10:34:52.065-05:00",
485
  "resolved_inferred": false,
486
  "started_at": "2026-02-02T16:33:52.000-05:00",
@@ -493,7 +493,7 @@
493
  "body": "The issue impacting Salesforce Messaging integration performance has been resolved. Chats should now connect to agents as expected. We will continue to monitor to ensure ongoing stability.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2026-01-31T14:24:04.232-05:00",
498
  "resolved_inferred": false,
499
  "started_at": "2026-01-31T13:45:56.542-05:00",
@@ -506,7 +506,7 @@
506
  "body": "Analytics availability has been restored following an upstream provider outage. Clients may notice minor discrepancies in analytics data from approximately 4:00\u20136:00 AM ET, which will be automatically backfilled later today. We will continue to monitor to ensure everything remains stable.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2026-01-31T07:10:05.942-05:00",
511
  "resolved_inferred": false,
512
  "started_at": "2026-01-31T05:00:44.587-05:00",
@@ -519,7 +519,7 @@
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "critical",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2026-01-22T14:54:46.016-05:00",
524
  "resolved_inferred": false,
525
  "started_at": "2026-01-22T14:03:47.869-05:00",
@@ -532,7 +532,7 @@
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "minor",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2026-01-19T21:11:59.571-05:00",
537
  "resolved_inferred": false,
538
  "started_at": "2026-01-19T20:01:34.444-05:00",
@@ -545,7 +545,7 @@
545
  "body": "This incident has been resolved",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2026-01-07T11:30:30.794-05:00",
550
  "resolved_inferred": false,
551
  "started_at": "2026-01-07T11:20:42.543-05:00",
@@ -558,7 +558,7 @@
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "minor",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2026-01-05T20:25:26.062-05:00",
563
  "resolved_inferred": false,
564
  "started_at": "2026-01-05T16:01:32.520-05:00",
@@ -571,7 +571,7 @@
571
  "body": "The issue with the Ada Dashboard has been resolved and Dashboard users should see things functioning normally again.\nOur team will continue to monitor the fix. We\u2019re sorry for the impact of this issue and appreciate your understanding.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "minor",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2025-12-15T19:50:29.409-05:00",
576
  "resolved_inferred": false,
577
  "started_at": "2025-12-15T17:48:22.285-05:00",
@@ -584,7 +584,7 @@
584
  "body": "The issue with a delay in the knowledge articles updating has been resolved and regular update cadence has been re-instated. Our team will continue to monitor the fix. We\u2019re sorry for the impact of this issue and appreciate your understanding.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2025-12-10T19:22:30.431-05:00",
589
  "resolved_inferred": false,
590
  "started_at": "2025-12-10T16:15:08.802-05:00",
@@ -597,7 +597,7 @@
597
  "body": "The issue with Ada Voice has been resolved and chatters should see things functioning normally again.\nOur team will continue to monitor the fix. We\u2019re sorry for the impact of this issue and appreciate your understanding.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "major",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2025-12-10T16:06:34.404-05:00",
602
  "resolved_inferred": false,
603
  "started_at": "2025-12-10T15:22:18.909-05:00",
@@ -610,7 +610,7 @@
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2025-12-10T01:05:01.286-05:00",
615
  "resolved_inferred": false,
616
  "started_at": "2025-12-10T00:19:52.197-05:00",
@@ -623,7 +623,7 @@
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2025-12-08T20:33:19.575-05:00",
628
  "resolved_inferred": false,
629
  "started_at": "2025-12-08T19:20:21.899-05:00",
@@ -636,7 +636,7 @@
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "major",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2025-12-01T23:17:03.587-05:00",
641
  "resolved_inferred": false,
642
  "started_at": "2025-12-01T11:59:52.508-05:00",
@@ -649,7 +649,7 @@
649
  "body": "The incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2025-11-21T05:27:05.560-05:00",
654
  "resolved_inferred": false,
655
  "started_at": "2025-11-21T04:26:10.489-05:00",
 
3
  "slug": "ada",
4
  "platform": "statuspage",
5
  "status_url": "https://status.ada.support",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-01T14:05:01.353-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T12:37:40.797-04:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-27T11:39:56.280-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-27T10:49:19.000-04:00",
 
38
  "body": "Query performance in US2 has returned to normal baseline levels and all affected endpoints. Conversation View, transcripts, conversation search, and analytics dashboards are responding at expected speeds.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-25T16:35:47.632-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-25T16:24:50.282-04:00",
 
51
  "body": "This incident has been resolved. Timing for conversations appearing in the conversations view has returned to normal. Thank you for your patience.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-24T12:23:28.018-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-24T11:12:48.515-04:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-08-21T11:09:25.710-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-21T09:11:54.778-04:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-08-11T10:25:24.029-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-11T09:22:59.181-04:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-07-24T15:32:11.423-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-24T06:41:35.187-04:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-21T11:41:34.074-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-21T10:29:11.672-04:00",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-07-16T21:48:01.885-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-16T20:48:39.897-04:00",
 
129
  "body": "WorkOS fix is now effective, and we have stopped monitoring the issue.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-07-16T07:49:39.924-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-07-16T06:41:35.964-04:00",
 
142
  "body": "A fix has been deployed, and queued Zendesk Emails are being sent out now.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-07-14T09:51:42.512-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-07-14T09:31:45.953-04:00",
 
155
  "body": "The team was able to identify the root cause and a fix is in place.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-07-13T15:56:31.244-04:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-07-12T07:45:13.809-04:00",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-07-10T15:12:50.051-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-10T12:46:48.261-04:00",
 
181
  "body": "The incident have been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-07-09T00:55:10.471-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-09T00:44:49.553-04:00",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-07-07T10:28:05.712-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-07T07:54:58.552-04:00",
 
207
  "body": "Identified and resolved an issue affecting some internal background data processing. Our team corrected it and confirmed all systems have returned to normal operation.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-07-06T18:38:43.759-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-06T17:33:00.000-04:00",
 
220
  "body": "The incident has been resolved",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-05-26T18:15:53.709-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-05-26T16:58:29.586-04:00",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-05-25T12:04:16.138-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-05-25T10:28:50.696-04:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "critical",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-05-21T20:22:51.674-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-05-21T18:28:09.942-04:00",
 
259
  "body": "The certificate rotation issue has been fully resolved. Error rates have returned to normal levels and services are operating as expected. No further impact is anticipated",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-05-11T10:49:49.000-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-05-10T15:55:10.212-04:00",
 
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-05-05T17:50:48.014-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-05-05T17:01:49.250-04:00",
 
285
  "body": "Based on our Engineering Team's investigation, we have determined the scope of this issue is limited to a very small number of clients and affected conversations. We are continuing to work on the issue, but moving forward will be communicating on this issue on an individual basis.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-05-01T14:37:07.094-04:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-05-01T12:32:47.211-04:00",
 
298
  "body": "We have resolved an issue that caused an increase in emergency handoffs for a subset of customers.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-04-28T16:30:42.903-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-04-28T15:57:32.000-04:00",
 
311
  "body": "We have identified the root cause of the language detection issue affecting non-English responses. Improvements are actively in progress and will be delivered as part of our ongoing engineering work.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-04-24T13:00:38.433-04:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-04-24T11:06:03.532-04:00",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-04-09T18:39:52.778-04:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-04-09T18:12:04.000-04:00",
 
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "major",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-04-07T15:35:36.933-04:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-04-07T11:37:19.445-04:00",
 
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-04-07T18:07:04.000-04:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-04-07T11:27:14.000-04:00",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-04-06T21:10:08.968-04:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-04-06T19:37:38.348-04:00",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-04-03T13:53:32.449-04:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-04-03T12:38:45.037-04:00",
 
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-04-03T14:40:48.735-04:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-04-03T12:32:00.864-04:00",
 
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-04-01T10:01:44.660-04:00",
407
  "resolved_inferred": false,
408
  "started_at": "2026-04-01T09:13:35.470-04:00",
 
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-03-25T16:42:03.244-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2026-03-25T13:46:45.694-04:00",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-03-24T17:02:18.394-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2026-03-24T11:29:33.852-04:00",
 
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "major",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-03-05T19:03:10.249-05:00",
446
  "resolved_inferred": false,
447
  "started_at": "2026-03-05T18:51:44.922-05:00",
 
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-02-08T17:04:05.545-05:00",
459
  "resolved_inferred": false,
460
  "started_at": "2026-02-08T12:16:11.479-05:00",
 
467
  "body": "This incident has been resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-02-05T15:30:20.766-05:00",
472
  "resolved_inferred": false,
473
  "started_at": "2026-02-05T11:50:57.264-05:00",
 
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "minor",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-02-03T10:34:52.065-05:00",
485
  "resolved_inferred": false,
486
  "started_at": "2026-02-02T16:33:52.000-05:00",
 
493
  "body": "The issue impacting Salesforce Messaging integration performance has been resolved. Chats should now connect to agents as expected. We will continue to monitor to ensure ongoing stability.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2026-01-31T14:24:04.232-05:00",
498
  "resolved_inferred": false,
499
  "started_at": "2026-01-31T13:45:56.542-05:00",
 
506
  "body": "Analytics availability has been restored following an upstream provider outage. Clients may notice minor discrepancies in analytics data from approximately 4:00\u20136:00 AM ET, which will be automatically backfilled later today. We will continue to monitor to ensure everything remains stable.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "major",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2026-01-31T07:10:05.942-05:00",
511
  "resolved_inferred": false,
512
  "started_at": "2026-01-31T05:00:44.587-05:00",
 
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "critical",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2026-01-22T14:54:46.016-05:00",
524
  "resolved_inferred": false,
525
  "started_at": "2026-01-22T14:03:47.869-05:00",
 
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "minor",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2026-01-19T21:11:59.571-05:00",
537
  "resolved_inferred": false,
538
  "started_at": "2026-01-19T20:01:34.444-05:00",
 
545
  "body": "This incident has been resolved",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2026-01-07T11:30:30.794-05:00",
550
  "resolved_inferred": false,
551
  "started_at": "2026-01-07T11:20:42.543-05:00",
 
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "minor",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2026-01-05T20:25:26.062-05:00",
563
  "resolved_inferred": false,
564
  "started_at": "2026-01-05T16:01:32.520-05:00",
 
571
  "body": "The issue with the Ada Dashboard has been resolved and Dashboard users should see things functioning normally again.\nOur team will continue to monitor the fix. We\u2019re sorry for the impact of this issue and appreciate your understanding.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "minor",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-12-15T19:50:29.409-05:00",
576
  "resolved_inferred": false,
577
  "started_at": "2025-12-15T17:48:22.285-05:00",
 
584
  "body": "The issue with a delay in the knowledge articles updating has been resolved and regular update cadence has been re-instated. Our team will continue to monitor the fix. We\u2019re sorry for the impact of this issue and appreciate your understanding.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2025-12-10T19:22:30.431-05:00",
589
  "resolved_inferred": false,
590
  "started_at": "2025-12-10T16:15:08.802-05:00",
 
597
  "body": "The issue with Ada Voice has been resolved and chatters should see things functioning normally again.\nOur team will continue to monitor the fix. We\u2019re sorry for the impact of this issue and appreciate your understanding.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "major",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2025-12-10T16:06:34.404-05:00",
602
  "resolved_inferred": false,
603
  "started_at": "2025-12-10T15:22:18.909-05:00",
 
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2025-12-10T01:05:01.286-05:00",
615
  "resolved_inferred": false,
616
  "started_at": "2025-12-10T00:19:52.197-05:00",
 
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2025-12-08T20:33:19.575-05:00",
628
  "resolved_inferred": false,
629
  "started_at": "2025-12-08T19:20:21.899-05:00",
 
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "major",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2025-12-01T23:17:03.587-05:00",
641
  "resolved_inferred": false,
642
  "started_at": "2025-12-01T11:59:52.508-05:00",
 
649
  "body": "The incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2025-11-21T05:27:05.560-05:00",
654
  "resolved_inferred": false,
655
  "started_at": "2025-11-21T04:26:10.489-05:00",
api/v/adalo.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "adalo",
4
  "platform": "instatus",
5
  "status_url": "https://status.adalo.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "adalo",
4
  "platform": "instatus",
5
  "status_url": "https://status.adalo.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/adaptavist-cloud-apps.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "adaptavist-cloud-apps",
4
  "platform": "statuspage",
5
  "status_url": "https://status.connect.adaptavist.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "A small number of scripts failed to run between 9:01am UTC and 9:59am UTC on the 27th Aug 2026. \n\nThe issue is now resolved and scripts should be running normally.\n\nThis affected ScriptRunner for Jira and Confluence Cloud.\n\nApologies for any inconvenience caused.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-27T08:00:00.000Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-27T08:00:00.000Z",
@@ -25,7 +25,7 @@
25
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-07-30T19:15:24.871Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-30T12:49:00.000Z",
@@ -38,7 +38,7 @@
38
  "body": "Between 10:15 and 10:30 UTC, customers using ScriptRunner for Jira Cloud or Enhanced Search apps may have experienced increased rate limiting when accessing Jira REST APIs from their scripts, other automations or JQL searches. This was caused by a gradual release of Atlassian's new authentication mechanism for requests made as individual users. We rolled back the changes and apologise for any disruption.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-07-28T09:00:00.000Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-28T09:00:00.000Z",
@@ -51,7 +51,7 @@
51
  "body": "The issue is caused by the deprecation of the legacy workflows page \nhttps://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Final-notice-old-workflow-editor-deprecation-in-July-2026/ba-p/3247499\n\nFor users to edit their conditions and validators they will need to follow the instructions above to use the new workflow editor experience or edit their conditions and validators via the ScriptRunner Workflows Admin Page\n\nThanks!",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-16T08:52:37.219Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-16T08:37:13.656Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-15T23:15:47.411Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-15T10:55:48.366Z",
@@ -77,7 +77,7 @@
77
  "body": "ScriptRunner Cloud migrations are operating normally. The underlying issue has been addressed, and we are monitoring the system to ensure continued stability. Thank you for your patience.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-07-03T16:07:41.218Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-03T09:02:14.177Z",
@@ -90,7 +90,7 @@
90
  "body": "Our monitoring has confirmed the fix has worked.\nWe\u2019ll continue reviewing the incident to help prevent recurrence.\nOnce more, we apologise for any inconvenience caused and thank you for your patience.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-06-16T14:55:52.794Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-16T12:31:11.945Z",
@@ -103,7 +103,7 @@
103
  "body": "Our monitoring has now confirmed that the issue with the Forms for Confluence service, causing errors in some forms has been resolved and that all systems and services are operating normally.\n\nWe\u2019ll continue reviewing the incident to help prevent recurrence.\n\nOnce more, we apologise for any inconvenience caused and thank you for your patience.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-06-16T07:38:38.473Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-15T14:55:41.721Z",
@@ -116,7 +116,7 @@
116
  "body": "The issue has been fixed and the fix has been deployed. We are now monitoring the situation.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-06-04T19:27:44.737Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-04T18:52:51.082Z",
@@ -129,7 +129,7 @@
129
  "body": "At 13:21 28th May 2026 to 07:34 29th May 2026 UTC, there was an issue affecting script executions.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-06-01T13:43:54.106Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-01T10:01:56.419Z",
@@ -142,7 +142,7 @@
142
  "body": "Script Manager was unaccessible for a few hours between approximately 13:00 UTC and 22:00 UTC on 2026-05-05. Its visibility and accessibility have been restored. Script executions were unaffected.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-05-06T07:46:27.281Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-06T07:46:27.211Z",
@@ -155,7 +155,7 @@
155
  "body": "Atlassian published an update to their status page that their monitoring confirmed the issue with delays in delivering events is now resolved",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-04-30T15:00:29.239Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-04-30T09:42:14.424Z",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-04-21T11:35:08.496Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-20T09:51:13.191Z",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-04-20T11:32:13.201Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-17T07:27:13.703Z",
@@ -194,7 +194,7 @@
194
  "body": "We are confident that the issues we were seeing with processing event webhooks are resolved now. Please get in touch with our team if you experience any more issues.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-04-16T08:56:22.537Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-16T08:17:42.006Z",
@@ -207,7 +207,7 @@
207
  "body": "At 9:59 to 10:02 UTC (10:59 to 11:02 BST), there was an outage for ScriptRunner and EnhancedSearch apps in the US region only.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-04-13T10:31:25.550Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-13T10:31:25.489Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-03-25T11:45:21.927Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-25T11:40:23.280Z",
@@ -233,7 +233,7 @@
233
  "body": "Our monitoring has now confirmed that the issue affecting macro functionality has been resolved and that services are running normally again.\nWe apologise for any inconvenience caused.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-03-13T00:47:56.824Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-12T15:06:11.995Z",
@@ -246,7 +246,7 @@
246
  "body": "At 08:25 UTC the execution demand dropped to normal levels and the system resumed normal operation.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-03-12T10:31:15.858Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-12T10:30:47.339Z",
@@ -259,7 +259,7 @@
259
  "body": "At 17:35 the execution demand dropped to normal levels and the system resumed normal operation.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-02-25T17:35:50.000Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-02-25T17:33:07.000Z",
@@ -272,7 +272,7 @@
272
  "body": "The issue has been resolved, after verifying that ES filter syncing is now working as expected. \n\nApologies for the inconvenience, and thank you for your patience.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-02-20T18:42:13.153Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-02-20T14:16:22.682Z",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-01-21T13:43:59.814Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-21T09:30:03.102Z",
@@ -298,7 +298,7 @@
298
  "body": "We have rolled back the changes, the incident is resolved now.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-01-14T16:59:17.149Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-01-14T16:21:07.462Z",
@@ -311,7 +311,7 @@
311
  "body": "We are confident that the issue we witnessed this morning is resolved and did not impact the vast majority of our users. We will close this incident, but will continue to monitor the status of the relevant systems as necessary.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-01-09T10:52:24.247Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-01-09T09:23:21.061Z",
@@ -324,7 +324,7 @@
324
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 19:57 UTC to 22:00 UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-01-08T22:00:00.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-01-08T22:00:00.000Z",
@@ -337,7 +337,7 @@
337
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2025-12-31T13:14:22.914Z",
342
  "resolved_inferred": false,
343
  "started_at": "2025-12-31T07:56:17.699Z",
@@ -350,7 +350,7 @@
350
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team. Apologies for the inconvenience",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2025-12-31T15:10:55.768Z",
355
  "resolved_inferred": false,
356
  "started_at": "2025-12-29T12:30:17.000Z",
@@ -363,7 +363,7 @@
363
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 11:00AM UTC to 5:00PM UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2025-12-29T17:00:00.000Z",
368
  "resolved_inferred": false,
369
  "started_at": "2025-12-29T11:00:00.000Z",
@@ -376,7 +376,7 @@
376
  "body": "We have identified the issue and released a fix. Apologies for the inconvenience",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-12-19T15:53:54.643Z",
381
  "resolved_inferred": false,
382
  "started_at": "2025-12-18T19:00:47.000Z",
@@ -389,7 +389,7 @@
389
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 12:45 UTC to 14:52 UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-12-17T15:00:00.000Z",
394
  "resolved_inferred": false,
395
  "started_at": "2025-12-17T15:00:00.000Z",
@@ -402,7 +402,7 @@
402
  "body": "We have confirmed that automated migrations are working properly. We have identified the root cause and putting things in place to prevent a future outage.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-12-16T14:28:23.930Z",
407
  "resolved_inferred": false,
408
  "started_at": "2025-12-12T16:55:39.000Z",
@@ -415,7 +415,7 @@
415
  "body": "The issues we were seeing have now been resolved and filters are being synced automatically again.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-12-10T20:27:39.726Z",
420
  "resolved_inferred": false,
421
  "started_at": "2025-12-10T19:50:58.000Z",
@@ -428,7 +428,7 @@
428
  "body": "Scripts appear to have continued to perform at their standard level throughout a period of monitoring, therefore we're marking this incident as resolved.\n\nApologies for any inconvenience caused.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-12-11T09:52:48.515Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-12-10T16:48:40.973Z",
@@ -441,7 +441,7 @@
441
  "body": "We deployed a fix on 10 Dec at 19:32 UTC to resolve the issue and can confirm that the incident is now fully resolved.\n\nWe apologise for any inconvenience caused.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-12-11T07:44:52.283Z",
446
  "resolved_inferred": false,
447
  "started_at": "2025-12-10T11:29:22.357Z",
@@ -454,7 +454,7 @@
454
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 10:00PM UTC 3rd December 2025 to 3:00AM UTC on 4th December 2025. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-12-04T03:00:00.000Z",
459
  "resolved_inferred": false,
460
  "started_at": "2025-12-03T22:00:00.000Z",
@@ -467,7 +467,7 @@
467
  "body": "All script using saved scripts from Script Manager are now working as expected.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-12-04T17:50:11.000Z",
472
  "resolved_inferred": false,
473
  "started_at": "2025-12-03T16:08:35.113Z",
@@ -480,7 +480,7 @@
480
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 2:30AM UTC to 4:25AM UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "minor",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-11-26T02:30:00.000Z",
485
  "resolved_inferred": false,
486
  "started_at": "2025-11-26T02:30:00.000Z",
@@ -493,7 +493,7 @@
493
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-11-26T03:32:39.728Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-11-25T22:03:58.361Z",
@@ -506,7 +506,7 @@
506
  "body": "Our monitoring has now confirmed that the incident has been resolved and that all services are running as normal again.\n\nWe apologise for any inconvenience caused.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "none",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-11-21T11:15:33.677Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-11-21T08:27:22.289Z",
@@ -519,7 +519,7 @@
519
  "body": "We are confident that the issues experienced with using ScriptRunner Cloud apps yesterday are now resolved, so we are closing this incident. If you experience any further issues then please get in touch with our team.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2025-11-20T11:15:45.040Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-11-19T15:59:49.832Z",
@@ -532,7 +532,7 @@
532
  "body": "Our monitoring has now confirmed that the incident has been resolved and that all services are running as normal again.\n\nWe apologise for any inconvenience caused.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2025-11-13T08:58:31.573Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-11-13T07:29:06.793Z",
@@ -545,7 +545,7 @@
545
  "body": "We have reverted the change causing the shorter timeouts. This has been confirmed to fix the issue.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "none",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2025-11-10T09:03:05.185Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-11-10T08:54:27.397Z",
@@ -558,7 +558,7 @@
558
  "body": "Atlassian has deployed a fix to mitigate the webhooks problem, and we've verified that the Script Listener service is now operating normally. If your Script Listener did not work between 01:00 and 20:47 UTC on October 22, 2025, it was likely affected by this incident.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2025-10-22T22:21:19.219Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-10-22T15:33:00.732Z",
@@ -571,7 +571,7 @@
571
  "body": "Between 20-21 October, Atlassian Cloud experienced a major service disruption due to an outage in AWS\u2019s US-EAST-1 region that affected DNS resolution and dependent global services (e.g., DynamoDB, IAM).\n\u2028This caused partial or complete unavailability across multiple Atlassian systems, including:\n* Jira Cloud, Confluence Cloud, and Bitbucket Cloud APIs\n* Marketplace (app listings, installations, licensing, and vendor management)\n* Forge developer platform (app deployment, logging, and monitoring)\n* Atlassian Support portal and related service desks\n* Authentication and user management flows\n\nScriptRunner for Jira and Confluence Cloud, Enhanced Search and Behaviours functionality were indirectly affected through Atlassian platform dependencies (e.g., API latency and Marketplace licensing validation), though no internal ScriptRunner infrastructure outage occurred.\n\u2028AWS mitigated the underlying DNS issue in US-EAST-1, after which Atlassian restored full functionality across affected products. Atlassian has confirmed full recovery of core services, with residual monitoring on migrations and JSM virtual service agents still ongoing.\n\nWe apologise for any inconvenience caused.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2025-10-21T07:24:18.568Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-10-21T07:24:18.516Z",
@@ -584,7 +584,7 @@
584
  "body": "Between 2025-09-29 22:24 UTC and 2025-09-30 00:39 UTC in our US hosting region only the following apps were unable to store and process webhooks, postfunctions and JCMA migration events sent to us from Atlassian due to an AWS service outage: ScriptRunner for Jira Cloud, ScriptRunner for Confluence Cloud and Enhanced Search.\nThis problem impacted Script Listeners, Postfunctions, Scripted Fields that depend on issue updates and Enhanced Search queries using keywords.\nApologies for any inconvenience.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "major",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2025-09-29T21:30:00.000Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-09-29T21:30:00.000Z",
@@ -597,7 +597,7 @@
597
  "body": "We confirmed our earlier changes solved the problem reliably. The incident is closed and all migrations are operational. Customers who experienced the issue over the last weekend should re-attempt their migrations.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "none",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2025-09-29T13:15:26.000Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-09-25T16:00:31.000Z",
@@ -610,7 +610,7 @@
610
  "body": "All in app help documentation for ScriptRunner for Jira Cloud is now available again. Therefore this incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "none",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2025-09-22T14:09:59.480Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-09-22T09:02:07.117Z",
@@ -623,7 +623,7 @@
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2025-08-27T16:52:10.608Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-08-15T08:40:31.388Z",
@@ -636,7 +636,7 @@
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2025-08-15T08:34:25.533Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-08-13T09:52:12.657Z",
@@ -649,7 +649,7 @@
649
  "body": "This incident has been resolved. Script listeners and post functions should be operating normally.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2025-08-14T08:55:33.561Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-08-12T09:27:51.455Z",
 
3
  "slug": "adaptavist-cloud-apps",
4
  "platform": "statuspage",
5
  "status_url": "https://status.connect.adaptavist.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "A small number of scripts failed to run between 9:01am UTC and 9:59am UTC on the 27th Aug 2026. \n\nThe issue is now resolved and scripts should be running normally.\n\nThis affected ScriptRunner for Jira and Confluence Cloud.\n\nApologies for any inconvenience caused.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-27T08:00:00.000Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-27T08:00:00.000Z",
 
25
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-07-30T19:15:24.871Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-30T12:49:00.000Z",
 
38
  "body": "Between 10:15 and 10:30 UTC, customers using ScriptRunner for Jira Cloud or Enhanced Search apps may have experienced increased rate limiting when accessing Jira REST APIs from their scripts, other automations or JQL searches. This was caused by a gradual release of Atlassian's new authentication mechanism for requests made as individual users. We rolled back the changes and apologise for any disruption.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-07-28T09:00:00.000Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-28T09:00:00.000Z",
 
51
  "body": "The issue is caused by the deprecation of the legacy workflows page \nhttps://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Final-notice-old-workflow-editor-deprecation-in-July-2026/ba-p/3247499\n\nFor users to edit their conditions and validators they will need to follow the instructions above to use the new workflow editor experience or edit their conditions and validators via the ScriptRunner Workflows Admin Page\n\nThanks!",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-16T08:52:37.219Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-16T08:37:13.656Z",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-15T23:15:47.411Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-15T10:55:48.366Z",
 
77
  "body": "ScriptRunner Cloud migrations are operating normally. The underlying issue has been addressed, and we are monitoring the system to ensure continued stability. Thank you for your patience.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-07-03T16:07:41.218Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-03T09:02:14.177Z",
 
90
  "body": "Our monitoring has confirmed the fix has worked.\nWe\u2019ll continue reviewing the incident to help prevent recurrence.\nOnce more, we apologise for any inconvenience caused and thank you for your patience.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-06-16T14:55:52.794Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-16T12:31:11.945Z",
 
103
  "body": "Our monitoring has now confirmed that the issue with the Forms for Confluence service, causing errors in some forms has been resolved and that all systems and services are operating normally.\n\nWe\u2019ll continue reviewing the incident to help prevent recurrence.\n\nOnce more, we apologise for any inconvenience caused and thank you for your patience.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-06-16T07:38:38.473Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-15T14:55:41.721Z",
 
116
  "body": "The issue has been fixed and the fix has been deployed. We are now monitoring the situation.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-06-04T19:27:44.737Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-04T18:52:51.082Z",
 
129
  "body": "At 13:21 28th May 2026 to 07:34 29th May 2026 UTC, there was an issue affecting script executions.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-06-01T13:43:54.106Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-01T10:01:56.419Z",
 
142
  "body": "Script Manager was unaccessible for a few hours between approximately 13:00 UTC and 22:00 UTC on 2026-05-05. Its visibility and accessibility have been restored. Script executions were unaffected.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-05-06T07:46:27.281Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-06T07:46:27.211Z",
 
155
  "body": "Atlassian published an update to their status page that their monitoring confirmed the issue with delays in delivering events is now resolved",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-04-30T15:00:29.239Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-04-30T09:42:14.424Z",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-04-21T11:35:08.496Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-04-20T09:51:13.191Z",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-04-20T11:32:13.201Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-04-17T07:27:13.703Z",
 
194
  "body": "We are confident that the issues we were seeing with processing event webhooks are resolved now. Please get in touch with our team if you experience any more issues.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-04-16T08:56:22.537Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-16T08:17:42.006Z",
 
207
  "body": "At 9:59 to 10:02 UTC (10:59 to 11:02 BST), there was an outage for ScriptRunner and EnhancedSearch apps in the US region only.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-04-13T10:31:25.550Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-13T10:31:25.489Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-03-25T11:45:21.927Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-25T11:40:23.280Z",
 
233
  "body": "Our monitoring has now confirmed that the issue affecting macro functionality has been resolved and that services are running normally again.\nWe apologise for any inconvenience caused.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-03-13T00:47:56.824Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-12T15:06:11.995Z",
 
246
  "body": "At 08:25 UTC the execution demand dropped to normal levels and the system resumed normal operation.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-03-12T10:31:15.858Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-12T10:30:47.339Z",
 
259
  "body": "At 17:35 the execution demand dropped to normal levels and the system resumed normal operation.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-02-25T17:35:50.000Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-02-25T17:33:07.000Z",
 
272
  "body": "The issue has been resolved, after verifying that ES filter syncing is now working as expected. \n\nApologies for the inconvenience, and thank you for your patience.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-02-20T18:42:13.153Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-02-20T14:16:22.682Z",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-01-21T13:43:59.814Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-21T09:30:03.102Z",
 
298
  "body": "We have rolled back the changes, the incident is resolved now.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-01-14T16:59:17.149Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-01-14T16:21:07.462Z",
 
311
  "body": "We are confident that the issue we witnessed this morning is resolved and did not impact the vast majority of our users. We will close this incident, but will continue to monitor the status of the relevant systems as necessary.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-01-09T10:52:24.247Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-01-09T09:23:21.061Z",
 
324
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 19:57 UTC to 22:00 UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-01-08T22:00:00.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-01-08T22:00:00.000Z",
 
337
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2025-12-31T13:14:22.914Z",
342
  "resolved_inferred": false,
343
  "started_at": "2025-12-31T07:56:17.699Z",
 
350
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team. Apologies for the inconvenience",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2025-12-31T15:10:55.768Z",
355
  "resolved_inferred": false,
356
  "started_at": "2025-12-29T12:30:17.000Z",
 
363
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 11:00AM UTC to 5:00PM UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2025-12-29T17:00:00.000Z",
368
  "resolved_inferred": false,
369
  "started_at": "2025-12-29T11:00:00.000Z",
 
376
  "body": "We have identified the issue and released a fix. Apologies for the inconvenience",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-12-19T15:53:54.643Z",
381
  "resolved_inferred": false,
382
  "started_at": "2025-12-18T19:00:47.000Z",
 
389
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 12:45 UTC to 14:52 UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-12-17T15:00:00.000Z",
394
  "resolved_inferred": false,
395
  "started_at": "2025-12-17T15:00:00.000Z",
 
402
  "body": "We have confirmed that automated migrations are working properly. We have identified the root cause and putting things in place to prevent a future outage.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-12-16T14:28:23.930Z",
407
  "resolved_inferred": false,
408
  "started_at": "2025-12-12T16:55:39.000Z",
 
415
  "body": "The issues we were seeing have now been resolved and filters are being synced automatically again.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-12-10T20:27:39.726Z",
420
  "resolved_inferred": false,
421
  "started_at": "2025-12-10T19:50:58.000Z",
 
428
  "body": "Scripts appear to have continued to perform at their standard level throughout a period of monitoring, therefore we're marking this incident as resolved.\n\nApologies for any inconvenience caused.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-12-11T09:52:48.515Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-12-10T16:48:40.973Z",
 
441
  "body": "We deployed a fix on 10 Dec at 19:32 UTC to resolve the issue and can confirm that the incident is now fully resolved.\n\nWe apologise for any inconvenience caused.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-12-11T07:44:52.283Z",
446
  "resolved_inferred": false,
447
  "started_at": "2025-12-10T11:29:22.357Z",
 
454
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 10:00PM UTC 3rd December 2025 to 3:00AM UTC on 4th December 2025. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-12-04T03:00:00.000Z",
459
  "resolved_inferred": false,
460
  "started_at": "2025-12-03T22:00:00.000Z",
 
467
  "body": "All script using saved scripts from Script Manager are now working as expected.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-12-04T17:50:11.000Z",
472
  "resolved_inferred": false,
473
  "started_at": "2025-12-03T16:08:35.113Z",
 
480
  "body": "We experienced delays in automated filter syncing for ScriptRunner for Jira Enhanced Search customers in the US from 2:30AM UTC to 4:25AM UTC. Some filter results may have been out of date during this period for some customers. A work around was available at this time by manually syncing the filter from the Enhanced Search page. We apologise for the disruption and are implementing architecture changes to improve the stability of this service.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "minor",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-11-26T02:30:00.000Z",
485
  "resolved_inferred": false,
486
  "started_at": "2025-11-26T02:30:00.000Z",
 
493
  "body": "We\u2019re confident the ScriptRunner Cloud issues are now resolved, so we\u2019re closing this incident. If you experience any further issues, please contact our team.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-11-26T03:32:39.728Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-11-25T22:03:58.361Z",
 
506
  "body": "Our monitoring has now confirmed that the incident has been resolved and that all services are running as normal again.\n\nWe apologise for any inconvenience caused.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "none",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-11-21T11:15:33.677Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-11-21T08:27:22.289Z",
 
519
  "body": "We are confident that the issues experienced with using ScriptRunner Cloud apps yesterday are now resolved, so we are closing this incident. If you experience any further issues then please get in touch with our team.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-11-20T11:15:45.040Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-11-19T15:59:49.832Z",
 
532
  "body": "Our monitoring has now confirmed that the incident has been resolved and that all services are running as normal again.\n\nWe apologise for any inconvenience caused.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-11-13T08:58:31.573Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-11-13T07:29:06.793Z",
 
545
  "body": "We have reverted the change causing the shorter timeouts. This has been confirmed to fix the issue.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "none",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-11-10T09:03:05.185Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-11-10T08:54:27.397Z",
 
558
  "body": "Atlassian has deployed a fix to mitigate the webhooks problem, and we've verified that the Script Listener service is now operating normally. If your Script Listener did not work between 01:00 and 20:47 UTC on October 22, 2025, it was likely affected by this incident.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2025-10-22T22:21:19.219Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-10-22T15:33:00.732Z",
 
571
  "body": "Between 20-21 October, Atlassian Cloud experienced a major service disruption due to an outage in AWS\u2019s US-EAST-1 region that affected DNS resolution and dependent global services (e.g., DynamoDB, IAM).\n\u2028This caused partial or complete unavailability across multiple Atlassian systems, including:\n* Jira Cloud, Confluence Cloud, and Bitbucket Cloud APIs\n* Marketplace (app listings, installations, licensing, and vendor management)\n* Forge developer platform (app deployment, logging, and monitoring)\n* Atlassian Support portal and related service desks\n* Authentication and user management flows\n\nScriptRunner for Jira and Confluence Cloud, Enhanced Search and Behaviours functionality were indirectly affected through Atlassian platform dependencies (e.g., API latency and Marketplace licensing validation), though no internal ScriptRunner infrastructure outage occurred.\n\u2028AWS mitigated the underlying DNS issue in US-EAST-1, after which Atlassian restored full functionality across affected products. Atlassian has confirmed full recovery of core services, with residual monitoring on migrations and JSM virtual service agents still ongoing.\n\nWe apologise for any inconvenience caused.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-10-21T07:24:18.568Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-10-21T07:24:18.516Z",
 
584
  "body": "Between 2025-09-29 22:24 UTC and 2025-09-30 00:39 UTC in our US hosting region only the following apps were unable to store and process webhooks, postfunctions and JCMA migration events sent to us from Atlassian due to an AWS service outage: ScriptRunner for Jira Cloud, ScriptRunner for Confluence Cloud and Enhanced Search.\nThis problem impacted Script Listeners, Postfunctions, Scripted Fields that depend on issue updates and Enhanced Search queries using keywords.\nApologies for any inconvenience.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "major",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2025-09-29T21:30:00.000Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-09-29T21:30:00.000Z",
 
597
  "body": "We confirmed our earlier changes solved the problem reliably. The incident is closed and all migrations are operational. Customers who experienced the issue over the last weekend should re-attempt their migrations.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "none",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2025-09-29T13:15:26.000Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-09-25T16:00:31.000Z",
 
610
  "body": "All in app help documentation for ScriptRunner for Jira Cloud is now available again. Therefore this incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "none",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2025-09-22T14:09:59.480Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-09-22T09:02:07.117Z",
 
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2025-08-27T16:52:10.608Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-08-15T08:40:31.388Z",
 
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2025-08-15T08:34:25.533Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-08-13T09:52:12.657Z",
 
649
  "body": "This incident has been resolved. Script listeners and post functions should be operating normally.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2025-08-14T08:55:33.561Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-08-12T09:27:51.455Z",
api/v/addigy.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "addigy",
4
  "platform": "statuspage",
5
  "status_url": "https://status.addigy.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-20T15:53:31.533Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-20T14:04:11.677Z",
@@ -25,7 +25,7 @@
25
  "body": "This issue has been resolved. Logging in to Addigy is working as expected. If you continue to see errors, please open a support ticket and we will assist.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-03T16:12:51.277Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-03T16:08:03.498Z",
@@ -38,7 +38,7 @@
38
  "body": "This issue has been resolved. To create or renew your push certificate, first download a fresh AddigyCSR.plist from your Addigy instance, then upload it to Apple\u2019s APNs portal. An older AddigyCSR.plist file will not work. If you still see errors after using a newly downloaded file, please open a support ticket and we will assist.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-03T16:54:24.436Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-03T16:01:49.990Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-15T18:53:14.554Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-09T21:09:51.891Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-06-22T18:01:24.359Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-06-22T14:15:24.695Z",
@@ -77,7 +77,7 @@
77
  "body": "A fix has been applied and the incident is now resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "major",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-06-18T13:00:46.889Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-18T12:53:46.874Z",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-03-17T23:05:42.149Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-03-17T21:11:09.394Z",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-02-22T20:15:17.409Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-02-22T18:41:04.312Z",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved. A fix has been deployed and monitoring has been verified.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "critical",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-01-30T16:58:42.189Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-01-30T14:27:02.492Z",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-09-30T18:18:34.051Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-09-30T17:34:01.703Z",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "critical",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-09-09T19:39:31.578Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-09-09T18:50:27.266Z",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved and correlated to an upstream provider incident: https://www.cloudflarestatus.com/incidents/d9n3g1vnxdd2",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-08-21T19:46:35.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-08-21T18:14:09.616Z",
 
3
  "slug": "addigy",
4
  "platform": "statuspage",
5
  "status_url": "https://status.addigy.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-20T15:53:31.533Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-20T14:04:11.677Z",
 
25
  "body": "This issue has been resolved. Logging in to Addigy is working as expected. If you continue to see errors, please open a support ticket and we will assist.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-03T16:12:51.277Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-03T16:08:03.498Z",
 
38
  "body": "This issue has been resolved. To create or renew your push certificate, first download a fresh AddigyCSR.plist from your Addigy instance, then upload it to Apple\u2019s APNs portal. An older AddigyCSR.plist file will not work. If you still see errors after using a newly downloaded file, please open a support ticket and we will assist.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-03T16:54:24.436Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-03T16:01:49.990Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-15T18:53:14.554Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-09T21:09:51.891Z",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-06-22T18:01:24.359Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-06-22T14:15:24.695Z",
 
77
  "body": "A fix has been applied and the incident is now resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "major",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-06-18T13:00:46.889Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-18T12:53:46.874Z",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-03-17T23:05:42.149Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-03-17T21:11:09.394Z",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-02-22T20:15:17.409Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-02-22T18:41:04.312Z",
 
116
  "body": "This incident has been resolved. A fix has been deployed and monitoring has been verified.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "critical",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-01-30T16:58:42.189Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-01-30T14:27:02.492Z",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-09-30T18:18:34.051Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-09-30T17:34:01.703Z",
 
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "critical",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-09-09T19:39:31.578Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-09-09T18:50:27.266Z",
 
155
  "body": "This incident has been resolved and correlated to an upstream provider incident: https://www.cloudflarestatus.com/incidents/d9n3g1vnxdd2",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-08-21T19:46:35.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-08-21T18:14:09.616Z",
api/v/airbrake.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "airbrake",
4
  "platform": "statuspage",
5
  "status_url": "https://status.airbrake.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "The incident has been resolved and metrics are back online. There will be a dip in metric count graphs while the incident was experienced. Error event data was recorded normally and was unaffected. We apologize for the inconvenience. If you have any questions please reach us at support@airbrake.io.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-07-13T20:29:00.352-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-13T08:15:00.000-07:00",
@@ -25,7 +25,7 @@
25
  "body": "We've resolved an issue with our email notifications. The issue was caused by email asset delivery which we've resolved. We apologize for any inconvenience. Please email support at support@airbrake.io if you have any questions or concerns.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-06-01T08:53:12.777-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-06-01T07:22:17.515-07:00",
@@ -38,7 +38,7 @@
38
  "body": "A subset of customers experienced an issue where the error dashboard list was not loading properly. This may have resulted in error filtering being faulty or the errors list being blank. The issue was escalated to our techops team which resolved the issue.\n\nWe apologize for the inconvenience that this has caused. If you have any questions or concerns, please reach us at support@airbrake.io.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-05-06T04:00:03.000-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-05-06T04:00:03.000-07:00",
 
3
  "slug": "airbrake",
4
  "platform": "statuspage",
5
  "status_url": "https://status.airbrake.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "The incident has been resolved and metrics are back online. There will be a dip in metric count graphs while the incident was experienced. Error event data was recorded normally and was unaffected. We apologize for the inconvenience. If you have any questions please reach us at support@airbrake.io.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-07-13T20:29:00.352-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-13T08:15:00.000-07:00",
 
25
  "body": "We've resolved an issue with our email notifications. The issue was caused by email asset delivery which we've resolved. We apologize for any inconvenience. Please email support at support@airbrake.io if you have any questions or concerns.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-06-01T08:53:12.777-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-06-01T07:22:17.515-07:00",
 
38
  "body": "A subset of customers experienced an issue where the error dashboard list was not loading properly. This may have resulted in error filtering being faulty or the errors list being blank. The issue was escalated to our techops team which resolved the issue.\n\nWe apologize for the inconvenience that this has caused. If you have any questions or concerns, please reach us at support@airbrake.io.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-05-06T04:00:03.000-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-05-06T04:00:03.000-07:00",
api/v/aiven.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "aiven",
4
  "platform": "statuspage",
5
  "status_url": "https://status.aiven.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "New VM creation has returned to normal across all cloud providers, including DigitalOcean.\n\n* VM provisioning is operating normally across all regions.\n* The upstream DigitalOcean incident has been resolved.\n* We are continuing to monitor the infrastructure to ensure stable provisioning.\n\nThe incident is now resolved. Thank you for your patience.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-09T06:28:49Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-08T21:28:11Z",
@@ -24,7 +24,7 @@
24
  "body": "Our team has successfully applied the appropriate mitigation to all impacted nodes, and the fix has been deployed to prevent future occurrences.",
25
  "first_seen": "2026-09-04T07:06:16Z",
26
  "impact": "major",
27
- "last_seen": "2026-09-04T09:06:33Z",
28
  "resolved_at": "2026-07-29T17:07:13Z",
29
  "resolved_inferred": false,
30
  "started_at": "2026-07-29T14:29:15Z",
@@ -36,7 +36,7 @@
36
  "body": "We have resolved the underlying cause of this issue.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "major",
39
- "last_seen": "2026-09-04T09:06:33Z",
40
  "resolved_at": "2026-07-03T05:28:30Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-07-02T23:24:59Z",
@@ -48,7 +48,7 @@
48
  "body": "The issue has been resolved. Terraform & Kubernetes operator users should no longer experience `400` errors when using `aiven_pg_database`. We apologize for any inconvenience caused.",
49
  "first_seen": "2026-09-04T07:06:16Z",
50
  "impact": "none",
51
- "last_seen": "2026-09-04T09:06:33Z",
52
  "resolved_at": "2026-06-25T13:14:31Z",
53
  "resolved_inferred": false,
54
  "started_at": "2026-06-25T10:16:16Z",
@@ -60,7 +60,7 @@
60
  "body": "The issues affecting KRaft migrations during Kafka 3\\.8 to 3\\.9 upgrades have been resolved.\n\nFixes have been deployed, migrations have been re-enabled, and services have remained stable during monitoring. \n\nIf you are experiencing any issues, please contact support.",
61
  "first_seen": "2026-09-04T07:06:16Z",
62
  "impact": "none",
63
- "last_seen": "2026-09-04T09:06:33Z",
64
  "resolved_at": "2026-06-25T11:38:25Z",
65
  "resolved_inferred": false,
66
  "started_at": "2026-06-23T14:18:37Z",
@@ -72,7 +72,7 @@
72
  "body": "The issue has been resolved. All affected functionality is operating normally.",
73
  "first_seen": "2026-09-04T07:06:16Z",
74
  "impact": "none",
75
- "last_seen": "2026-09-04T09:06:33Z",
76
  "resolved_at": "2026-06-16T11:05:49Z",
77
  "resolved_inferred": false,
78
  "started_at": "2026-06-11T15:25:40Z",
@@ -84,7 +84,7 @@
84
  "body": "The monitoring period has passed without further evidence of the issue occurring. Incident has been declared resolved.",
85
  "first_seen": "2026-09-04T07:06:16Z",
86
  "impact": "major",
87
- "last_seen": "2026-09-04T09:06:33Z",
88
  "resolved_at": "2026-06-09T16:57:26Z",
89
  "resolved_inferred": false,
90
  "started_at": "2026-06-09T15:10:00Z",
@@ -96,7 +96,7 @@
96
  "body": "We have resolved the underlying cause of the issue affection service operations in our Azure regions.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
97
  "first_seen": "2026-09-04T07:06:16Z",
98
  "impact": "major",
99
- "last_seen": "2026-09-04T09:06:33Z",
100
  "resolved_at": "2026-05-25T03:54:07Z",
101
  "resolved_inferred": false,
102
  "started_at": "2026-05-25T02:29:06Z",
@@ -108,7 +108,7 @@
108
  "body": "This issue is now resolved.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue.",
109
  "first_seen": "2026-09-04T07:06:16Z",
110
  "impact": "minor",
111
- "last_seen": "2026-09-04T09:06:33Z",
112
  "resolved_at": "2026-05-20T02:38:53Z",
113
  "resolved_inferred": false,
114
  "started_at": "2026-05-20T01:15:06Z",
@@ -120,7 +120,7 @@
120
  "body": "We have resolved the underlying cause of the kafka service disruption.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
121
  "first_seen": "2026-09-04T07:06:16Z",
122
  "impact": "none",
123
- "last_seen": "2026-09-04T09:06:33Z",
124
  "resolved_at": "2026-05-15T23:13:23Z",
125
  "resolved_inferred": false,
126
  "started_at": "2026-05-14T06:55:15Z",
@@ -132,7 +132,7 @@
132
  "body": "The underlying issues with Amazon Web Services (AWS) in the **ME-CENTRAL-1** and **ME-SOUTH-1** regions are ongoing, and AWS continues to work on recovery. \n\nWe have disabled the creation of new services and nodes in the affected regions to prevent further impact. We recommend our customers to migrate their services to a stable region as part of their disaster recovery plan. \n\nAs there are no further actions we can take at this time, we are moving this incident to a resolved state on our status page. The recovery of these regions is fully dependent on AWS. We will make **ME-CENTRAL-1** and **ME-SOUTH-1** regions available again for Aiven services once AWS confirms they are fully restored and stable. \n\nWe recommend customers continue to monitor the official AWS Health Status Page for updates.\nhttps://health.aws.amazon.com/health/status",
133
  "first_seen": "2026-09-04T07:06:16Z",
134
  "impact": "major",
135
- "last_seen": "2026-09-04T09:06:33Z",
136
  "resolved_at": "2026-04-02T11:23:09Z",
137
  "resolved_inferred": false,
138
  "started_at": "2026-03-01T23:12:45Z",
@@ -144,7 +144,7 @@
144
  "body": "The issue affecting node creation on the UpCloud cloud platform has been fully resolved. New services and replacement nodes are now provisioning successfully across all UpCloud regions. Our engineering team has completed all remediation steps and confirmed the stability of the platform.",
145
  "first_seen": "2026-09-04T07:06:16Z",
146
  "impact": "none",
147
- "last_seen": "2026-09-04T09:06:33Z",
148
  "resolved_at": "2025-12-17T13:58:34Z",
149
  "resolved_inferred": false,
150
  "started_at": "2025-12-12T11:33:23Z",
@@ -156,7 +156,7 @@
156
  "body": "We are confirming that the platfom has remained **stable** following the resolution of the DNS update performance issue, and the system is handling expected load variations well. We are now closing the incident after extended monitoring.",
157
  "first_seen": "2026-09-04T07:06:16Z",
158
  "impact": "major",
159
- "last_seen": "2026-09-04T09:06:33Z",
160
  "resolved_at": "2025-12-08T20:41:10Z",
161
  "resolved_inferred": false,
162
  "started_at": "2025-12-08T03:48:30Z",
@@ -168,7 +168,7 @@
168
  "body": "We have confirmed that all the Aiven services running on the Microsoft Azure region are operational. \n\nIf you face any further issues please contact Aiven support. ",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-12-06T03:35:09Z",
173
  "resolved_inferred": false,
174
  "started_at": "2025-12-05T07:19:24Z",
@@ -180,7 +180,7 @@
180
  "body": "The issue affecting metrics retrieval has been fully resolved. All metrics APIs and the Metrics page in the console should now be functioning normally. If you continue to experience any problems, please reach out to our support team and we\u2019ll be happy to assist.",
181
  "first_seen": "2026-09-04T07:06:16Z",
182
  "impact": "none",
183
- "last_seen": "2026-09-04T09:06:33Z",
184
  "resolved_at": "2025-12-04T19:17:24Z",
185
  "resolved_inferred": false,
186
  "started_at": "2025-12-04T17:12:15Z",
@@ -192,7 +192,7 @@
192
  "body": "We have confirmed that the incident has been resolved, and all the PG replicas are operating normally.\n\nWe apologise for the inconvenience caused by this issue.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "none",
195
- "last_seen": "2026-09-04T09:06:33Z",
196
  "resolved_at": "2025-11-24T05:38:38Z",
197
  "resolved_inferred": false,
198
  "started_at": "2025-11-24T03:39:21Z",
@@ -204,7 +204,7 @@
204
  "body": "We have identified a mitigation to resolve the issues causing PostgreSQL services not being able to be powered on after being powered off. \n\nWe are continuing to monitor closely to ensure no further problems.\n\nWe apologise for the inconvenience caused by this issue. ",
205
  "first_seen": "2026-09-04T07:06:16Z",
206
  "impact": "major",
207
- "last_seen": "2026-09-04T09:06:33Z",
208
  "resolved_at": "2025-11-20T00:07:14Z",
209
  "resolved_inferred": false,
210
  "started_at": "2025-11-19T22:05:11Z",
@@ -216,7 +216,7 @@
216
  "body": "Cloudflare has resolved the issues on their side and our platform has returned to normal operation. No impact was observed on any running services.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.",
217
  "first_seen": "2026-09-04T07:06:16Z",
218
  "impact": "none",
219
- "last_seen": "2026-09-04T09:06:33Z",
220
  "resolved_at": "2025-11-18T19:06:12Z",
221
  "resolved_inferred": false,
222
  "started_at": "2025-11-18T12:08:38Z",
@@ -228,7 +228,7 @@
228
  "body": "The root cause of this incident has been fixed. All impacted PostgreSQL 18 nodes are operating normally. \n\nWe apologize for any inconvenience this may have caused. If you continue to experience any issues with your PostgreSQL services, please contact our support team for assistance.",
229
  "first_seen": "2026-09-04T07:06:16Z",
230
  "impact": "major",
231
- "last_seen": "2026-09-04T09:06:33Z",
232
  "resolved_at": "2025-11-06T07:35:58Z",
233
  "resolved_inferred": false,
234
  "started_at": "2025-11-06T04:24:09Z",
@@ -240,7 +240,7 @@
240
  "body": "**Resolved** -\u00a0 The issue with starting up new nodes has been resolved, and all services are now operating normally. We apologize for any inconvenience this may have caused.",
241
  "first_seen": "2026-09-04T07:06:16Z",
242
  "impact": "major",
243
- "last_seen": "2026-09-04T09:06:33Z",
244
  "resolved_at": "2025-10-31T13:36:24Z",
245
  "resolved_inferred": false,
246
  "started_at": "2025-10-31T11:32:28Z",
@@ -252,7 +252,7 @@
252
  "body": "RESOLVED: We have identified and applied a fix for the issue where services in BYOC environments were struggling to spin up new nodes. All affected services should now be able to create and rebalance nodes normally.",
253
  "first_seen": "2026-09-04T07:06:16Z",
254
  "impact": "major",
255
- "last_seen": "2026-09-04T09:06:33Z",
256
  "resolved_at": "2025-10-29T21:18:40Z",
257
  "resolved_inferred": false,
258
  "started_at": "2025-10-29T17:04:42Z",
@@ -264,7 +264,7 @@
264
  "body": "AWS has recovered and declared their incident as resolved.\n\nSee the AWS status page for a timeline on the issue: [https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status \"https://health.aws.amazon.com/health/status\")\n\nShould any further issues be encountered, please reach out to support via the Aiven console.",
265
  "first_seen": "2026-09-04T07:06:16Z",
266
  "impact": "major",
267
- "last_seen": "2026-09-04T09:06:33Z",
268
  "resolved_at": "2025-10-20T23:57:36Z",
269
  "resolved_inferred": false,
270
  "started_at": "2025-10-20T09:30:50Z",
@@ -276,7 +276,7 @@
276
  "body": "Digital Ocean Engineering team has confirmed that the IPv6 connectivity issue has been fully resolved across all regions. Users should no longer face IPv6 connectivity issues. \n\nIf you continue to experience problems, please open a ticket with support team. Thank you for your patience and we apologize for any inconvenience.",
277
  "first_seen": "2026-09-04T07:06:16Z",
278
  "impact": "major",
279
- "last_seen": "2026-09-04T09:06:33Z",
280
  "resolved_at": "2025-10-17T05:05:25Z",
281
  "resolved_inferred": false,
282
  "started_at": "2025-10-17T00:29:08Z",
@@ -288,7 +288,7 @@
288
  "body": "We have resolved the underlying cause of issue affecting our customers using legacy MD5 password cannot connect through pgbouncer.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
289
  "first_seen": "2026-09-04T07:06:16Z",
290
  "impact": "major",
291
- "last_seen": "2026-09-04T09:06:33Z",
292
  "resolved_at": "2025-10-01T05:48:41Z",
293
  "resolved_inferred": false,
294
  "started_at": "2025-09-30T21:47:50Z",
@@ -300,7 +300,7 @@
300
  "body": "Service user logging pipelines are now operating as per normal. If you continue to experience delays, please reach out to Aiven Support. ",
301
  "first_seen": "2026-09-04T07:06:16Z",
302
  "impact": "minor",
303
- "last_seen": "2026-09-04T09:06:33Z",
304
  "resolved_at": "2025-09-26T06:04:54Z",
305
  "resolved_inferred": false,
306
  "started_at": "2025-09-26T01:49:29Z",
 
3
  "slug": "aiven",
4
  "platform": "statuspage",
5
  "status_url": "https://status.aiven.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "New VM creation has returned to normal across all cloud providers, including DigitalOcean.\n\n* VM provisioning is operating normally across all regions.\n* The upstream DigitalOcean incident has been resolved.\n* We are continuing to monitor the infrastructure to ensure stable provisioning.\n\nThe incident is now resolved. Thank you for your patience.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-09T06:28:49Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-08T21:28:11Z",
 
24
  "body": "Our team has successfully applied the appropriate mitigation to all impacted nodes, and the fix has been deployed to prevent future occurrences.",
25
  "first_seen": "2026-09-04T07:06:16Z",
26
  "impact": "major",
27
+ "last_seen": "2026-09-04T10:17:20Z",
28
  "resolved_at": "2026-07-29T17:07:13Z",
29
  "resolved_inferred": false,
30
  "started_at": "2026-07-29T14:29:15Z",
 
36
  "body": "We have resolved the underlying cause of this issue.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "major",
39
+ "last_seen": "2026-09-04T10:17:20Z",
40
  "resolved_at": "2026-07-03T05:28:30Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-07-02T23:24:59Z",
 
48
  "body": "The issue has been resolved. Terraform & Kubernetes operator users should no longer experience `400` errors when using `aiven_pg_database`. We apologize for any inconvenience caused.",
49
  "first_seen": "2026-09-04T07:06:16Z",
50
  "impact": "none",
51
+ "last_seen": "2026-09-04T10:17:20Z",
52
  "resolved_at": "2026-06-25T13:14:31Z",
53
  "resolved_inferred": false,
54
  "started_at": "2026-06-25T10:16:16Z",
 
60
  "body": "The issues affecting KRaft migrations during Kafka 3\\.8 to 3\\.9 upgrades have been resolved.\n\nFixes have been deployed, migrations have been re-enabled, and services have remained stable during monitoring. \n\nIf you are experiencing any issues, please contact support.",
61
  "first_seen": "2026-09-04T07:06:16Z",
62
  "impact": "none",
63
+ "last_seen": "2026-09-04T10:17:20Z",
64
  "resolved_at": "2026-06-25T11:38:25Z",
65
  "resolved_inferred": false,
66
  "started_at": "2026-06-23T14:18:37Z",
 
72
  "body": "The issue has been resolved. All affected functionality is operating normally.",
73
  "first_seen": "2026-09-04T07:06:16Z",
74
  "impact": "none",
75
+ "last_seen": "2026-09-04T10:17:20Z",
76
  "resolved_at": "2026-06-16T11:05:49Z",
77
  "resolved_inferred": false,
78
  "started_at": "2026-06-11T15:25:40Z",
 
84
  "body": "The monitoring period has passed without further evidence of the issue occurring. Incident has been declared resolved.",
85
  "first_seen": "2026-09-04T07:06:16Z",
86
  "impact": "major",
87
+ "last_seen": "2026-09-04T10:17:20Z",
88
  "resolved_at": "2026-06-09T16:57:26Z",
89
  "resolved_inferred": false,
90
  "started_at": "2026-06-09T15:10:00Z",
 
96
  "body": "We have resolved the underlying cause of the issue affection service operations in our Azure regions.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
97
  "first_seen": "2026-09-04T07:06:16Z",
98
  "impact": "major",
99
+ "last_seen": "2026-09-04T10:17:20Z",
100
  "resolved_at": "2026-05-25T03:54:07Z",
101
  "resolved_inferred": false,
102
  "started_at": "2026-05-25T02:29:06Z",
 
108
  "body": "This issue is now resolved.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue.",
109
  "first_seen": "2026-09-04T07:06:16Z",
110
  "impact": "minor",
111
+ "last_seen": "2026-09-04T10:17:20Z",
112
  "resolved_at": "2026-05-20T02:38:53Z",
113
  "resolved_inferred": false,
114
  "started_at": "2026-05-20T01:15:06Z",
 
120
  "body": "We have resolved the underlying cause of the kafka service disruption.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
121
  "first_seen": "2026-09-04T07:06:16Z",
122
  "impact": "none",
123
+ "last_seen": "2026-09-04T10:17:20Z",
124
  "resolved_at": "2026-05-15T23:13:23Z",
125
  "resolved_inferred": false,
126
  "started_at": "2026-05-14T06:55:15Z",
 
132
  "body": "The underlying issues with Amazon Web Services (AWS) in the **ME-CENTRAL-1** and **ME-SOUTH-1** regions are ongoing, and AWS continues to work on recovery. \n\nWe have disabled the creation of new services and nodes in the affected regions to prevent further impact. We recommend our customers to migrate their services to a stable region as part of their disaster recovery plan. \n\nAs there are no further actions we can take at this time, we are moving this incident to a resolved state on our status page. The recovery of these regions is fully dependent on AWS. We will make **ME-CENTRAL-1** and **ME-SOUTH-1** regions available again for Aiven services once AWS confirms they are fully restored and stable. \n\nWe recommend customers continue to monitor the official AWS Health Status Page for updates.\nhttps://health.aws.amazon.com/health/status",
133
  "first_seen": "2026-09-04T07:06:16Z",
134
  "impact": "major",
135
+ "last_seen": "2026-09-04T10:17:20Z",
136
  "resolved_at": "2026-04-02T11:23:09Z",
137
  "resolved_inferred": false,
138
  "started_at": "2026-03-01T23:12:45Z",
 
144
  "body": "The issue affecting node creation on the UpCloud cloud platform has been fully resolved. New services and replacement nodes are now provisioning successfully across all UpCloud regions. Our engineering team has completed all remediation steps and confirmed the stability of the platform.",
145
  "first_seen": "2026-09-04T07:06:16Z",
146
  "impact": "none",
147
+ "last_seen": "2026-09-04T10:17:20Z",
148
  "resolved_at": "2025-12-17T13:58:34Z",
149
  "resolved_inferred": false,
150
  "started_at": "2025-12-12T11:33:23Z",
 
156
  "body": "We are confirming that the platfom has remained **stable** following the resolution of the DNS update performance issue, and the system is handling expected load variations well. We are now closing the incident after extended monitoring.",
157
  "first_seen": "2026-09-04T07:06:16Z",
158
  "impact": "major",
159
+ "last_seen": "2026-09-04T10:17:20Z",
160
  "resolved_at": "2025-12-08T20:41:10Z",
161
  "resolved_inferred": false,
162
  "started_at": "2025-12-08T03:48:30Z",
 
168
  "body": "We have confirmed that all the Aiven services running on the Microsoft Azure region are operational. \n\nIf you face any further issues please contact Aiven support. ",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-12-06T03:35:09Z",
173
  "resolved_inferred": false,
174
  "started_at": "2025-12-05T07:19:24Z",
 
180
  "body": "The issue affecting metrics retrieval has been fully resolved. All metrics APIs and the Metrics page in the console should now be functioning normally. If you continue to experience any problems, please reach out to our support team and we\u2019ll be happy to assist.",
181
  "first_seen": "2026-09-04T07:06:16Z",
182
  "impact": "none",
183
+ "last_seen": "2026-09-04T10:17:20Z",
184
  "resolved_at": "2025-12-04T19:17:24Z",
185
  "resolved_inferred": false,
186
  "started_at": "2025-12-04T17:12:15Z",
 
192
  "body": "We have confirmed that the incident has been resolved, and all the PG replicas are operating normally.\n\nWe apologise for the inconvenience caused by this issue.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "none",
195
+ "last_seen": "2026-09-04T10:17:20Z",
196
  "resolved_at": "2025-11-24T05:38:38Z",
197
  "resolved_inferred": false,
198
  "started_at": "2025-11-24T03:39:21Z",
 
204
  "body": "We have identified a mitigation to resolve the issues causing PostgreSQL services not being able to be powered on after being powered off. \n\nWe are continuing to monitor closely to ensure no further problems.\n\nWe apologise for the inconvenience caused by this issue. ",
205
  "first_seen": "2026-09-04T07:06:16Z",
206
  "impact": "major",
207
+ "last_seen": "2026-09-04T10:17:20Z",
208
  "resolved_at": "2025-11-20T00:07:14Z",
209
  "resolved_inferred": false,
210
  "started_at": "2025-11-19T22:05:11Z",
 
216
  "body": "Cloudflare has resolved the issues on their side and our platform has returned to normal operation. No impact was observed on any running services.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.",
217
  "first_seen": "2026-09-04T07:06:16Z",
218
  "impact": "none",
219
+ "last_seen": "2026-09-04T10:17:20Z",
220
  "resolved_at": "2025-11-18T19:06:12Z",
221
  "resolved_inferred": false,
222
  "started_at": "2025-11-18T12:08:38Z",
 
228
  "body": "The root cause of this incident has been fixed. All impacted PostgreSQL 18 nodes are operating normally. \n\nWe apologize for any inconvenience this may have caused. If you continue to experience any issues with your PostgreSQL services, please contact our support team for assistance.",
229
  "first_seen": "2026-09-04T07:06:16Z",
230
  "impact": "major",
231
+ "last_seen": "2026-09-04T10:17:20Z",
232
  "resolved_at": "2025-11-06T07:35:58Z",
233
  "resolved_inferred": false,
234
  "started_at": "2025-11-06T04:24:09Z",
 
240
  "body": "**Resolved** -\u00a0 The issue with starting up new nodes has been resolved, and all services are now operating normally. We apologize for any inconvenience this may have caused.",
241
  "first_seen": "2026-09-04T07:06:16Z",
242
  "impact": "major",
243
+ "last_seen": "2026-09-04T10:17:20Z",
244
  "resolved_at": "2025-10-31T13:36:24Z",
245
  "resolved_inferred": false,
246
  "started_at": "2025-10-31T11:32:28Z",
 
252
  "body": "RESOLVED: We have identified and applied a fix for the issue where services in BYOC environments were struggling to spin up new nodes. All affected services should now be able to create and rebalance nodes normally.",
253
  "first_seen": "2026-09-04T07:06:16Z",
254
  "impact": "major",
255
+ "last_seen": "2026-09-04T10:17:20Z",
256
  "resolved_at": "2025-10-29T21:18:40Z",
257
  "resolved_inferred": false,
258
  "started_at": "2025-10-29T17:04:42Z",
 
264
  "body": "AWS has recovered and declared their incident as resolved.\n\nSee the AWS status page for a timeline on the issue: [https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status \"https://health.aws.amazon.com/health/status\")\n\nShould any further issues be encountered, please reach out to support via the Aiven console.",
265
  "first_seen": "2026-09-04T07:06:16Z",
266
  "impact": "major",
267
+ "last_seen": "2026-09-04T10:17:20Z",
268
  "resolved_at": "2025-10-20T23:57:36Z",
269
  "resolved_inferred": false,
270
  "started_at": "2025-10-20T09:30:50Z",
 
276
  "body": "Digital Ocean Engineering team has confirmed that the IPv6 connectivity issue has been fully resolved across all regions. Users should no longer face IPv6 connectivity issues. \n\nIf you continue to experience problems, please open a ticket with support team. Thank you for your patience and we apologize for any inconvenience.",
277
  "first_seen": "2026-09-04T07:06:16Z",
278
  "impact": "major",
279
+ "last_seen": "2026-09-04T10:17:20Z",
280
  "resolved_at": "2025-10-17T05:05:25Z",
281
  "resolved_inferred": false,
282
  "started_at": "2025-10-17T00:29:08Z",
 
288
  "body": "We have resolved the underlying cause of issue affecting our customers using legacy MD5 password cannot connect through pgbouncer.\n\nShould any further issues be encountered, please reach out to support via the Aiven console.\n\nWe apologise for the inconvenience caused by this issue, and commit to analysing and improving our platform to avoid future incidents similar to this one.",
289
  "first_seen": "2026-09-04T07:06:16Z",
290
  "impact": "major",
291
+ "last_seen": "2026-09-04T10:17:20Z",
292
  "resolved_at": "2025-10-01T05:48:41Z",
293
  "resolved_inferred": false,
294
  "started_at": "2025-09-30T21:47:50Z",
 
300
  "body": "Service user logging pipelines are now operating as per normal. If you continue to experience delays, please reach out to Aiven Support. ",
301
  "first_seen": "2026-09-04T07:06:16Z",
302
  "impact": "minor",
303
+ "last_seen": "2026-09-04T10:17:20Z",
304
  "resolved_at": "2025-09-26T06:04:54Z",
305
  "resolved_inferred": false,
306
  "started_at": "2025-09-26T01:49:29Z",
api/v/akamai-edge-dns.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "akamai-edge-dns",
4
  "platform": "statuspage",
5
  "status_url": "https://edgedns.status.akamai.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "degraded",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "We are continuing to investigate this issue. Customers and partners can find more details on the Akamai Community: https://community.akamai.com/customers/s/feed/0D5a700001S7tYbCAJ. We will provide the next update as we make progress.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "started_at": "2026-09-04T06:14:59.971Z",
17
  "state": "investigating",
18
  "title": "Application Load Balancer reporting availability issues",
@@ -23,7 +23,7 @@
23
  "body": "We can confirm that the issue was mitigated at 03:30 UTC on 28 August 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001QvOI6CAN or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
24
  "first_seen": "2026-09-04T07:06:16Z",
25
  "impact": "minor",
26
- "last_seen": "2026-09-04T09:06:33Z",
27
  "resolved_at": "2026-08-28T04:52:29.929Z",
28
  "resolved_inferred": false,
29
  "started_at": "2026-08-28T01:33:18.801Z",
@@ -36,7 +36,7 @@
36
  "body": "Customers and partners can find an incident summary report, here: https://community.akamai.com/customers/s/feed/0D5a700001QPRcTCAX",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "minor",
39
- "last_seen": "2026-09-04T09:06:33Z",
40
  "resolved_at": "2026-08-26T10:16:18.115Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-08-25T16:52:37.293Z",
@@ -49,7 +49,7 @@
49
  "body": "We can confirm that the issue was mitigated at 14:25 UTC on August 22, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001Psh2gCAB or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
50
  "first_seen": "2026-09-04T07:06:16Z",
51
  "impact": "minor",
52
- "last_seen": "2026-09-04T09:06:33Z",
53
  "resolved_at": "2026-08-24T18:50:49.215Z",
54
  "resolved_inferred": false,
55
  "started_at": "2026-08-22T11:21:42.123Z",
@@ -62,7 +62,7 @@
62
  "body": "We can confirm that the issue was mitigated at 23:50 UTC on August 24, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001PVMc9CAH or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
63
  "first_seen": "2026-09-04T07:06:16Z",
64
  "impact": "minor",
65
- "last_seen": "2026-09-04T09:06:33Z",
66
  "resolved_at": "2026-08-28T21:59:26.418Z",
67
  "resolved_inferred": false,
68
  "started_at": "2026-08-20T16:43:42.326Z",
@@ -75,7 +75,7 @@
75
  "body": "We can confirm that the issue was mitigated at 03:34 UTC on 19 August, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001PHy9qCAD or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
76
  "first_seen": "2026-09-04T07:06:16Z",
77
  "impact": "none",
78
- "last_seen": "2026-09-04T09:06:33Z",
79
  "resolved_at": "2026-08-20T14:46:53.877Z",
80
  "resolved_inferred": false,
81
  "started_at": "2026-08-19T16:10:55.895Z",
@@ -88,7 +88,7 @@
88
  "body": "We can confirm that the issue was mitigated at 14:48 UTC on August 14, 2026,&nbsp;and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001NmwELCAZ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
89
  "first_seen": "2026-09-04T07:06:16Z",
90
  "impact": "minor",
91
- "last_seen": "2026-09-04T09:06:33Z",
92
  "resolved_at": "2026-08-14T19:40:32.855Z",
93
  "resolved_inferred": false,
94
  "started_at": "2026-08-14T14:53:36.527Z",
@@ -101,7 +101,7 @@
101
  "body": "We can confirm that the issue was confirmed mitigated at 20:42 UTC on August 18, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001Nh4U3CAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
102
  "first_seen": "2026-09-04T07:06:16Z",
103
  "impact": "minor",
104
- "last_seen": "2026-09-04T09:06:33Z",
105
  "resolved_at": "2026-08-18T21:29:49.005Z",
106
  "resolved_inferred": false,
107
  "started_at": "2026-08-13T19:31:27.629Z",
@@ -114,7 +114,7 @@
114
  "body": "We can confirm that the issue was mitigated at 11:50 UTC on August 12, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001NOXC4CAP or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
115
  "first_seen": "2026-09-04T07:06:16Z",
116
  "impact": "none",
117
- "last_seen": "2026-09-04T09:06:33Z",
118
  "resolved_at": "2026-08-13T13:52:57.111Z",
119
  "resolved_inferred": false,
120
  "started_at": "2026-08-12T13:02:24.232Z",
@@ -127,7 +127,7 @@
127
  "body": "We can confirm that the issue was mitigated at 08:30 UTC on August 14, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001NAvXBCA1 or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
128
  "first_seen": "2026-09-04T07:06:16Z",
129
  "impact": "minor",
130
- "last_seen": "2026-09-04T09:06:33Z",
131
  "resolved_at": "2026-08-14T17:08:09.838Z",
132
  "resolved_inferred": false,
133
  "started_at": "2026-08-11T10:11:57.929Z",
@@ -140,7 +140,7 @@
140
  "body": "We became aware of an issue with Web Security Analytics related to Empty HTTP Accept Language and Content Length header values being logged. The issue lasted between 11:30 UTC on August 3, 2026, and 14:00 UTC on August 4, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001M5NvWCAV or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
141
  "first_seen": "2026-09-04T07:06:16Z",
142
  "impact": "none",
143
- "last_seen": "2026-09-04T09:06:33Z",
144
  "resolved_at": "2026-08-04T14:00:00.000Z",
145
  "resolved_inferred": false,
146
  "started_at": "2026-08-04T14:00:00.000Z",
@@ -153,7 +153,7 @@
153
  "body": "We can confirm that the issue was mitigated at 00:20 UTC on August 4, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001M2nELCAZ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
154
  "first_seen": "2026-09-04T07:06:16Z",
155
  "impact": "none",
156
- "last_seen": "2026-09-04T09:06:33Z",
157
  "resolved_at": "2026-08-05T14:33:05.909Z",
158
  "resolved_inferred": false,
159
  "started_at": "2026-08-04T07:54:30.387Z",
@@ -166,7 +166,7 @@
166
  "body": "We can confirm that the issue was mitigated at 09:05 UTC on August 1, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001LizHpCAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
167
  "first_seen": "2026-09-04T07:06:16Z",
168
  "impact": "minor",
169
- "last_seen": "2026-09-04T09:06:33Z",
170
  "resolved_at": "2026-08-01T12:14:33.276Z",
171
  "resolved_inferred": false,
172
  "started_at": "2026-08-01T10:54:20.448Z",
@@ -179,7 +179,7 @@
179
  "body": "We can confirm that the issue was mitigated at 14:21 UTC on 29 July 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001LBrwDCAT, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
180
  "first_seen": "2026-09-04T07:06:16Z",
181
  "impact": "minor",
182
- "last_seen": "2026-09-04T09:06:33Z",
183
  "resolved_at": "2026-07-29T17:06:22.854Z",
184
  "resolved_inferred": false,
185
  "started_at": "2026-07-29T14:48:18.227Z",
@@ -192,7 +192,7 @@
192
  "body": "We can confirm that the issue was mitigated at 01:30 UTC on 27 July 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001Kh1F0CAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "minor",
195
- "last_seen": "2026-09-04T09:06:33Z",
196
  "resolved_at": "2026-07-27T06:07:31.956Z",
197
  "resolved_inferred": false,
198
  "started_at": "2026-07-27T01:46:47.329Z",
@@ -205,7 +205,7 @@
205
  "body": "We can confirm that the issue was mitigated at 12:00 UTC on July 24, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001KQ2QQCA1 or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
206
  "first_seen": "2026-09-04T07:06:16Z",
207
  "impact": "minor",
208
- "last_seen": "2026-09-04T09:06:33Z",
209
  "resolved_at": "2026-07-24T18:45:31.126Z",
210
  "resolved_inferred": false,
211
  "started_at": "2026-07-24T12:21:37.517Z",
@@ -218,7 +218,7 @@
218
  "body": "We can confirm that the issue was mitigated at 04:10 UTC on July 19, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001JVmHpCAL or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
219
  "first_seen": "2026-09-04T07:06:16Z",
220
  "impact": "none",
221
- "last_seen": "2026-09-04T09:06:33Z",
222
  "resolved_at": "2026-07-20T14:46:38.457Z",
223
  "resolved_inferred": false,
224
  "started_at": "2026-07-19T07:40:27.560Z",
@@ -231,7 +231,7 @@
231
  "body": "We can confirm that the issue was mitigated at 04:36 UTC on 16 July 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001J1h4UCAR or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
232
  "first_seen": "2026-09-04T07:06:16Z",
233
  "impact": "minor",
234
- "last_seen": "2026-09-04T09:06:33Z",
235
  "resolved_at": "2026-07-23T02:06:06.179Z",
236
  "resolved_inferred": false,
237
  "started_at": "2026-07-16T04:21:58.828Z",
@@ -244,7 +244,7 @@
244
  "body": "We can confirm that the issue was mitigated at 4:20 UTC on July 2, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
245
  "first_seen": "2026-09-04T07:06:16Z",
246
  "impact": "minor",
247
- "last_seen": "2026-09-04T09:06:33Z",
248
  "resolved_at": "2026-07-06T04:11:26.005Z",
249
  "resolved_inferred": false,
250
  "started_at": "2026-07-02T14:40:01.861Z",
@@ -257,7 +257,7 @@
257
  "body": "We can confirm that the issue was mitigated at 21:14 UTC on June 30, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to https://community.akamai.com/customers/s/feed/0D5a700001GabcKCAR or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
258
  "first_seen": "2026-09-04T07:06:16Z",
259
  "impact": "minor",
260
- "last_seen": "2026-09-04T09:06:33Z",
261
  "resolved_at": "2026-06-30T22:02:40.317Z",
262
  "resolved_inferred": false,
263
  "started_at": "2026-06-30T21:15:05.493Z",
@@ -270,7 +270,7 @@
270
  "body": "We can confirm that the issue was mitigated at 16:50 UTC on June 28, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001GB7HRCA1 or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
271
  "first_seen": "2026-09-04T07:06:16Z",
272
  "impact": "minor",
273
- "last_seen": "2026-09-04T09:06:33Z",
274
  "resolved_at": "2026-06-29T15:42:59.184Z",
275
  "resolved_inferred": false,
276
  "started_at": "2026-06-28T14:45:34.035Z",
@@ -283,7 +283,7 @@
283
  "body": "We can confirm that the issue was mitigated at 20:55 UTC on 25 June 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001FiyHGCAZ, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
284
  "first_seen": "2026-09-04T07:06:16Z",
285
  "impact": "minor",
286
- "last_seen": "2026-09-04T09:06:33Z",
287
  "resolved_at": "2026-06-26T23:35:06.212Z",
288
  "resolved_inferred": false,
289
  "started_at": "2026-06-25T18:14:17.634Z",
@@ -296,7 +296,7 @@
296
  "body": "We became aware of an issue with HTTP and HTTPS related to latency and performance degradation while accessing the applications. The issue lasted between 13:37 UTC and 14:20 UTC on June 16, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001E6lLpCAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
297
  "first_seen": "2026-09-04T07:06:16Z",
298
  "impact": "none",
299
- "last_seen": "2026-09-04T09:06:33Z",
300
  "resolved_at": "2026-06-16T15:45:24.635Z",
301
  "resolved_inferred": false,
302
  "started_at": "2026-06-16T15:45:24.572Z",
@@ -309,7 +309,7 @@
309
  "body": "We identified an issue with the Datastream service where between 10:00 UTC and 21:00 UTC on June 11, 2026, customers may have experienced degraded fidelity on CDN observability streams. We can confirm that the issue is now mitigated as of 21:00 UTC on June 11, 2026, and no longer occurring. Customers and partners can find more details on the Akamai Community: https://community.akamai.com/customers/s/feed/0D5a700001DVkdgCAD. We apologize for any impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence.",
310
  "first_seen": "2026-09-04T07:06:16Z",
311
  "impact": "none",
312
- "last_seen": "2026-09-04T09:06:33Z",
313
  "resolved_at": "2026-06-12T14:58:05.609Z",
314
  "resolved_inferred": false,
315
  "started_at": "2026-06-12T14:58:05.505Z",
@@ -322,7 +322,7 @@
322
  "body": "We can confirm that the issue was mitigated at 18:41 UTC on June 10, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001D7uShCAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
323
  "first_seen": "2026-09-04T07:06:16Z",
324
  "impact": "minor",
325
- "last_seen": "2026-09-04T09:06:33Z",
326
  "resolved_at": "2026-06-11T16:41:41.011Z",
327
  "resolved_inferred": false,
328
  "started_at": "2026-06-10T18:38:27.837Z",
@@ -335,7 +335,7 @@
335
  "body": "We can confirm that the issue was mitigated at 1:30 UTC on June 6, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001CQ6lqCAD or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
336
  "first_seen": "2026-09-04T07:06:16Z",
337
  "impact": "minor",
338
- "last_seen": "2026-09-04T09:06:33Z",
339
  "resolved_at": "2026-06-06T07:21:13.014Z",
340
  "resolved_inferred": false,
341
  "started_at": "2026-06-06T04:29:26.000Z",
@@ -348,7 +348,7 @@
348
  "body": "We can confirm that the issue was mitigated at 17:30 UTC on June 12, 2026, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015iVQMCA2, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
349
  "first_seen": "2026-09-04T07:06:16Z",
350
  "impact": "minor",
351
- "last_seen": "2026-09-04T09:06:33Z",
352
  "resolved_at": "2026-06-19T11:07:17.400Z",
353
  "resolved_inferred": false,
354
  "started_at": "2026-06-05T16:16:27.279Z",
@@ -361,7 +361,7 @@
361
  "body": "We became aware of an issue with HTTP and HTTPS related to latency while accessing the applications. The issue lasted between 11:18 UTC and 12:22 UTC on May 27, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001ANLNkCAP or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
362
  "first_seen": "2026-09-04T07:06:16Z",
363
  "impact": "none",
364
- "last_seen": "2026-09-04T09:06:33Z",
365
  "resolved_at": "2026-05-27T13:28:12.247Z",
366
  "resolved_inferred": false,
367
  "started_at": "2026-05-27T13:28:12.019Z",
@@ -374,7 +374,7 @@
374
  "body": "We can confirm that the issue was mitigated at 14:50 UTC on May 21, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000019St8yCAC or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
375
  "first_seen": "2026-09-04T07:06:16Z",
376
  "impact": "minor",
377
- "last_seen": "2026-09-04T09:06:33Z",
378
  "resolved_at": "2026-05-21T16:52:10.334Z",
379
  "resolved_inferred": false,
380
  "started_at": "2026-05-21T13:58:05.340Z",
@@ -387,7 +387,7 @@
387
  "body": "Starting around 12:00 UTC on May 20, 2026, users experienced difficulties with configuration deployments for mPulse and EdgeWorkers. During this period, activations within Property Manager were impacted, preventing affected customers from successfully updating or deploying these configurations.\n\nAkamai initiated an investigation and determined that the issue was caused by a tripped circuit breaker, which resulted in multiple racks in the data center losing power. We responded with a series of coordinated actions to address both the immediate power outage and its downstream effects on critical services. At 14:45 UTC on May 20, 2026, a failover was completed, and by 14:55 UTC on May 20, 2026, error rates in the Akamai Control Center began to decrease, and the issue was mitigated.\n\nWe will continue to investigate the root cause and will take appropriate preventive actions. We apologize for the impact. We appreciate your patience as we worked to resolve this issue. If you have further questions, please post them on [https://community.akamai.com/customers/s/feed/0D5a7000019DgxBCAS](https://community.akamai.com/customers/s/feed/0D5a7000019DgxBCAS).\n\nThis summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.",
388
  "first_seen": "2026-09-04T07:06:16Z",
389
  "impact": "minor",
390
- "last_seen": "2026-09-04T09:06:33Z",
391
  "resolved_at": "2026-05-21T12:36:41.094Z",
392
  "resolved_inferred": false,
393
  "started_at": "2026-05-20T14:29:36.858Z",
@@ -400,7 +400,7 @@
400
  "body": "We can confirm that the issue was mitigated and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000018q2TuCAI or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
401
  "first_seen": "2026-09-04T07:06:16Z",
402
  "impact": "minor",
403
- "last_seen": "2026-09-04T09:06:33Z",
404
  "resolved_at": "2026-06-01T07:46:02.442Z",
405
  "resolved_inferred": false,
406
  "started_at": "2026-05-19T10:13:33.000Z",
@@ -413,7 +413,7 @@
413
  "body": "We can confirm that the issue was mitigated at 18:21 UTC on May 14th, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a70000189Hk3CAE, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
414
  "first_seen": "2026-09-04T07:06:16Z",
415
  "impact": "minor",
416
- "last_seen": "2026-09-04T09:06:33Z",
417
  "resolved_at": "2026-05-14T18:45:51.890Z",
418
  "resolved_inferred": false,
419
  "started_at": "2026-05-14T18:08:25.615Z",
@@ -426,7 +426,7 @@
426
  "body": "We can confirm that the issue was mitigated at approximately 09:40 UTC on May 13, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000017tokVCAQ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
427
  "first_seen": "2026-09-04T07:06:16Z",
428
  "impact": "minor",
429
- "last_seen": "2026-09-04T09:06:33Z",
430
  "resolved_at": "2026-05-13T10:25:03.179Z",
431
  "resolved_inferred": false,
432
  "started_at": "2026-05-13T09:33:04.568Z",
@@ -439,7 +439,7 @@
439
  "body": "Customers and partners can find an incident summary report here: https://community.akamai.com/customers/s/feed/0D5a7000017mjDUCAY",
440
  "first_seen": "2026-09-04T07:06:16Z",
441
  "impact": "minor",
442
- "last_seen": "2026-09-04T09:06:33Z",
443
  "resolved_at": "2026-05-13T01:08:51.634Z",
444
  "resolved_inferred": false,
445
  "started_at": "2026-05-12T17:08:25.136Z",
@@ -452,7 +452,7 @@
452
  "body": "We can confirm that the issue was mitigated at 23:13 UTC on May 11, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000017a38WCAQ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
453
  "first_seen": "2026-09-04T07:06:16Z",
454
  "impact": "minor",
455
- "last_seen": "2026-09-04T09:06:33Z",
456
  "resolved_at": "2026-05-12T19:18:56.055Z",
457
  "resolved_inferred": false,
458
  "started_at": "2026-05-11T16:03:03.105Z",
@@ -465,7 +465,7 @@
465
  "body": "We can confirm that the issue was mitigated at approximately 11:30 UTC on May 6, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000016uVhvCAE or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
466
  "first_seen": "2026-09-04T07:06:16Z",
467
  "impact": "minor",
468
- "last_seen": "2026-09-04T09:06:33Z",
469
  "resolved_at": "2026-05-06T12:01:06.153Z",
470
  "resolved_inferred": false,
471
  "started_at": "2026-05-06T11:21:27.308Z",
@@ -478,7 +478,7 @@
478
  "body": "We can confirm that the issue was mitigated at 19:00 UTC on April 30, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a70000168PJsCAM, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
479
  "first_seen": "2026-09-04T07:06:16Z",
480
  "impact": "minor",
481
- "last_seen": "2026-09-04T09:06:33Z",
482
  "resolved_at": "2026-04-30T20:00:19.679Z",
483
  "resolved_inferred": false,
484
  "started_at": "2026-04-30T18:41:53.530Z",
@@ -491,7 +491,7 @@
491
  "body": "We can confirm that the issue was mitigated at 06:50 UTC on May 4, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015pThhCAE or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
492
  "first_seen": "2026-09-04T07:06:16Z",
493
  "impact": "minor",
494
- "last_seen": "2026-09-04T09:06:33Z",
495
  "resolved_at": "2026-05-04T12:24:25.340Z",
496
  "resolved_inferred": false,
497
  "started_at": "2026-04-29T05:19:52.480Z",
@@ -504,7 +504,7 @@
504
  "body": "We can confirm that the issue was mitigated at 12:00 UTC on 2 May, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015jW2OCAU or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
505
  "first_seen": "2026-09-04T07:06:16Z",
506
  "impact": "minor",
507
- "last_seen": "2026-09-04T09:06:33Z",
508
  "resolved_at": "2026-05-04T03:05:38.891Z",
509
  "resolved_inferred": false,
510
  "started_at": "2026-04-28T16:42:43.247Z",
@@ -517,7 +517,7 @@
517
  "body": "We can confirm that the issue was mitigated at 16:20 UTC on April 28, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015iVQMCA2, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
518
  "first_seen": "2026-09-04T07:06:16Z",
519
  "impact": "minor",
520
- "last_seen": "2026-09-04T09:06:33Z",
521
  "resolved_at": "2026-04-28T23:37:50.470Z",
522
  "resolved_inferred": false,
523
  "started_at": "2026-04-28T15:40:33.808Z",
@@ -530,7 +530,7 @@
530
  "body": "We can confirm that the issue was mitigated at 13:30 UTC on April 28, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015dBomCAE or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
531
  "first_seen": "2026-09-04T07:06:16Z",
532
  "impact": "minor",
533
- "last_seen": "2026-09-04T09:06:33Z",
534
  "resolved_at": "2026-04-28T17:02:49.219Z",
535
  "resolved_inferred": false,
536
  "started_at": "2026-04-28T02:50:21.736Z",
@@ -543,7 +543,7 @@
543
  "body": "We can confirm that the issue was mitigated at 05:26 UTC on 27 April, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015Qwi8CAC or reaching out to Akamai Support.\n\nWe apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
544
  "first_seen": "2026-09-04T07:06:16Z",
545
  "impact": "minor",
546
- "last_seen": "2026-09-04T09:06:33Z",
547
  "resolved_at": "2026-04-27T13:27:25.583Z",
548
  "resolved_inferred": false,
549
  "started_at": "2026-04-27T03:20:42.690Z",
@@ -556,7 +556,7 @@
556
  "body": "We can confirm that the issue was mitigated at 23:36 UTC on April 24, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015H7xxCAC?language=en_US or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
557
  "first_seen": "2026-09-04T07:06:16Z",
558
  "impact": "minor",
559
- "last_seen": "2026-09-04T09:06:33Z",
560
  "resolved_at": "2026-04-24T23:52:45.134Z",
561
  "resolved_inferred": false,
562
  "started_at": "2026-04-24T20:07:51.874Z",
@@ -569,7 +569,7 @@
569
  "body": "We can confirm that the issue was mitigated at 10:45 UTC on April 28, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a70000151eEnCAI or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
570
  "first_seen": "2026-09-04T07:06:16Z",
571
  "impact": "minor",
572
- "last_seen": "2026-09-04T09:06:33Z",
573
  "resolved_at": "2026-04-28T17:39:18.528Z",
574
  "resolved_inferred": false,
575
  "started_at": "2026-04-23T14:11:12.339Z",
@@ -582,7 +582,7 @@
582
  "body": "We became aware of an issue in the Akamai Control Center related to errors when using multiple tools within \"Edge Diagnostics\". The issue lasted between 20:34 UTC on April 22, 2026, and 8:31 UTC on April 23, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000014zYTlCAM or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
583
  "first_seen": "2026-09-04T07:06:16Z",
584
  "impact": "none",
585
- "last_seen": "2026-09-04T09:06:33Z",
586
  "resolved_at": "2026-04-23T09:44:30.000Z",
587
  "resolved_inferred": false,
588
  "started_at": "2026-04-23T09:44:30.000Z",
@@ -595,7 +595,7 @@
595
  "body": "Customers and partners can find an incident summary report, here: https://community.akamai.com/customers/s/feed/0D5a7000014QIlOCAW",
596
  "first_seen": "2026-09-04T07:06:16Z",
597
  "impact": "minor",
598
- "last_seen": "2026-09-04T09:06:33Z",
599
  "resolved_at": "2026-04-21T01:07:38.369Z",
600
  "resolved_inferred": false,
601
  "started_at": "2026-04-20T12:25:21.935Z",
@@ -608,7 +608,7 @@
608
  "body": "We can confirm that the issue was mitigated at 04:57 UTC on 16 April 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000013s3OVCAY or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
609
  "first_seen": "2026-09-04T07:06:16Z",
610
  "impact": "minor",
611
- "last_seen": "2026-09-04T09:06:33Z",
612
  "resolved_at": "2026-04-16T06:44:20.283Z",
613
  "resolved_inferred": false,
614
  "started_at": "2026-04-16T03:17:27.921Z",
@@ -621,7 +621,7 @@
621
  "body": "We can confirm that the issue was mitigated at 11:30 UTC on April 8, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000012Uk7TCAS or reaching out to Akamai Support.\n\nWe apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
622
  "first_seen": "2026-09-04T07:06:16Z",
623
  "impact": "minor",
624
- "last_seen": "2026-09-04T09:06:33Z",
625
  "resolved_at": "2026-04-08T13:02:20.777Z",
626
  "resolved_inferred": false,
627
  "started_at": "2026-04-07T18:43:51.686Z",
@@ -634,7 +634,7 @@
634
  "body": "We can confirm that the issue was mitigated at 11:00 UTC on April 13, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000012RCWbCAO or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
635
  "first_seen": "2026-09-04T07:06:16Z",
636
  "impact": "minor",
637
- "last_seen": "2026-09-04T09:06:33Z",
638
  "resolved_at": "2026-04-14T19:47:46.021Z",
639
  "resolved_inferred": false,
640
  "started_at": "2026-04-07T12:11:07.442Z",
@@ -647,7 +647,7 @@
647
  "body": "We can confirm that the issue was mitigated at 23:12 UTC on April 10, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
648
  "first_seen": "2026-09-04T07:06:16Z",
649
  "impact": "minor",
650
- "last_seen": "2026-09-04T09:06:33Z",
651
  "resolved_at": "2026-04-15T16:02:59.494Z",
652
  "resolved_inferred": false,
653
  "started_at": "2026-04-06T18:22:58.211Z",
 
3
  "slug": "akamai-edge-dns",
4
  "platform": "statuspage",
5
  "status_url": "https://edgedns.status.akamai.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "degraded",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "We are continuing to investigate this issue. Customers and partners can find more details on the Akamai Community: https://community.akamai.com/customers/s/feed/0D5a700001S7tYbCAJ. We will provide the next update as we make progress.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "started_at": "2026-09-04T06:14:59.971Z",
17
  "state": "investigating",
18
  "title": "Application Load Balancer reporting availability issues",
 
23
  "body": "We can confirm that the issue was mitigated at 03:30 UTC on 28 August 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001QvOI6CAN or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
24
  "first_seen": "2026-09-04T07:06:16Z",
25
  "impact": "minor",
26
+ "last_seen": "2026-09-04T10:17:20Z",
27
  "resolved_at": "2026-08-28T04:52:29.929Z",
28
  "resolved_inferred": false,
29
  "started_at": "2026-08-28T01:33:18.801Z",
 
36
  "body": "Customers and partners can find an incident summary report, here: https://community.akamai.com/customers/s/feed/0D5a700001QPRcTCAX",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "minor",
39
+ "last_seen": "2026-09-04T10:17:20Z",
40
  "resolved_at": "2026-08-26T10:16:18.115Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-08-25T16:52:37.293Z",
 
49
  "body": "We can confirm that the issue was mitigated at 14:25 UTC on August 22, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001Psh2gCAB or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
50
  "first_seen": "2026-09-04T07:06:16Z",
51
  "impact": "minor",
52
+ "last_seen": "2026-09-04T10:17:20Z",
53
  "resolved_at": "2026-08-24T18:50:49.215Z",
54
  "resolved_inferred": false,
55
  "started_at": "2026-08-22T11:21:42.123Z",
 
62
  "body": "We can confirm that the issue was mitigated at 23:50 UTC on August 24, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001PVMc9CAH or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
63
  "first_seen": "2026-09-04T07:06:16Z",
64
  "impact": "minor",
65
+ "last_seen": "2026-09-04T10:17:20Z",
66
  "resolved_at": "2026-08-28T21:59:26.418Z",
67
  "resolved_inferred": false,
68
  "started_at": "2026-08-20T16:43:42.326Z",
 
75
  "body": "We can confirm that the issue was mitigated at 03:34 UTC on 19 August, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001PHy9qCAD or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
76
  "first_seen": "2026-09-04T07:06:16Z",
77
  "impact": "none",
78
+ "last_seen": "2026-09-04T10:17:20Z",
79
  "resolved_at": "2026-08-20T14:46:53.877Z",
80
  "resolved_inferred": false,
81
  "started_at": "2026-08-19T16:10:55.895Z",
 
88
  "body": "We can confirm that the issue was mitigated at 14:48 UTC on August 14, 2026,&nbsp;and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001NmwELCAZ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
89
  "first_seen": "2026-09-04T07:06:16Z",
90
  "impact": "minor",
91
+ "last_seen": "2026-09-04T10:17:20Z",
92
  "resolved_at": "2026-08-14T19:40:32.855Z",
93
  "resolved_inferred": false,
94
  "started_at": "2026-08-14T14:53:36.527Z",
 
101
  "body": "We can confirm that the issue was confirmed mitigated at 20:42 UTC on August 18, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001Nh4U3CAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
102
  "first_seen": "2026-09-04T07:06:16Z",
103
  "impact": "minor",
104
+ "last_seen": "2026-09-04T10:17:20Z",
105
  "resolved_at": "2026-08-18T21:29:49.005Z",
106
  "resolved_inferred": false,
107
  "started_at": "2026-08-13T19:31:27.629Z",
 
114
  "body": "We can confirm that the issue was mitigated at 11:50 UTC on August 12, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001NOXC4CAP or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
115
  "first_seen": "2026-09-04T07:06:16Z",
116
  "impact": "none",
117
+ "last_seen": "2026-09-04T10:17:20Z",
118
  "resolved_at": "2026-08-13T13:52:57.111Z",
119
  "resolved_inferred": false,
120
  "started_at": "2026-08-12T13:02:24.232Z",
 
127
  "body": "We can confirm that the issue was mitigated at 08:30 UTC on August 14, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001NAvXBCA1 or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
128
  "first_seen": "2026-09-04T07:06:16Z",
129
  "impact": "minor",
130
+ "last_seen": "2026-09-04T10:17:20Z",
131
  "resolved_at": "2026-08-14T17:08:09.838Z",
132
  "resolved_inferred": false,
133
  "started_at": "2026-08-11T10:11:57.929Z",
 
140
  "body": "We became aware of an issue with Web Security Analytics related to Empty HTTP Accept Language and Content Length header values being logged. The issue lasted between 11:30 UTC on August 3, 2026, and 14:00 UTC on August 4, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001M5NvWCAV or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
141
  "first_seen": "2026-09-04T07:06:16Z",
142
  "impact": "none",
143
+ "last_seen": "2026-09-04T10:17:20Z",
144
  "resolved_at": "2026-08-04T14:00:00.000Z",
145
  "resolved_inferred": false,
146
  "started_at": "2026-08-04T14:00:00.000Z",
 
153
  "body": "We can confirm that the issue was mitigated at 00:20 UTC on August 4, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001M2nELCAZ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
154
  "first_seen": "2026-09-04T07:06:16Z",
155
  "impact": "none",
156
+ "last_seen": "2026-09-04T10:17:20Z",
157
  "resolved_at": "2026-08-05T14:33:05.909Z",
158
  "resolved_inferred": false,
159
  "started_at": "2026-08-04T07:54:30.387Z",
 
166
  "body": "We can confirm that the issue was mitigated at 09:05 UTC on August 1, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001LizHpCAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
167
  "first_seen": "2026-09-04T07:06:16Z",
168
  "impact": "minor",
169
+ "last_seen": "2026-09-04T10:17:20Z",
170
  "resolved_at": "2026-08-01T12:14:33.276Z",
171
  "resolved_inferred": false,
172
  "started_at": "2026-08-01T10:54:20.448Z",
 
179
  "body": "We can confirm that the issue was mitigated at 14:21 UTC on 29 July 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001LBrwDCAT, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
180
  "first_seen": "2026-09-04T07:06:16Z",
181
  "impact": "minor",
182
+ "last_seen": "2026-09-04T10:17:20Z",
183
  "resolved_at": "2026-07-29T17:06:22.854Z",
184
  "resolved_inferred": false,
185
  "started_at": "2026-07-29T14:48:18.227Z",
 
192
  "body": "We can confirm that the issue was mitigated at 01:30 UTC on 27 July 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001Kh1F0CAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "minor",
195
+ "last_seen": "2026-09-04T10:17:20Z",
196
  "resolved_at": "2026-07-27T06:07:31.956Z",
197
  "resolved_inferred": false,
198
  "started_at": "2026-07-27T01:46:47.329Z",
 
205
  "body": "We can confirm that the issue was mitigated at 12:00 UTC on July 24, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001KQ2QQCA1 or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
206
  "first_seen": "2026-09-04T07:06:16Z",
207
  "impact": "minor",
208
+ "last_seen": "2026-09-04T10:17:20Z",
209
  "resolved_at": "2026-07-24T18:45:31.126Z",
210
  "resolved_inferred": false,
211
  "started_at": "2026-07-24T12:21:37.517Z",
 
218
  "body": "We can confirm that the issue was mitigated at 04:10 UTC on July 19, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001JVmHpCAL or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
219
  "first_seen": "2026-09-04T07:06:16Z",
220
  "impact": "none",
221
+ "last_seen": "2026-09-04T10:17:20Z",
222
  "resolved_at": "2026-07-20T14:46:38.457Z",
223
  "resolved_inferred": false,
224
  "started_at": "2026-07-19T07:40:27.560Z",
 
231
  "body": "We can confirm that the issue was mitigated at 04:36 UTC on 16 July 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001J1h4UCAR or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
232
  "first_seen": "2026-09-04T07:06:16Z",
233
  "impact": "minor",
234
+ "last_seen": "2026-09-04T10:17:20Z",
235
  "resolved_at": "2026-07-23T02:06:06.179Z",
236
  "resolved_inferred": false,
237
  "started_at": "2026-07-16T04:21:58.828Z",
 
244
  "body": "We can confirm that the issue was mitigated at 4:20 UTC on July 2, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
245
  "first_seen": "2026-09-04T07:06:16Z",
246
  "impact": "minor",
247
+ "last_seen": "2026-09-04T10:17:20Z",
248
  "resolved_at": "2026-07-06T04:11:26.005Z",
249
  "resolved_inferred": false,
250
  "started_at": "2026-07-02T14:40:01.861Z",
 
257
  "body": "We can confirm that the issue was mitigated at 21:14 UTC on June 30, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to https://community.akamai.com/customers/s/feed/0D5a700001GabcKCAR or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
258
  "first_seen": "2026-09-04T07:06:16Z",
259
  "impact": "minor",
260
+ "last_seen": "2026-09-04T10:17:20Z",
261
  "resolved_at": "2026-06-30T22:02:40.317Z",
262
  "resolved_inferred": false,
263
  "started_at": "2026-06-30T21:15:05.493Z",
 
270
  "body": "We can confirm that the issue was mitigated at 16:50 UTC on June 28, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001GB7HRCA1 or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
271
  "first_seen": "2026-09-04T07:06:16Z",
272
  "impact": "minor",
273
+ "last_seen": "2026-09-04T10:17:20Z",
274
  "resolved_at": "2026-06-29T15:42:59.184Z",
275
  "resolved_inferred": false,
276
  "started_at": "2026-06-28T14:45:34.035Z",
 
283
  "body": "We can confirm that the issue was mitigated at 20:55 UTC on 25 June 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001FiyHGCAZ, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
284
  "first_seen": "2026-09-04T07:06:16Z",
285
  "impact": "minor",
286
+ "last_seen": "2026-09-04T10:17:20Z",
287
  "resolved_at": "2026-06-26T23:35:06.212Z",
288
  "resolved_inferred": false,
289
  "started_at": "2026-06-25T18:14:17.634Z",
 
296
  "body": "We became aware of an issue with HTTP and HTTPS related to latency and performance degradation while accessing the applications. The issue lasted between 13:37 UTC and 14:20 UTC on June 16, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001E6lLpCAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
297
  "first_seen": "2026-09-04T07:06:16Z",
298
  "impact": "none",
299
+ "last_seen": "2026-09-04T10:17:20Z",
300
  "resolved_at": "2026-06-16T15:45:24.635Z",
301
  "resolved_inferred": false,
302
  "started_at": "2026-06-16T15:45:24.572Z",
 
309
  "body": "We identified an issue with the Datastream service where between 10:00 UTC and 21:00 UTC on June 11, 2026, customers may have experienced degraded fidelity on CDN observability streams. We can confirm that the issue is now mitigated as of 21:00 UTC on June 11, 2026, and no longer occurring. Customers and partners can find more details on the Akamai Community: https://community.akamai.com/customers/s/feed/0D5a700001DVkdgCAD. We apologize for any impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent recurrence.",
310
  "first_seen": "2026-09-04T07:06:16Z",
311
  "impact": "none",
312
+ "last_seen": "2026-09-04T10:17:20Z",
313
  "resolved_at": "2026-06-12T14:58:05.609Z",
314
  "resolved_inferred": false,
315
  "started_at": "2026-06-12T14:58:05.505Z",
 
322
  "body": "We can confirm that the issue was mitigated at 18:41 UTC on June 10, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001D7uShCAJ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
323
  "first_seen": "2026-09-04T07:06:16Z",
324
  "impact": "minor",
325
+ "last_seen": "2026-09-04T10:17:20Z",
326
  "resolved_at": "2026-06-11T16:41:41.011Z",
327
  "resolved_inferred": false,
328
  "started_at": "2026-06-10T18:38:27.837Z",
 
335
  "body": "We can confirm that the issue was mitigated at 1:30 UTC on June 6, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001CQ6lqCAD or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
336
  "first_seen": "2026-09-04T07:06:16Z",
337
  "impact": "minor",
338
+ "last_seen": "2026-09-04T10:17:20Z",
339
  "resolved_at": "2026-06-06T07:21:13.014Z",
340
  "resolved_inferred": false,
341
  "started_at": "2026-06-06T04:29:26.000Z",
 
348
  "body": "We can confirm that the issue was mitigated at 17:30 UTC on June 12, 2026, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015iVQMCA2, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
349
  "first_seen": "2026-09-04T07:06:16Z",
350
  "impact": "minor",
351
+ "last_seen": "2026-09-04T10:17:20Z",
352
  "resolved_at": "2026-06-19T11:07:17.400Z",
353
  "resolved_inferred": false,
354
  "started_at": "2026-06-05T16:16:27.279Z",
 
361
  "body": "We became aware of an issue with HTTP and HTTPS related to latency while accessing the applications. The issue lasted between 11:18 UTC and 12:22 UTC on May 27, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a700001ANLNkCAP or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
362
  "first_seen": "2026-09-04T07:06:16Z",
363
  "impact": "none",
364
+ "last_seen": "2026-09-04T10:17:20Z",
365
  "resolved_at": "2026-05-27T13:28:12.247Z",
366
  "resolved_inferred": false,
367
  "started_at": "2026-05-27T13:28:12.019Z",
 
374
  "body": "We can confirm that the issue was mitigated at 14:50 UTC on May 21, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000019St8yCAC or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
375
  "first_seen": "2026-09-04T07:06:16Z",
376
  "impact": "minor",
377
+ "last_seen": "2026-09-04T10:17:20Z",
378
  "resolved_at": "2026-05-21T16:52:10.334Z",
379
  "resolved_inferred": false,
380
  "started_at": "2026-05-21T13:58:05.340Z",
 
387
  "body": "Starting around 12:00 UTC on May 20, 2026, users experienced difficulties with configuration deployments for mPulse and EdgeWorkers. During this period, activations within Property Manager were impacted, preventing affected customers from successfully updating or deploying these configurations.\n\nAkamai initiated an investigation and determined that the issue was caused by a tripped circuit breaker, which resulted in multiple racks in the data center losing power. We responded with a series of coordinated actions to address both the immediate power outage and its downstream effects on critical services. At 14:45 UTC on May 20, 2026, a failover was completed, and by 14:55 UTC on May 20, 2026, error rates in the Akamai Control Center began to decrease, and the issue was mitigated.\n\nWe will continue to investigate the root cause and will take appropriate preventive actions. We apologize for the impact. We appreciate your patience as we worked to resolve this issue. If you have further questions, please post them on [https://community.akamai.com/customers/s/feed/0D5a7000019DgxBCAS](https://community.akamai.com/customers/s/feed/0D5a7000019DgxBCAS).\n\nThis summary provides an overview of our current understanding of the incident given the information available. Our investigation is ongoing and any information herein is subject to change.",
388
  "first_seen": "2026-09-04T07:06:16Z",
389
  "impact": "minor",
390
+ "last_seen": "2026-09-04T10:17:20Z",
391
  "resolved_at": "2026-05-21T12:36:41.094Z",
392
  "resolved_inferred": false,
393
  "started_at": "2026-05-20T14:29:36.858Z",
 
400
  "body": "We can confirm that the issue was mitigated and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000018q2TuCAI or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
401
  "first_seen": "2026-09-04T07:06:16Z",
402
  "impact": "minor",
403
+ "last_seen": "2026-09-04T10:17:20Z",
404
  "resolved_at": "2026-06-01T07:46:02.442Z",
405
  "resolved_inferred": false,
406
  "started_at": "2026-05-19T10:13:33.000Z",
 
413
  "body": "We can confirm that the issue was mitigated at 18:21 UTC on May 14th, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a70000189Hk3CAE, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
414
  "first_seen": "2026-09-04T07:06:16Z",
415
  "impact": "minor",
416
+ "last_seen": "2026-09-04T10:17:20Z",
417
  "resolved_at": "2026-05-14T18:45:51.890Z",
418
  "resolved_inferred": false,
419
  "started_at": "2026-05-14T18:08:25.615Z",
 
426
  "body": "We can confirm that the issue was mitigated at approximately 09:40 UTC on May 13, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000017tokVCAQ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
427
  "first_seen": "2026-09-04T07:06:16Z",
428
  "impact": "minor",
429
+ "last_seen": "2026-09-04T10:17:20Z",
430
  "resolved_at": "2026-05-13T10:25:03.179Z",
431
  "resolved_inferred": false,
432
  "started_at": "2026-05-13T09:33:04.568Z",
 
439
  "body": "Customers and partners can find an incident summary report here: https://community.akamai.com/customers/s/feed/0D5a7000017mjDUCAY",
440
  "first_seen": "2026-09-04T07:06:16Z",
441
  "impact": "minor",
442
+ "last_seen": "2026-09-04T10:17:20Z",
443
  "resolved_at": "2026-05-13T01:08:51.634Z",
444
  "resolved_inferred": false,
445
  "started_at": "2026-05-12T17:08:25.136Z",
 
452
  "body": "We can confirm that the issue was mitigated at 23:13 UTC on May 11, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000017a38WCAQ or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
453
  "first_seen": "2026-09-04T07:06:16Z",
454
  "impact": "minor",
455
+ "last_seen": "2026-09-04T10:17:20Z",
456
  "resolved_at": "2026-05-12T19:18:56.055Z",
457
  "resolved_inferred": false,
458
  "started_at": "2026-05-11T16:03:03.105Z",
 
465
  "body": "We can confirm that the issue was mitigated at approximately 11:30 UTC on May 6, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000016uVhvCAE or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
466
  "first_seen": "2026-09-04T07:06:16Z",
467
  "impact": "minor",
468
+ "last_seen": "2026-09-04T10:17:20Z",
469
  "resolved_at": "2026-05-06T12:01:06.153Z",
470
  "resolved_inferred": false,
471
  "started_at": "2026-05-06T11:21:27.308Z",
 
478
  "body": "We can confirm that the issue was mitigated at 19:00 UTC on April 30, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a70000168PJsCAM, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
479
  "first_seen": "2026-09-04T07:06:16Z",
480
  "impact": "minor",
481
+ "last_seen": "2026-09-04T10:17:20Z",
482
  "resolved_at": "2026-04-30T20:00:19.679Z",
483
  "resolved_inferred": false,
484
  "started_at": "2026-04-30T18:41:53.530Z",
 
491
  "body": "We can confirm that the issue was mitigated at 06:50 UTC on May 4, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015pThhCAE or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
492
  "first_seen": "2026-09-04T07:06:16Z",
493
  "impact": "minor",
494
+ "last_seen": "2026-09-04T10:17:20Z",
495
  "resolved_at": "2026-05-04T12:24:25.340Z",
496
  "resolved_inferred": false,
497
  "started_at": "2026-04-29T05:19:52.480Z",
 
504
  "body": "We can confirm that the issue was mitigated at 12:00 UTC on 2 May, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015jW2OCAU or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
505
  "first_seen": "2026-09-04T07:06:16Z",
506
  "impact": "minor",
507
+ "last_seen": "2026-09-04T10:17:20Z",
508
  "resolved_at": "2026-05-04T03:05:38.891Z",
509
  "resolved_inferred": false,
510
  "started_at": "2026-04-28T16:42:43.247Z",
 
517
  "body": "We can confirm that the issue was mitigated at 16:20 UTC on April 28, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015iVQMCA2, or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
518
  "first_seen": "2026-09-04T07:06:16Z",
519
  "impact": "minor",
520
+ "last_seen": "2026-09-04T10:17:20Z",
521
  "resolved_at": "2026-04-28T23:37:50.470Z",
522
  "resolved_inferred": false,
523
  "started_at": "2026-04-28T15:40:33.808Z",
 
530
  "body": "We can confirm that the issue was mitigated at 13:30 UTC on April 28, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015dBomCAE or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
531
  "first_seen": "2026-09-04T07:06:16Z",
532
  "impact": "minor",
533
+ "last_seen": "2026-09-04T10:17:20Z",
534
  "resolved_at": "2026-04-28T17:02:49.219Z",
535
  "resolved_inferred": false,
536
  "started_at": "2026-04-28T02:50:21.736Z",
 
543
  "body": "We can confirm that the issue was mitigated at 05:26 UTC on 27 April, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015Qwi8CAC or reaching out to Akamai Support.\n\nWe apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
544
  "first_seen": "2026-09-04T07:06:16Z",
545
  "impact": "minor",
546
+ "last_seen": "2026-09-04T10:17:20Z",
547
  "resolved_at": "2026-04-27T13:27:25.583Z",
548
  "resolved_inferred": false,
549
  "started_at": "2026-04-27T03:20:42.690Z",
 
556
  "body": "We can confirm that the issue was mitigated at 23:36 UTC on April 24, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000015H7xxCAC?language=en_US or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
557
  "first_seen": "2026-09-04T07:06:16Z",
558
  "impact": "minor",
559
+ "last_seen": "2026-09-04T10:17:20Z",
560
  "resolved_at": "2026-04-24T23:52:45.134Z",
561
  "resolved_inferred": false,
562
  "started_at": "2026-04-24T20:07:51.874Z",
 
569
  "body": "We can confirm that the issue was mitigated at 10:45 UTC on April 28, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a70000151eEnCAI or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
570
  "first_seen": "2026-09-04T07:06:16Z",
571
  "impact": "minor",
572
+ "last_seen": "2026-09-04T10:17:20Z",
573
  "resolved_at": "2026-04-28T17:39:18.528Z",
574
  "resolved_inferred": false,
575
  "started_at": "2026-04-23T14:11:12.339Z",
 
582
  "body": "We became aware of an issue in the Akamai Control Center related to errors when using multiple tools within \"Edge Diagnostics\". The issue lasted between 20:34 UTC on April 22, 2026, and 8:31 UTC on April 23, 2026. We can confirm that the issue is now resolved, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000014zYTlCAM or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
583
  "first_seen": "2026-09-04T07:06:16Z",
584
  "impact": "none",
585
+ "last_seen": "2026-09-04T10:17:20Z",
586
  "resolved_at": "2026-04-23T09:44:30.000Z",
587
  "resolved_inferred": false,
588
  "started_at": "2026-04-23T09:44:30.000Z",
 
595
  "body": "Customers and partners can find an incident summary report, here: https://community.akamai.com/customers/s/feed/0D5a7000014QIlOCAW",
596
  "first_seen": "2026-09-04T07:06:16Z",
597
  "impact": "minor",
598
+ "last_seen": "2026-09-04T10:17:20Z",
599
  "resolved_at": "2026-04-21T01:07:38.369Z",
600
  "resolved_inferred": false,
601
  "started_at": "2026-04-20T12:25:21.935Z",
 
608
  "body": "We can confirm that the issue was mitigated at 04:57 UTC on 16 April 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000013s3OVCAY or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
609
  "first_seen": "2026-09-04T07:06:16Z",
610
  "impact": "minor",
611
+ "last_seen": "2026-09-04T10:17:20Z",
612
  "resolved_at": "2026-04-16T06:44:20.283Z",
613
  "resolved_inferred": false,
614
  "started_at": "2026-04-16T03:17:27.921Z",
 
621
  "body": "We can confirm that the issue was mitigated at 11:30 UTC on April 8, 2026, and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000012Uk7TCAS or reaching out to Akamai Support.\n\nWe apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
622
  "first_seen": "2026-09-04T07:06:16Z",
623
  "impact": "minor",
624
+ "last_seen": "2026-09-04T10:17:20Z",
625
  "resolved_at": "2026-04-08T13:02:20.777Z",
626
  "resolved_inferred": false,
627
  "started_at": "2026-04-07T18:43:51.686Z",
 
634
  "body": "We can confirm that the issue was mitigated at 11:00 UTC on April 13, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: https://community.akamai.com/customers/s/feed/0D5a7000012RCWbCAO or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
635
  "first_seen": "2026-09-04T07:06:16Z",
636
  "impact": "minor",
637
+ "last_seen": "2026-09-04T10:17:20Z",
638
  "resolved_at": "2026-04-14T19:47:46.021Z",
639
  "resolved_inferred": false,
640
  "started_at": "2026-04-07T12:11:07.442Z",
 
647
  "body": "We can confirm that the issue was mitigated at 23:12 UTC on April 10, 2026 and the service has resumed normal operation. Customers and partners can view additional details about the incident by logging in to: or reaching out to Akamai Support. We apologize for the impact and thank you for your patience and continued support. We are committed to making continuous improvements to make our systems better and prevent a recurrence of this issue.",
648
  "first_seen": "2026-09-04T07:06:16Z",
649
  "impact": "minor",
650
+ "last_seen": "2026-09-04T10:17:20Z",
651
  "resolved_at": "2026-04-15T16:02:59.494Z",
652
  "resolved_inferred": false,
653
  "started_at": "2026-04-06T18:22:58.211Z",
api/v/alchemy.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "alchemy",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alchemy.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "The incident has been resolved. We are continuing to monitor the situation.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-03T16:54:10.399Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T15:41:24.397Z",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-09-03T03:48:05.000Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-09-03T02:58:55.000Z",
@@ -38,7 +38,7 @@
38
  "body": "All networks latencies are back to baseline.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-31T15:34:06.077Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-31T14:39:39.846Z",
@@ -51,7 +51,7 @@
51
  "body": "Incident is resolved and blocks are being produced again - confirmed by Cronost team: https://x.com/CronosNetwork/status/2094417832394301499",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-31T13:38:17.909Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-31T12:15:16.092Z",
@@ -64,7 +64,7 @@
64
  "body": "The elevated latencies affecting Ethereum Mainnet Data APIs have been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-08-29T19:45:42.275Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-29T18:13:47.000Z",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-08-27T20:47:01.000Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-27T20:05:55.000Z",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved! WebSocket subscription delivery for X Layer Mainnet in our US East region has returned to normal. HTTP requests were not affected at any point during this incident",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-08-27T23:40:52.297Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-27T16:18:44.574Z",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved. Between approximately 21:58 UTC and 22:12 UTC, some API requests across multiple networks experienced elevated latency, primarily affecting Token API and Portfolio API balance lookups.\n\nAll services are currently operating normally. We will continue to investigate the underlying cause to prevent recurrence!",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-08-26T22:12:55.000Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-26T21:58:13.000Z",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-08-26T21:59:28.000Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-26T12:30:35.000Z",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-08-25T18:30:50.000Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-25T13:31:17.157Z",
@@ -142,7 +142,7 @@
142
  "body": "A subset of nodes serving Unichain Mainnet in our US East (use1) region experienced stalled safe/finalized block tracking, causing delayed safe/finalized block data for requests routed through that region. The latest block head and overall API serving were unaffected throughout and no elevated error rates were observed.\n\nWe performed a rolling restart of the affected nodes, which resolved the issue. Safe/finalized data is now current and within normal lag across the region.\n\nThis incident is resolved!",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-08-24T18:37:04.751Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-24T12:23:27.483Z",
@@ -155,7 +155,7 @@
155
  "body": "Resolved - Elevated latency on BNB Smart Chain Mainnet JSON-RPC requests has been fully mitigated. All methods are performing within normal latency ranges!",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-08-25T14:25:45.249Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-08-23T14:20:30.217Z",
@@ -168,7 +168,7 @@
168
  "body": "Latency has returned to normal for Robinhood Mainnet. We will continue to monitor the service.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-08-22T22:43:51.868Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-08-22T21:33:48.844Z",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-08-20T01:43:19.879Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-08-20T00:36:00.000Z",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-08-20T16:02:39.853Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-08-19T17:42:17.000Z",
@@ -207,7 +207,7 @@
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-08-19T06:45:37.051Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-08-19T06:00:37.127Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-08-17T14:30:58.000Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-08-17T14:18:14.530Z",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-08-13T15:41:08.000Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-08-13T14:52:31.670Z",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved. Injective Mainnet performance has returned to normal.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-08-14T18:00:57.000Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-08-13T11:36:52.594Z",
@@ -259,7 +259,7 @@
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-08-12T08:03:40.551Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-08-12T04:45:15.286Z",
@@ -272,7 +272,7 @@
272
  "body": "The issue has been resolved. Solana Mainnet service has recovered in Singapore and Tokyo, and we are monitoring the situation closely.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-08-12T04:44:30.569Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-08-12T04:38:33.206Z",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-08-12T02:33:22.475Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-08-12T01:19:45.000Z",
@@ -298,7 +298,7 @@
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-08-10T17:11:14.299Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-08-10T12:29:38.657Z",
@@ -311,7 +311,7 @@
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-08-06T06:12:09.788Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-08-06T06:09:06.830Z",
@@ -324,7 +324,7 @@
324
  "body": "Between 17:22 and 17:35 UTC on August 5, a subset of eth_getUserOperationReceipt requests across multiple networks experienced increased latencies. This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-08-05T17:45:11.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-08-05T17:45:11.000Z",
@@ -337,7 +337,7 @@
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-07-31T16:02:32.197Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-07-31T15:08:55.000Z",
@@ -350,7 +350,7 @@
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-07-31T14:23:36.759Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-07-31T13:19:33.711Z",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-07-31T02:49:50.531Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-07-31T01:07:51.942Z",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-07-30T17:10:12.171Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-07-30T16:04:18.285Z",
@@ -389,7 +389,7 @@
389
  "body": "Between 22:35 and 22:55 UTC on July 30, a subset of requests on Robinhood Mainnet experienced elevated latency. This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-07-30T21:30:00.000Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-07-30T00:00:00.000Z",
@@ -402,7 +402,7 @@
402
  "body": "Between 13:30 UTC on July 28 and 08:00 UTC on July 29, HYPERLIQUID\\_MAINNET requests served from us-east experienced elevated latency, and `eth_sendRawTransaction` returned a high rate of errors. Read methods remained available throughout, with elevated response times.\n\n**Impact**\n\nTransaction submission was the primary failure mode. During the peak period, the large majority of `eth_sendRawTransaction` requests either timed out or returned an error, and clients retrying submissions saw sustained failures. Read traffic on the network was slower than normal but continued to be served successfully. Latency was elevated for all HYPERLIQUID\\_MAINNET request types for the duration of the event.\n\n**Root cause**\n\nA majority of our Hyperliquid full nodes in us-east lost peering with the network. The nodes were unable to complete state synchronization handshakes with upstream peers -- connection attempts were rate limited, timed out, or rejected because peer connection slots were full. Affected nodes fell behind and were removed from the healthy serving pool. Recovery required the upstream peer pool to free capacity; feeding new peers into the configuration and pruning node state did not restore peering.\n\nTwo factors extended the impact:\n\n* With that capacity gone, all us-east traffic concentrated on the remaining archive node pool, which pushed latency up further and made `eth_sendRawTransaction` the first method to fail.\n* On Hyperliquid, transactions are not propagated peer-to-peer. They are relayed to a network-level submission endpoint that can rate limit, which means the transaction submission path is sensitive to network conditions independent of which infrastructure serves the request.\n\n**Resolution**\n\nWe began routing `eth_sendRawTransaction` to secondary infra as soon as the issue was identified, but this did not restore transaction submission. Submissions relayed through secondary infra continued to fail at a comparable rate, since that path depends on the same network-level submission endpoint. \n\nA subset of nodes began to recover from around 01:30 UTC on July 29, when the first `hlnode` in us-east returned to a healthy state as upstream peer capacity freed up. Server-side errors from our serving layer dropped off around the same time, though submissions continued to fail through a mix of remaining unhealthy nodes and rejections at the network's submission endpoint. Peering re-established across the rest of the pool over the following hours. Latency returned to normal levels by approximately 08:00 UTC, request volumes and error rates returned to baseline, and all us-east nodes were confirmed healthy shortly afterward.\n\n**Follow-up**\n\nWe are exploring running our own validator and sentry nodes for Hyperliquid so that peering no longer depends on availability in the shared public peer pool.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-07-29T08:00:53.000Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-07-28T14:06:34.423Z",
@@ -415,7 +415,7 @@
415
  "body": "This is resolved. Base Mainnet's Safe head has caught up and data batching to Ethereum L1 is back to normal. Block production was unaffected throughout. See the Base status page for their full update: https://status.base.org/incidents/j6y12tshwkcg",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-07-28T15:33:18.806Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-07-28T13:26:57.168Z",
@@ -428,7 +428,7 @@
428
  "body": "Nodes have recovered and services are healthy again.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2026-07-27T06:51:48.839Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-07-27T03:39:54.079Z",
@@ -441,7 +441,7 @@
441
  "body": "Nodes have been rescyned with stable binary and services are back to healthy.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2026-07-24T12:49:32.837Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-07-24T09:36:40.044Z",
@@ -454,7 +454,7 @@
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2026-07-24T11:09:57.252Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-07-23T15:12:29.745Z",
@@ -467,7 +467,7 @@
467
  "body": "This incident has been resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2026-07-24T12:00:48.517Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-07-23T09:34:15.165Z",
@@ -480,7 +480,7 @@
480
  "body": "Resolved: All impacted networks, including Mode Sepolia (testnet), have fully recovered and caught up. This incident is now resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2026-07-22T18:42:07.504Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-07-22T18:07:15.813Z",
@@ -493,7 +493,7 @@
493
  "body": "Traffic has been fully restored to the US West region. This incident is now resolved!",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "minor",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2026-07-22T21:00:56.000Z",
498
  "resolved_inferred": false,
499
  "started_at": "2026-07-22T15:51:25.000Z",
@@ -506,7 +506,7 @@
506
  "body": "We have confirmed full recovery across our BNB Smart Chain Mainnet infrastructure. All nodes are healthy and serving traffic normally, with response times and error rates back to baseline. This incident is now resolved. Thank you for your patience!",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "minor",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2026-07-22T14:43:21.230Z",
511
  "resolved_inferred": false,
512
  "started_at": "2026-07-22T07:45:25.000Z",
@@ -519,7 +519,7 @@
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2026-07-21T22:42:10.724Z",
524
  "resolved_inferred": false,
525
  "started_at": "2026-07-21T20:49:23.000Z",
@@ -532,7 +532,7 @@
532
  "body": "Between approximately 23:20 UTC on July 17 and 03:30 UTC on July 18, some Polygon Mainnet requests experienced slower than normal response times, mainly for log queries. The issue was limited to the us-east-1 region.\nThe cause was an unusually heavy request load that put pressure on part of our infrastructure in the region. We added extra capacity and rebalanced traffic, after which performance returned to normal.\n\nThe issue is fully resolved. We apologize for the disruption.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2026-07-17T20:00:00.000Z",
537
  "resolved_inferred": false,
538
  "started_at": "2026-07-17T20:00:00.000Z",
@@ -545,7 +545,7 @@
545
  "body": "This incident has been resolved.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "minor",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2026-07-16T04:51:26.432Z",
550
  "resolved_inferred": false,
551
  "started_at": "2026-07-16T04:20:09.652Z",
@@ -558,7 +558,7 @@
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "minor",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2026-07-16T04:02:12.215Z",
563
  "resolved_inferred": false,
564
  "started_at": "2026-07-15T23:09:24.996Z",
@@ -571,7 +571,7 @@
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "minor",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2026-07-15T16:25:34.000Z",
576
  "resolved_inferred": false,
577
  "started_at": "2026-07-15T16:00:18.451Z",
@@ -584,7 +584,7 @@
584
  "body": "This incident has been resolved.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2026-07-15T17:15:14.000Z",
589
  "resolved_inferred": false,
590
  "started_at": "2026-07-15T14:52:44.687Z",
@@ -597,7 +597,7 @@
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "minor",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2026-07-15T16:50:58.316Z",
602
  "resolved_inferred": false,
603
  "started_at": "2026-07-15T13:17:30.430Z",
@@ -610,7 +610,7 @@
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2026-07-15T00:52:00.446Z",
615
  "resolved_inferred": false,
616
  "started_at": "2026-07-14T23:48:19.491Z",
@@ -623,7 +623,7 @@
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "minor",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2026-07-13T21:13:22.000Z",
628
  "resolved_inferred": false,
629
  "started_at": "2026-07-13T21:09:02.003Z",
@@ -636,7 +636,7 @@
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2026-07-10T16:01:08.269Z",
641
  "resolved_inferred": false,
642
  "started_at": "2026-07-10T15:16:20.000Z",
@@ -649,7 +649,7 @@
649
  "body": "This incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "none",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2026-07-10T10:00:00.000Z",
654
  "resolved_inferred": false,
655
  "started_at": "2026-07-10T10:00:00.000Z",
 
3
  "slug": "alchemy",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alchemy.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "The incident has been resolved. We are continuing to monitor the situation.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-03T16:54:10.399Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T15:41:24.397Z",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-09-03T03:48:05.000Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-09-03T02:58:55.000Z",
 
38
  "body": "All networks latencies are back to baseline.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-31T15:34:06.077Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-31T14:39:39.846Z",
 
51
  "body": "Incident is resolved and blocks are being produced again - confirmed by Cronost team: https://x.com/CronosNetwork/status/2094417832394301499",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-31T13:38:17.909Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-31T12:15:16.092Z",
 
64
  "body": "The elevated latencies affecting Ethereum Mainnet Data APIs have been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-08-29T19:45:42.275Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-29T18:13:47.000Z",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-08-27T20:47:01.000Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-27T20:05:55.000Z",
 
90
  "body": "This incident has been resolved! WebSocket subscription delivery for X Layer Mainnet in our US East region has returned to normal. HTTP requests were not affected at any point during this incident",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-08-27T23:40:52.297Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-27T16:18:44.574Z",
 
103
  "body": "This incident has been resolved. Between approximately 21:58 UTC and 22:12 UTC, some API requests across multiple networks experienced elevated latency, primarily affecting Token API and Portfolio API balance lookups.\n\nAll services are currently operating normally. We will continue to investigate the underlying cause to prevent recurrence!",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-08-26T22:12:55.000Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-26T21:58:13.000Z",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-08-26T21:59:28.000Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-26T12:30:35.000Z",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-08-25T18:30:50.000Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-25T13:31:17.157Z",
 
142
  "body": "A subset of nodes serving Unichain Mainnet in our US East (use1) region experienced stalled safe/finalized block tracking, causing delayed safe/finalized block data for requests routed through that region. The latest block head and overall API serving were unaffected throughout and no elevated error rates were observed.\n\nWe performed a rolling restart of the affected nodes, which resolved the issue. Safe/finalized data is now current and within normal lag across the region.\n\nThis incident is resolved!",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-08-24T18:37:04.751Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-24T12:23:27.483Z",
 
155
  "body": "Resolved - Elevated latency on BNB Smart Chain Mainnet JSON-RPC requests has been fully mitigated. All methods are performing within normal latency ranges!",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-08-25T14:25:45.249Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-08-23T14:20:30.217Z",
 
168
  "body": "Latency has returned to normal for Robinhood Mainnet. We will continue to monitor the service.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-08-22T22:43:51.868Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-08-22T21:33:48.844Z",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-08-20T01:43:19.879Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-08-20T00:36:00.000Z",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-08-20T16:02:39.853Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-08-19T17:42:17.000Z",
 
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-08-19T06:45:37.051Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-08-19T06:00:37.127Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-08-17T14:30:58.000Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-08-17T14:18:14.530Z",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-08-13T15:41:08.000Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-08-13T14:52:31.670Z",
 
246
  "body": "This incident has been resolved. Injective Mainnet performance has returned to normal.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-08-14T18:00:57.000Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-08-13T11:36:52.594Z",
 
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-08-12T08:03:40.551Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-08-12T04:45:15.286Z",
 
272
  "body": "The issue has been resolved. Solana Mainnet service has recovered in Singapore and Tokyo, and we are monitoring the situation closely.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-08-12T04:44:30.569Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-08-12T04:38:33.206Z",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-08-12T02:33:22.475Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-08-12T01:19:45.000Z",
 
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-08-10T17:11:14.299Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-08-10T12:29:38.657Z",
 
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-08-06T06:12:09.788Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-08-06T06:09:06.830Z",
 
324
  "body": "Between 17:22 and 17:35 UTC on August 5, a subset of eth_getUserOperationReceipt requests across multiple networks experienced increased latencies. This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-08-05T17:45:11.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-08-05T17:45:11.000Z",
 
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-07-31T16:02:32.197Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-07-31T15:08:55.000Z",
 
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-07-31T14:23:36.759Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-07-31T13:19:33.711Z",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-07-31T02:49:50.531Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-07-31T01:07:51.942Z",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-07-30T17:10:12.171Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-07-30T16:04:18.285Z",
 
389
  "body": "Between 22:35 and 22:55 UTC on July 30, a subset of requests on Robinhood Mainnet experienced elevated latency. This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-07-30T21:30:00.000Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-07-30T00:00:00.000Z",
 
402
  "body": "Between 13:30 UTC on July 28 and 08:00 UTC on July 29, HYPERLIQUID\\_MAINNET requests served from us-east experienced elevated latency, and `eth_sendRawTransaction` returned a high rate of errors. Read methods remained available throughout, with elevated response times.\n\n**Impact**\n\nTransaction submission was the primary failure mode. During the peak period, the large majority of `eth_sendRawTransaction` requests either timed out or returned an error, and clients retrying submissions saw sustained failures. Read traffic on the network was slower than normal but continued to be served successfully. Latency was elevated for all HYPERLIQUID\\_MAINNET request types for the duration of the event.\n\n**Root cause**\n\nA majority of our Hyperliquid full nodes in us-east lost peering with the network. The nodes were unable to complete state synchronization handshakes with upstream peers -- connection attempts were rate limited, timed out, or rejected because peer connection slots were full. Affected nodes fell behind and were removed from the healthy serving pool. Recovery required the upstream peer pool to free capacity; feeding new peers into the configuration and pruning node state did not restore peering.\n\nTwo factors extended the impact:\n\n* With that capacity gone, all us-east traffic concentrated on the remaining archive node pool, which pushed latency up further and made `eth_sendRawTransaction` the first method to fail.\n* On Hyperliquid, transactions are not propagated peer-to-peer. They are relayed to a network-level submission endpoint that can rate limit, which means the transaction submission path is sensitive to network conditions independent of which infrastructure serves the request.\n\n**Resolution**\n\nWe began routing `eth_sendRawTransaction` to secondary infra as soon as the issue was identified, but this did not restore transaction submission. Submissions relayed through secondary infra continued to fail at a comparable rate, since that path depends on the same network-level submission endpoint. \n\nA subset of nodes began to recover from around 01:30 UTC on July 29, when the first `hlnode` in us-east returned to a healthy state as upstream peer capacity freed up. Server-side errors from our serving layer dropped off around the same time, though submissions continued to fail through a mix of remaining unhealthy nodes and rejections at the network's submission endpoint. Peering re-established across the rest of the pool over the following hours. Latency returned to normal levels by approximately 08:00 UTC, request volumes and error rates returned to baseline, and all us-east nodes were confirmed healthy shortly afterward.\n\n**Follow-up**\n\nWe are exploring running our own validator and sentry nodes for Hyperliquid so that peering no longer depends on availability in the shared public peer pool.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-07-29T08:00:53.000Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-07-28T14:06:34.423Z",
 
415
  "body": "This is resolved. Base Mainnet's Safe head has caught up and data batching to Ethereum L1 is back to normal. Block production was unaffected throughout. See the Base status page for their full update: https://status.base.org/incidents/j6y12tshwkcg",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-07-28T15:33:18.806Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-07-28T13:26:57.168Z",
 
428
  "body": "Nodes have recovered and services are healthy again.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-07-27T06:51:48.839Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-07-27T03:39:54.079Z",
 
441
  "body": "Nodes have been rescyned with stable binary and services are back to healthy.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-07-24T12:49:32.837Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-07-24T09:36:40.044Z",
 
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-07-24T11:09:57.252Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-07-23T15:12:29.745Z",
 
467
  "body": "This incident has been resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-07-24T12:00:48.517Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-07-23T09:34:15.165Z",
 
480
  "body": "Resolved: All impacted networks, including Mode Sepolia (testnet), have fully recovered and caught up. This incident is now resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-07-22T18:42:07.504Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-07-22T18:07:15.813Z",
 
493
  "body": "Traffic has been fully restored to the US West region. This incident is now resolved!",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "minor",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2026-07-22T21:00:56.000Z",
498
  "resolved_inferred": false,
499
  "started_at": "2026-07-22T15:51:25.000Z",
 
506
  "body": "We have confirmed full recovery across our BNB Smart Chain Mainnet infrastructure. All nodes are healthy and serving traffic normally, with response times and error rates back to baseline. This incident is now resolved. Thank you for your patience!",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "minor",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2026-07-22T14:43:21.230Z",
511
  "resolved_inferred": false,
512
  "started_at": "2026-07-22T07:45:25.000Z",
 
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2026-07-21T22:42:10.724Z",
524
  "resolved_inferred": false,
525
  "started_at": "2026-07-21T20:49:23.000Z",
 
532
  "body": "Between approximately 23:20 UTC on July 17 and 03:30 UTC on July 18, some Polygon Mainnet requests experienced slower than normal response times, mainly for log queries. The issue was limited to the us-east-1 region.\nThe cause was an unusually heavy request load that put pressure on part of our infrastructure in the region. We added extra capacity and rebalanced traffic, after which performance returned to normal.\n\nThe issue is fully resolved. We apologize for the disruption.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2026-07-17T20:00:00.000Z",
537
  "resolved_inferred": false,
538
  "started_at": "2026-07-17T20:00:00.000Z",
 
545
  "body": "This incident has been resolved.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "minor",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2026-07-16T04:51:26.432Z",
550
  "resolved_inferred": false,
551
  "started_at": "2026-07-16T04:20:09.652Z",
 
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "minor",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2026-07-16T04:02:12.215Z",
563
  "resolved_inferred": false,
564
  "started_at": "2026-07-15T23:09:24.996Z",
 
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "minor",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2026-07-15T16:25:34.000Z",
576
  "resolved_inferred": false,
577
  "started_at": "2026-07-15T16:00:18.451Z",
 
584
  "body": "This incident has been resolved.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2026-07-15T17:15:14.000Z",
589
  "resolved_inferred": false,
590
  "started_at": "2026-07-15T14:52:44.687Z",
 
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "minor",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2026-07-15T16:50:58.316Z",
602
  "resolved_inferred": false,
603
  "started_at": "2026-07-15T13:17:30.430Z",
 
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2026-07-15T00:52:00.446Z",
615
  "resolved_inferred": false,
616
  "started_at": "2026-07-14T23:48:19.491Z",
 
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "minor",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2026-07-13T21:13:22.000Z",
628
  "resolved_inferred": false,
629
  "started_at": "2026-07-13T21:09:02.003Z",
 
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2026-07-10T16:01:08.269Z",
641
  "resolved_inferred": false,
642
  "started_at": "2026-07-10T15:16:20.000Z",
 
649
  "body": "This incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "none",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2026-07-10T10:00:00.000Z",
654
  "resolved_inferred": false,
655
  "started_at": "2026-07-10T10:00:00.000Z",
api/v/alert-logic.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "alert-logic",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alertlogic.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "alert-logic",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alertlogic.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/alloy.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "alloy",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alloy.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Between 12:45 PM and 1:20 PM ET on August 27, a third-party data provider Threatmetrix experienced a service disruption that caused intermittent connection errors on device intelligence checks. During this window, some evaluations that use impacted service completed as partial rather than returning a full provider response, and some requests saw elevated latency or connector timeouts.\n\n The provider has confirmed the underlying issue is resolved, and error rates returned to normal by 1:20 PM ET. Evaluations submitted outside this window were not affected.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-27T12:45:00.000-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-27T12:45:00.000-04:00",
@@ -25,7 +25,7 @@
25
  "body": "Issue have been fully resolved. \nElevated error rates were observed on August 25th between 14:18 and 14:22 PM ET and between 14:29 and 14:35 PM ET",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-25T16:39:35.164-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-25T14:45:06.409-04:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-20T16:43:02.408-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-20T11:38:04.913-04:00",
@@ -51,7 +51,7 @@
51
  "body": "The issue affecting the Journeys API has been fully resolved, and service has returned to normal. We have completed monitoring and confirmed that related dashboard functionality has also recovered as of July 21, 2026 at 5:11 PM ET.\n\nThank you for your patience while we worked to restore service.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "major",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-22T11:44:34.905-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-21T13:56:59.694-04:00",
@@ -64,7 +64,7 @@
64
  "body": "We have confirmed that login functionality and Application Queues have returned to normal operation, and no further impact is being observed. Thank you for your patience while we worked to resolve this issue.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-17T10:51:17.535-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-17T10:42:41.291-04:00",
@@ -77,7 +77,7 @@
77
  "body": "We have seen recovery across the impacted LexisNexis services and error rates has returned to expected levels. This incident is now considered resolved.\n\nWe will continue to work with the LexisNexis team to obtain a Root Cause Analysis (RCA). If you would like to receive a copy of the RCA when it becomes available, please contact support@alloy.com.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-07-14T15:09:12.325-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-14T11:31:29.627-04:00",
@@ -90,7 +90,7 @@
90
  "body": "After further montioring, we have not observed any new errors. All systems are operating normally.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-06-18T14:27:52.296-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-18T14:03:29.420-04:00",
@@ -103,7 +103,7 @@
103
  "body": "Service has returned to normal operation as of 3:36 PM ET, and our monitoring confirms that API performance is stable. We will continue to monitor closely to ensure ongoing reliability.\n\nWe apologize for any disruption this may have caused and appreciate your patience while we worked to resolve the issue.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-06-11T15:56:40.841-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-11T15:22:42.273-04:00",
@@ -116,7 +116,7 @@
116
  "body": "Starting at 9:17 AM ET, the homepage analytics dashboards were not loading as expected. All other dashboard pages and services remained fully operational. As of 11:47 AM ET, the system has recovered and is fully operational.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-05-08T09:00:00.000-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-05-08T09:00:00.000-04:00",
@@ -129,7 +129,7 @@
129
  "body": "We believe the cause of the latency is resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-05-07T23:57:46.253-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-07T23:23:46.224-04:00",
@@ -142,7 +142,7 @@
142
  "body": "The issue has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-04-23T11:33:26.193-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-04-23T10:25:59.879-04:00",
@@ -155,7 +155,7 @@
155
  "body": "We recently identified and resolved an issue affecting some plugins initialized through the Alloy SDK.\n\nFor a subset of SDK Plugins, applications initializing the SDK may have experienced unexpected behavior, which could present as UI instability or premature close events.\n\nWe mitigated the issue by rolling back a recent SDK change. Following the rollback, normal plugin behavior was restored.\n\nIf you continue to experience any issues, please contact Alloy Support.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-03-05T11:00:00.000-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-03-05T11:00:00.000-05:00",
@@ -168,7 +168,7 @@
168
  "body": "Between March 4 at 11:00 PM ET and March 5 at 10:07 AM ET, we experienced an elevated rate of memory-related errors impacting evaluations running through JQ input attributes. As a result, some evaluations returned a null value for the input attribute instead of the correct value, potentially interrupting decisioning in the Workflow. Impacted applications would need to be re-run.\n\nOnly workflows using input attributes with JQ were impacted; other Workflow logic was not impacted.\n\nThe issue has been identified and resolved, and all systems are now operating normally.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-03-04T23:00:00.000-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-03-04T23:00:00.000-05:00",
@@ -181,7 +181,7 @@
181
  "body": "API functionality has been fully restored. We are continuing to investigate the impact and look into root causes.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-02-24T05:00:46.000-05:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-02-24T04:30:57.000-05:00",
@@ -194,7 +194,7 @@
194
  "body": "Realtime webhook processing has been fully restored, and has maintained stability after monitoring. All new webhook events are now completing in realtime as expected. To further strengthen system stability, the engineering team has deployed an additional mitigation to prevent webhook queue backlogging under similar spike conditions.\n\nA thorough postmortem will be completed a Root Cause Analysis (RCA) can be shared with customers - please email support@alloy.com if you would like to receive the RCA. We are also investing in further improvements to the reliability and resiliency of our webhook queueing mechanism in the future to prevent event loss in the future.\n\nPlease note, action is required to ensure applications process: \n\nDuring the incident, webhook events generated between 2:24 PM - 4:38 PM ET and 5:42 - 5:45 ET were not successfully processed and were permanently lost. Webhooks generated outside of this time window were not impacted.\n\nThis issue affects applications that are stuck at a Journey step dependent on an Alloy webhook response to proceed (for example, action nodes), as well as applications that completed with a Manual Review outcome but are not reflecting back in core after review.\n\nApplications submitted during the affected window that are currently blocked due to a missing webhook dependency will need to be replayed. We recommend resubmitting those applications via API. Re-running an application will leverage cached data by default and will not trigger new calls to external data vendors.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-02-19T20:03:39.360-05:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-02-19T15:49:29.100-05:00",
@@ -207,7 +207,7 @@
207
  "body": "The root cause has been identified. Response times for the Dashboard and API have returned to normal levels since 3:46 PM ET.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-02-17T16:14:54.188-05:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-02-17T16:03:36.091-05:00",
@@ -220,7 +220,7 @@
220
  "body": "Between 11:20 AM and 12:04 PM ET, some workflows returned a 500 error when attempting to save a new version. Existing workflow versions and decisioning on existing workflow versions were not impacted. Once the root cause was identified as a previous code change, the issue was resolved at 12:04 PM ET when the affected change was rolled back, and all functionality related to workflow version saving was fully restored.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-02-02T12:27:00.937-05:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-02-02T12:27:00.881-05:00",
@@ -233,7 +233,7 @@
233
  "body": "A fix has been implemented and all systems are operational.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-01-08T16:30:45.000-05:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-01-08T13:43:22.813-05:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-01-02T17:05:14.450-05:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-01-02T16:15:10.000-05:00",
@@ -259,7 +259,7 @@
259
  "body": "The OpenCorporates team has assisted in resolving the issue, and the OpenCorporates data service is now fully operational. Any applications that previously failed due to this incident can now be re-run.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2025-12-03T17:51:47.886-05:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-12-03T13:37:29.290-05:00",
@@ -272,7 +272,7 @@
272
  "body": "Alloy is observing error rates have decreased across all impacted services as of 9:36 AM ET. \n\nCloudFlare has confirmed a fix has been implemented as of 9:42 AM ET. More information about the CloudFlare outage can be found here: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "none",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2025-11-18T10:08:01.367-05:00",
277
  "resolved_inferred": false,
278
  "started_at": "2025-11-18T08:37:50.652-05:00",
@@ -285,7 +285,7 @@
285
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any further errors since 12:20 PM ET. Any applications that failed during this period can now be re-run successfully.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2025-11-03T12:20:45.000-05:00",
290
  "resolved_inferred": false,
291
  "started_at": "2025-11-03T12:06:51.937-05:00",
@@ -298,7 +298,7 @@
298
  "body": "As of 11:44 PM ET, the webhook backlog has been fully processed, and real-time webhook processing has been restored.\n\nAll major Alloy services are now fully operational, with performance metrics and latency levels remaining stable.\n\nOur teams continue to work closely with AWS and the third-party vendor to complete a comprehensive post-mortem. We will share a Root Cause Analysis (RCA) once that review is finalized. If you\u2019d like to receive the RCA once it's available, please email support@alloy.com\n.\nWe appreciate your patience and understanding throughout this incident.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "critical",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2025-10-20T23:52:17.301-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-10-20T03:15:20.691-04:00",
@@ -311,7 +311,7 @@
311
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 6:02 PM ET. Any applications that failed during this period can now be re-run successfully.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2025-10-17T18:19:51.869-04:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-10-17T18:07:00.973-04:00",
@@ -324,7 +324,7 @@
324
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any further errors since 7:01 PM ET. Any applications that failed during this period can now be re-run successfully.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2025-10-17T19:09:49.153-04:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-10-17T15:44:22.446-04:00",
@@ -337,7 +337,7 @@
337
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 4:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2025-10-08T17:40:59.204-04:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-10-08T16:12:52.000-04:00",
@@ -350,7 +350,7 @@
350
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 4:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2025-10-08T17:41:07.520-04:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-10-08T16:12:33.620-04:00",
@@ -363,7 +363,7 @@
363
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 4:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2025-10-08T17:41:14.619-04:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-10-08T16:11:40.907-04:00",
@@ -376,7 +376,7 @@
376
  "body": "Our SMS vendor has confirmed that around 11:43 AM ET, there were SMS delivery delays when sending messages To T-mobile Network in the USA. They are now observing recovery when sending SMS messages over T-mobile and we\u2019ve received confirmed reports from customers as well.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-09-29T14:16:31.846-04:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-09-29T13:40:09.133-04:00",
@@ -389,7 +389,7 @@
389
  "body": "We have detected that calls to Qualifile were failing from 12:01AM ET due to a Qualifile maintenance window. We are monitoring to determine when their system is back up.\n\nWe have confirmed that Qualifile processing has returned to normal. We have not observed any timeout errors since 2:03 PM ET. Any applications that failed during this period can now be re-run successfully.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-09-21T00:00:00.000-04:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-09-21T00:00:00.000-04:00",
@@ -402,7 +402,7 @@
402
  "body": "We are resolving this incident after affected customers confirmed that updating their allowlisted domain .*alloy.com in their security vendor restored dashboard access. The issue was limited to customers who control Alloy dashboard access via Allowlisted IPs and use a security vendor that routes traffic over dedicated IPs based on domain.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-09-20T12:32:04.184-04:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-09-19T14:13:44.640-04:00",
@@ -415,7 +415,7 @@
415
  "body": "We\u2019ve resolved the issue that was causing the 403 errors, and our systems have returned to normal operations. Thank you for your patience while we worked to address this.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-09-10T15:49:56.717-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-09-10T14:55:42.938-04:00",
@@ -428,7 +428,7 @@
428
  "body": "Our monitoring confirms that Iovation processing has returned to normal. We have not observed any timeout errors since 3:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-08-21T17:08:37.508-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-08-21T14:36:54.000-04:00",
@@ -441,7 +441,7 @@
441
  "body": "Between 10:37 AM ET and 12:12 PM ET, requests to ComplyAdvantage had a 206 error, causing evaluations running this service to fail. We identified the root cause and deployed a fix. The issue has been resolved, and evaluations can now be rerun.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "none",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-08-20T10:37:00.000-04:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-08-20T10:37:00.000-04:00",
@@ -454,7 +454,7 @@
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "major",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-08-13T18:17:30.713-04:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-08-13T18:02:47.906-04:00",
@@ -467,7 +467,7 @@
467
  "body": "Iovation failures resolved at 9:52 AM EDT. Any applications that failed during this time can be re-run.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-08-08T10:16:49.000-04:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-08-08T09:55:22.000-04:00",
@@ -480,7 +480,7 @@
480
  "body": "An interprocess communication issue resulted in a period of increased API latency and downtime from 12:28 to 12:44 ET (16 minutes). We have remediated the underlying issue and are working on an RCA of the incident now.\n\nAPI issues during this time will appear as either increased latency and/or HTTP 206 response codes. All API requests are retryable and can be retried now.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-08-05T12:48:02.000-04:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-08-05T12:37:40.946-04:00",
 
3
  "slug": "alloy",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alloy.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Between 12:45 PM and 1:20 PM ET on August 27, a third-party data provider Threatmetrix experienced a service disruption that caused intermittent connection errors on device intelligence checks. During this window, some evaluations that use impacted service completed as partial rather than returning a full provider response, and some requests saw elevated latency or connector timeouts.\n\n The provider has confirmed the underlying issue is resolved, and error rates returned to normal by 1:20 PM ET. Evaluations submitted outside this window were not affected.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-27T12:45:00.000-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-27T12:45:00.000-04:00",
 
25
  "body": "Issue have been fully resolved. \nElevated error rates were observed on August 25th between 14:18 and 14:22 PM ET and between 14:29 and 14:35 PM ET",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-25T16:39:35.164-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-25T14:45:06.409-04:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-20T16:43:02.408-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-20T11:38:04.913-04:00",
 
51
  "body": "The issue affecting the Journeys API has been fully resolved, and service has returned to normal. We have completed monitoring and confirmed that related dashboard functionality has also recovered as of July 21, 2026 at 5:11 PM ET.\n\nThank you for your patience while we worked to restore service.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "major",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-22T11:44:34.905-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-21T13:56:59.694-04:00",
 
64
  "body": "We have confirmed that login functionality and Application Queues have returned to normal operation, and no further impact is being observed. Thank you for your patience while we worked to resolve this issue.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-17T10:51:17.535-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-17T10:42:41.291-04:00",
 
77
  "body": "We have seen recovery across the impacted LexisNexis services and error rates has returned to expected levels. This incident is now considered resolved.\n\nWe will continue to work with the LexisNexis team to obtain a Root Cause Analysis (RCA). If you would like to receive a copy of the RCA when it becomes available, please contact support@alloy.com.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-07-14T15:09:12.325-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-14T11:31:29.627-04:00",
 
90
  "body": "After further montioring, we have not observed any new errors. All systems are operating normally.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-06-18T14:27:52.296-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-18T14:03:29.420-04:00",
 
103
  "body": "Service has returned to normal operation as of 3:36 PM ET, and our monitoring confirms that API performance is stable. We will continue to monitor closely to ensure ongoing reliability.\n\nWe apologize for any disruption this may have caused and appreciate your patience while we worked to resolve the issue.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-06-11T15:56:40.841-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-06-11T15:22:42.273-04:00",
 
116
  "body": "Starting at 9:17 AM ET, the homepage analytics dashboards were not loading as expected. All other dashboard pages and services remained fully operational. As of 11:47 AM ET, the system has recovered and is fully operational.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-05-08T09:00:00.000-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-05-08T09:00:00.000-04:00",
 
129
  "body": "We believe the cause of the latency is resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-05-07T23:57:46.253-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-07T23:23:46.224-04:00",
 
142
  "body": "The issue has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-04-23T11:33:26.193-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-04-23T10:25:59.879-04:00",
 
155
  "body": "We recently identified and resolved an issue affecting some plugins initialized through the Alloy SDK.\n\nFor a subset of SDK Plugins, applications initializing the SDK may have experienced unexpected behavior, which could present as UI instability or premature close events.\n\nWe mitigated the issue by rolling back a recent SDK change. Following the rollback, normal plugin behavior was restored.\n\nIf you continue to experience any issues, please contact Alloy Support.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-03-05T11:00:00.000-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-03-05T11:00:00.000-05:00",
 
168
  "body": "Between March 4 at 11:00 PM ET and March 5 at 10:07 AM ET, we experienced an elevated rate of memory-related errors impacting evaluations running through JQ input attributes. As a result, some evaluations returned a null value for the input attribute instead of the correct value, potentially interrupting decisioning in the Workflow. Impacted applications would need to be re-run.\n\nOnly workflows using input attributes with JQ were impacted; other Workflow logic was not impacted.\n\nThe issue has been identified and resolved, and all systems are now operating normally.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-03-04T23:00:00.000-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-03-04T23:00:00.000-05:00",
 
181
  "body": "API functionality has been fully restored. We are continuing to investigate the impact and look into root causes.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-02-24T05:00:46.000-05:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-02-24T04:30:57.000-05:00",
 
194
  "body": "Realtime webhook processing has been fully restored, and has maintained stability after monitoring. All new webhook events are now completing in realtime as expected. To further strengthen system stability, the engineering team has deployed an additional mitigation to prevent webhook queue backlogging under similar spike conditions.\n\nA thorough postmortem will be completed a Root Cause Analysis (RCA) can be shared with customers - please email support@alloy.com if you would like to receive the RCA. We are also investing in further improvements to the reliability and resiliency of our webhook queueing mechanism in the future to prevent event loss in the future.\n\nPlease note, action is required to ensure applications process: \n\nDuring the incident, webhook events generated between 2:24 PM - 4:38 PM ET and 5:42 - 5:45 ET were not successfully processed and were permanently lost. Webhooks generated outside of this time window were not impacted.\n\nThis issue affects applications that are stuck at a Journey step dependent on an Alloy webhook response to proceed (for example, action nodes), as well as applications that completed with a Manual Review outcome but are not reflecting back in core after review.\n\nApplications submitted during the affected window that are currently blocked due to a missing webhook dependency will need to be replayed. We recommend resubmitting those applications via API. Re-running an application will leverage cached data by default and will not trigger new calls to external data vendors.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-02-19T20:03:39.360-05:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-02-19T15:49:29.100-05:00",
 
207
  "body": "The root cause has been identified. Response times for the Dashboard and API have returned to normal levels since 3:46 PM ET.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-02-17T16:14:54.188-05:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-02-17T16:03:36.091-05:00",
 
220
  "body": "Between 11:20 AM and 12:04 PM ET, some workflows returned a 500 error when attempting to save a new version. Existing workflow versions and decisioning on existing workflow versions were not impacted. Once the root cause was identified as a previous code change, the issue was resolved at 12:04 PM ET when the affected change was rolled back, and all functionality related to workflow version saving was fully restored.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-02-02T12:27:00.937-05:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-02-02T12:27:00.881-05:00",
 
233
  "body": "A fix has been implemented and all systems are operational.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-01-08T16:30:45.000-05:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-01-08T13:43:22.813-05:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-01-02T17:05:14.450-05:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-01-02T16:15:10.000-05:00",
 
259
  "body": "The OpenCorporates team has assisted in resolving the issue, and the OpenCorporates data service is now fully operational. Any applications that previously failed due to this incident can now be re-run.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2025-12-03T17:51:47.886-05:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-12-03T13:37:29.290-05:00",
 
272
  "body": "Alloy is observing error rates have decreased across all impacted services as of 9:36 AM ET. \n\nCloudFlare has confirmed a fix has been implemented as of 9:42 AM ET. More information about the CloudFlare outage can be found here: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "none",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2025-11-18T10:08:01.367-05:00",
277
  "resolved_inferred": false,
278
  "started_at": "2025-11-18T08:37:50.652-05:00",
 
285
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any further errors since 12:20 PM ET. Any applications that failed during this period can now be re-run successfully.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2025-11-03T12:20:45.000-05:00",
290
  "resolved_inferred": false,
291
  "started_at": "2025-11-03T12:06:51.937-05:00",
 
298
  "body": "As of 11:44 PM ET, the webhook backlog has been fully processed, and real-time webhook processing has been restored.\n\nAll major Alloy services are now fully operational, with performance metrics and latency levels remaining stable.\n\nOur teams continue to work closely with AWS and the third-party vendor to complete a comprehensive post-mortem. We will share a Root Cause Analysis (RCA) once that review is finalized. If you\u2019d like to receive the RCA once it's available, please email support@alloy.com\n.\nWe appreciate your patience and understanding throughout this incident.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "critical",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2025-10-20T23:52:17.301-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-10-20T03:15:20.691-04:00",
 
311
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 6:02 PM ET. Any applications that failed during this period can now be re-run successfully.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2025-10-17T18:19:51.869-04:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-10-17T18:07:00.973-04:00",
 
324
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any further errors since 7:01 PM ET. Any applications that failed during this period can now be re-run successfully.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2025-10-17T19:09:49.153-04:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-10-17T15:44:22.446-04:00",
 
337
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 4:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2025-10-08T17:40:59.204-04:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-10-08T16:12:52.000-04:00",
 
350
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 4:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2025-10-08T17:41:07.520-04:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-10-08T16:12:33.620-04:00",
 
363
  "body": "Our monitoring confirms that processing has returned to normal. We have not observed any timeout errors since 4:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2025-10-08T17:41:14.619-04:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-10-08T16:11:40.907-04:00",
 
376
  "body": "Our SMS vendor has confirmed that around 11:43 AM ET, there were SMS delivery delays when sending messages To T-mobile Network in the USA. They are now observing recovery when sending SMS messages over T-mobile and we\u2019ve received confirmed reports from customers as well.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-09-29T14:16:31.846-04:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-09-29T13:40:09.133-04:00",
 
389
  "body": "We have detected that calls to Qualifile were failing from 12:01AM ET due to a Qualifile maintenance window. We are monitoring to determine when their system is back up.\n\nWe have confirmed that Qualifile processing has returned to normal. We have not observed any timeout errors since 2:03 PM ET. Any applications that failed during this period can now be re-run successfully.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-09-21T00:00:00.000-04:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-09-21T00:00:00.000-04:00",
 
402
  "body": "We are resolving this incident after affected customers confirmed that updating their allowlisted domain .*alloy.com in their security vendor restored dashboard access. The issue was limited to customers who control Alloy dashboard access via Allowlisted IPs and use a security vendor that routes traffic over dedicated IPs based on domain.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-09-20T12:32:04.184-04:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-09-19T14:13:44.640-04:00",
 
415
  "body": "We\u2019ve resolved the issue that was causing the 403 errors, and our systems have returned to normal operations. Thank you for your patience while we worked to address this.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-09-10T15:49:56.717-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-09-10T14:55:42.938-04:00",
 
428
  "body": "Our monitoring confirms that Iovation processing has returned to normal. We have not observed any timeout errors since 3:46 PM ET. Any applications that failed during this period can now be re-run successfully.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-08-21T17:08:37.508-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-08-21T14:36:54.000-04:00",
 
441
  "body": "Between 10:37 AM ET and 12:12 PM ET, requests to ComplyAdvantage had a 206 error, causing evaluations running this service to fail. We identified the root cause and deployed a fix. The issue has been resolved, and evaluations can now be rerun.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "none",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-08-20T10:37:00.000-04:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-08-20T10:37:00.000-04:00",
 
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "major",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-08-13T18:17:30.713-04:00",
459
  "resolved_inferred": false,
460
  "started_at": "2025-08-13T18:02:47.906-04:00",
 
467
  "body": "Iovation failures resolved at 9:52 AM EDT. Any applications that failed during this time can be re-run.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-08-08T10:16:49.000-04:00",
472
  "resolved_inferred": false,
473
  "started_at": "2025-08-08T09:55:22.000-04:00",
 
480
  "body": "An interprocess communication issue resulted in a period of increased API latency and downtime from 12:28 to 12:44 ET (16 minutes). We have remediated the underlying issue and are working on an RCA of the incident now.\n\nAPI issues during this time will appear as either increased latency and/or HTTP 206 response codes. All API requests are retryable and can be retried now.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-08-05T12:48:02.000-04:00",
485
  "resolved_inferred": false,
486
  "started_at": "2025-08-05T12:37:40.946-04:00",
api/v/alphavps.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "alphavps",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alphavps.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-21T14:11:04.516+03:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-30T15:50:58.316+03:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-07-09T06:44:11.606+03:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-06-29T21:42:41.066+03:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-06-30T03:51:51.404+03:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-05-27T15:56:03.738+03:00",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-06-30T03:52:06.994+03:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-07T12:31:31.976+03:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2025-09-26T22:02:26.000+03:00",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-23T01:05:32.423+03:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-09-04T08:26:59.471+03:00",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-04T08:13:28.541+03:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-09-03T10:33:23.988+03:00",
95
  "resolved_inferred": false,
96
  "started_at": "2025-09-03T08:09:55.024+03:00",
 
3
  "slug": "alphavps",
4
  "platform": "statuspage",
5
  "status_url": "https://status.alphavps.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-21T14:11:04.516+03:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-30T15:50:58.316+03:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-07-09T06:44:11.606+03:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-06-29T21:42:41.066+03:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-06-30T03:51:51.404+03:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-05-27T15:56:03.738+03:00",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-06-30T03:52:06.994+03:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-07T12:31:31.976+03:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2025-09-26T22:02:26.000+03:00",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-23T01:05:32.423+03:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-09-04T08:26:59.471+03:00",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-04T08:13:28.541+03:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-09-03T10:33:23.988+03:00",
95
  "resolved_inferred": false,
96
  "started_at": "2025-09-03T08:09:55.024+03:00",
api/v/amplitude.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "amplitude",
4
  "platform": "statuspage",
5
  "status_url": "https://status.amplitude.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-26T11:38:27.211-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-26T08:23:56.873-07:00",
@@ -25,7 +25,7 @@
25
  "body": "Incident timeline\n\nResolved \u2014 Amplitude is accessible once again, and customers should be able to access the platform as expected.\n\nPosted Aug 25, 2026 - 14:03 PT\n\nInvestigating \u2014 Since approximately 13:48 PT, some customers may have experienced a brief interruption when using Amplitude.\n\nPosted Aug 25, 2026 - 13:48 PT\n\nWe apologize for the disruption.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-25T13:48:00.000-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-25T13:48:00.000-07:00",
@@ -38,7 +38,7 @@
38
  "body": "A fix was deployed, and the issue was fully resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-24T20:23:01.519-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-24T19:06:37.620-07:00",
@@ -51,7 +51,7 @@
51
  "body": "On 2026-08-19 at 10:41:25 AM PT, some customers who had not explicitly enabled AI through the AI Controls page were placed in \u201cAdmin preview,\u201d and non-admin users could not access AI features. The issue was fully resolved at 12:41 PM PT on 2026-08-19. No data was impacted, and no customer action is required. Following the fix, customers should now be able to access Global Chat and see the Global Chat interface instead of the \u201cNo access\u201d message.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-19T10:41:00.000-07:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-19T10:41:00.000-07:00",
@@ -64,7 +64,7 @@
64
  "body": "On 2026-08-13 at 7:45 PM PT (2:45 AM UTC on 2026-08-14), we experienced a data ingestion latency. The issue was fully resolved at 8:35 PM PT (3:35 AM UTC on 2026-08-14), and all data has since been recovered. There was no data loss, and no customer action is required.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-08-13T19:30:00.000-07:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-13T19:30:00.000-07:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-08-12T20:45:54.905-07:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-12T16:39:08.000-07:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-08-01T23:12:43.160-07:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-01T22:45:46.343-07:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-31T20:51:59.748-07:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-31T19:07:20.532-07:00",
@@ -116,7 +116,7 @@
116
  "body": "Between approximately 2026-07-24 03:39\u201305:00 PT (10:39\u201312:00 UTC), some customers may have experienced intermittent connectivity issues while accessing Amplitude or sending data, including connection timeouts. This was caused by an AWS networking disruption in the us-west-2 region affecting multiple upstream AWS services.\n\nThe issue originated outside of Amplitude's infrastructure and was resolved by AWS.\n\nServices:\n- Our SDKs queue undelivered events on-device and automatically retry sending them, so we expect minimal to no data loss from this incident. No ingested data was lost and no action is required.\n- Experiment/Flag evaluations failed and return 503s due to service unavailability. There is no data loss.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-07-24T10:05:39.000-07:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-24T10:05:39.000-07:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-07-24T08:59:35.307-07:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-07-24T07:45:28.683-07:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-07-23T10:03:42.394-07:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-07-23T07:35:43.063-07:00",
@@ -155,7 +155,7 @@
155
  "body": "We identified the source of the issue and rolled back the responsible change at 12:06 PM PT (19:06 UTC). Error rates have returned to normal, and we are actively monitoring to confirm full stability.\n\nThere is no data loss. No customer action is needed at this time.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-07-22T13:20:59.156-07:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-07-22T13:20:59.109-07:00",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-07-13T16:07:58.791-07:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-13T14:31:53.771-07:00",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-07-13T16:17:08.997-07:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-13T11:51:09.422-07:00",
@@ -194,7 +194,7 @@
194
  "body": "The incident has been resolved and the Custom Metrics metrics details page displays normally now.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-07-13T07:59:40.179-07:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-13T04:41:59.470-07:00",
@@ -207,7 +207,7 @@
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-07-13T01:39:10.911-07:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-12T23:15:43.000-07:00",
@@ -220,7 +220,7 @@
220
  "body": "This incident is resolved. Shared embeds and public links have been stable since 1:50 AM PT (08:50 UTC), and we have verified affected links render normally. A permanent fix ships later today. No data was lost and no customer action is needed.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "major",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-07-09T02:45:56.400-07:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-07-09T02:12:47.316-07:00",
@@ -233,7 +233,7 @@
233
  "body": "All systems are caught up and functioning normally.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "none",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-07-05T12:11:06.588-07:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-07-05T08:56:16.586-07:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-06-18T21:30:56.080-07:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-06-18T12:29:15.000-07:00",
@@ -259,7 +259,7 @@
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-06-04T16:05:35.687-07:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-06-04T11:55:08.000-07:00",
@@ -272,7 +272,7 @@
272
  "body": "Service has been restored for the Amplitude application, and users should now be able to access the application normally.\n\nWe have implemented a fix and are monitoring the system to ensure continued stability. We do not expect any data loss at this time.\n\nThank you for your patience.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "critical",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-06-03T06:26:38.443-07:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-06-03T06:13:13.489-07:00",
@@ -285,7 +285,7 @@
285
  "body": "We have resolved the issue affecting the Amplitude application, and services are operating normally again.\n\nWe do not expect any data loss as a result of this incident. Our team will continue to monitor the system to ensure stability.\n\nThank you for your patience.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "critical",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-06-03T05:52:37.689-07:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-06-03T05:25:01.137-07:00",
@@ -298,7 +298,7 @@
298
  "body": "The issue causing elevated application latency has been resolved. We have confirmed that system performance has returned to normal levels and continue to monitor closely to ensure ongoing stability.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-05-21T23:32:06.945-07:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-05-21T19:51:02.241-07:00",
@@ -311,7 +311,7 @@
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-05-19T06:02:42.792-07:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-05-19T05:45:51.777-07:00",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-05-14T19:03:53.426-07:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-05-14T14:42:22.022-07:00",
@@ -337,7 +337,7 @@
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-05-05T12:44:54.338-07:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-05-05T12:13:50.213-07:00",
@@ -350,7 +350,7 @@
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-04-29T07:33:06.509-07:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-04-29T01:15:23.000-07:00",
@@ -363,7 +363,7 @@
363
  "body": "The Amplitude web application in the US was briefly inaccessible. We identified the issue to be related to a misconfigured feature flag. The issue started at 10:00 AM PST, lasting 10 minutes, and is now resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-04-28T10:00:00.000-07:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-04-28T10:00:00.000-07:00",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-04-23T13:32:07.743-07:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-04-23T12:56:18.227-07:00",
@@ -389,7 +389,7 @@
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-04-15T18:11:53.438-07:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-04-15T16:09:27.612-07:00",
@@ -402,7 +402,7 @@
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "none",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-04-13T14:00:56.162-07:00",
407
  "resolved_inferred": false,
408
  "started_at": "2026-04-13T08:45:16.000-07:00",
@@ -415,7 +415,7 @@
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "critical",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-04-12T03:52:44.330-07:00",
420
  "resolved_inferred": false,
421
  "started_at": "2026-04-12T01:24:36.041-07:00",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2026-04-06T17:48:17.296-07:00",
433
  "resolved_inferred": false,
434
  "started_at": "2026-04-06T12:53:19.789-07:00",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "critical",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2026-04-03T16:52:18.005-07:00",
446
  "resolved_inferred": false,
447
  "started_at": "2026-04-03T14:52:01.000-07:00",
@@ -454,7 +454,7 @@
454
  "body": "We have fixed the issue",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "critical",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2026-03-27T10:11:41.283-07:00",
459
  "resolved_inferred": false,
460
  "started_at": "2026-03-27T08:52:20.381-07:00",
@@ -467,7 +467,7 @@
467
  "body": "Some Flags and experiments that were targeting cohorts did not evaluate users into control and treatment correctly. This has been fixed",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "none",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2026-03-26T20:00:00.000-07:00",
472
  "resolved_inferred": false,
473
  "started_at": "2026-03-26T17:00:00.000-07:00",
@@ -480,7 +480,7 @@
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2026-03-25T11:09:09.739-07:00",
485
  "resolved_inferred": false,
486
  "started_at": "2026-03-25T11:00:50.187-07:00",
@@ -493,7 +493,7 @@
493
  "body": "This incident has been resolved.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2026-03-20T13:00:11.935-07:00",
498
  "resolved_inferred": false,
499
  "started_at": "2026-03-20T10:31:36.152-07:00",
@@ -506,7 +506,7 @@
506
  "body": "Duration: March 16, 2026, 11:20 AM PT to 1:17 PM PT\n\nBetween 11:20 AM PT and 1:17 PM PT, the Experiment Evaluation Service experienced a partial outage, resulting in elevated 500, 502, and 503 errors for some requests. Our team has successfully resolved the issue, and the service is now operating normally. We apologize for any inconvenience this disruption may have caused.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "none",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2026-03-16T13:55:39.780-07:00",
511
  "resolved_inferred": false,
512
  "started_at": "2026-03-16T13:55:39.724-07:00",
@@ -519,7 +519,7 @@
519
  "body": "Between 2026-03-16 08:57 AM PT (15:57 UTC) and 09:23 AM PT (16:23 UTC), some Amplitude users experienced intermittent 500 errors when loading charts, dashboards, and reports in Analytics and Experiment.\n\nA second brief interruption occurred at approximately 09:49 AM PT (16:49 UTC), during which some requests again returned 500 errors.\n\nThe issue was caused by a temporary database disruption that has since automatically recovered. Our team has confirmed that services are operating normally. No data loss occurred, and no customer action is needed.\n\nWe are actively investigating the root cause to prevent recurrence and will continue to monitor the system.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2026-03-16T09:00:00.000-07:00",
524
  "resolved_inferred": false,
525
  "started_at": "2026-03-16T09:00:00.000-07:00",
@@ -532,7 +532,7 @@
532
  "body": "A migration to transition some Growth orgs to a new permission system, which is activated by a feature flag, did not operate correctly, resulting in the appearance of lost role assignments for users. This affected some Growth orgs that have project-based permissions. Removing the feature flag for these orgs reverted them to the old permission system, restoring all role assignments correctly.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2026-03-10T09:00:00.000-07:00",
537
  "resolved_inferred": false,
538
  "started_at": "2026-03-10T09:00:00.000-07:00",
@@ -545,7 +545,7 @@
545
  "body": "This incident has been resolved.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2026-03-02T20:46:37.680-08:00",
550
  "resolved_inferred": false,
551
  "started_at": "2026-03-02T18:53:37.824-08:00",
@@ -558,7 +558,7 @@
558
  "body": "As of 3:10 PM PT, we have fully recovered and all systems are operating normally.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2026-02-27T15:47:57.347-08:00",
563
  "resolved_inferred": false,
564
  "started_at": "2026-02-27T14:22:46.000-08:00",
@@ -571,7 +571,7 @@
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "major",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2026-02-26T14:58:51.003-08:00",
576
  "resolved_inferred": false,
577
  "started_at": "2026-02-26T12:48:20.886-08:00",
@@ -584,7 +584,7 @@
584
  "body": "This incident has been resolved. The bug was isolated to a permissions issue with Amplitude users and did not impact any data ingestion, experiments, or other features. All user permissions should be back to operational.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "major",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2026-02-12T15:49:32.919-08:00",
589
  "resolved_inferred": false,
590
  "started_at": "2026-02-12T15:19:05.168-08:00",
@@ -597,7 +597,7 @@
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "minor",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2026-01-20T19:07:13.727-08:00",
602
  "resolved_inferred": false,
603
  "started_at": "2026-01-20T12:05:34.000-08:00",
@@ -610,7 +610,7 @@
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2026-01-08T09:17:41.960-08:00",
615
  "resolved_inferred": false,
616
  "started_at": "2026-01-08T06:07:32.961-08:00",
@@ -623,7 +623,7 @@
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "critical",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2025-12-10T00:46:00.275-08:00",
628
  "resolved_inferred": false,
629
  "started_at": "2025-12-09T19:40:30.695-08:00",
@@ -636,7 +636,7 @@
636
  "body": "As of Nov 22, 2025 14:00 UTC, this incident is resolved and customers should be able to see all historical data. Please reach out to support if you're still seeing gaps in your historical data.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2025-11-22T09:07:04.218-08:00",
641
  "resolved_inferred": false,
642
  "started_at": "2025-11-21T15:40:16.877-08:00",
@@ -649,7 +649,7 @@
649
  "body": "Amplitude's user interface and data ingestion were not impacted by the recent Cloudflare outage. However, your downstream destinations may have been impacted and we recommend checking with your vendor's status page to confirm impact.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "none",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2025-11-17T03:30:00.000-08:00",
654
  "resolved_inferred": false,
655
  "started_at": "2025-11-17T03:30:00.000-08:00",
 
3
  "slug": "amplitude",
4
  "platform": "statuspage",
5
  "status_url": "https://status.amplitude.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-26T11:38:27.211-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-26T08:23:56.873-07:00",
 
25
  "body": "Incident timeline\n\nResolved \u2014 Amplitude is accessible once again, and customers should be able to access the platform as expected.\n\nPosted Aug 25, 2026 - 14:03 PT\n\nInvestigating \u2014 Since approximately 13:48 PT, some customers may have experienced a brief interruption when using Amplitude.\n\nPosted Aug 25, 2026 - 13:48 PT\n\nWe apologize for the disruption.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-25T13:48:00.000-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-25T13:48:00.000-07:00",
 
38
  "body": "A fix was deployed, and the issue was fully resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-24T20:23:01.519-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-24T19:06:37.620-07:00",
 
51
  "body": "On 2026-08-19 at 10:41:25 AM PT, some customers who had not explicitly enabled AI through the AI Controls page were placed in \u201cAdmin preview,\u201d and non-admin users could not access AI features. The issue was fully resolved at 12:41 PM PT on 2026-08-19. No data was impacted, and no customer action is required. Following the fix, customers should now be able to access Global Chat and see the Global Chat interface instead of the \u201cNo access\u201d message.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-19T10:41:00.000-07:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-19T10:41:00.000-07:00",
 
64
  "body": "On 2026-08-13 at 7:45 PM PT (2:45 AM UTC on 2026-08-14), we experienced a data ingestion latency. The issue was fully resolved at 8:35 PM PT (3:35 AM UTC on 2026-08-14), and all data has since been recovered. There was no data loss, and no customer action is required.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-08-13T19:30:00.000-07:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-13T19:30:00.000-07:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-08-12T20:45:54.905-07:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-12T16:39:08.000-07:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-08-01T23:12:43.160-07:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-01T22:45:46.343-07:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-31T20:51:59.748-07:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-31T19:07:20.532-07:00",
 
116
  "body": "Between approximately 2026-07-24 03:39\u201305:00 PT (10:39\u201312:00 UTC), some customers may have experienced intermittent connectivity issues while accessing Amplitude or sending data, including connection timeouts. This was caused by an AWS networking disruption in the us-west-2 region affecting multiple upstream AWS services.\n\nThe issue originated outside of Amplitude's infrastructure and was resolved by AWS.\n\nServices:\n- Our SDKs queue undelivered events on-device and automatically retry sending them, so we expect minimal to no data loss from this incident. No ingested data was lost and no action is required.\n- Experiment/Flag evaluations failed and return 503s due to service unavailability. There is no data loss.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-07-24T10:05:39.000-07:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-24T10:05:39.000-07:00",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-07-24T08:59:35.307-07:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-07-24T07:45:28.683-07:00",
 
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-07-23T10:03:42.394-07:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-07-23T07:35:43.063-07:00",
 
155
  "body": "We identified the source of the issue and rolled back the responsible change at 12:06 PM PT (19:06 UTC). Error rates have returned to normal, and we are actively monitoring to confirm full stability.\n\nThere is no data loss. No customer action is needed at this time.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-07-22T13:20:59.156-07:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-07-22T13:20:59.109-07:00",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-07-13T16:07:58.791-07:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-13T14:31:53.771-07:00",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-07-13T16:17:08.997-07:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-13T11:51:09.422-07:00",
 
194
  "body": "The incident has been resolved and the Custom Metrics metrics details page displays normally now.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-07-13T07:59:40.179-07:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-13T04:41:59.470-07:00",
 
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-07-13T01:39:10.911-07:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-12T23:15:43.000-07:00",
 
220
  "body": "This incident is resolved. Shared embeds and public links have been stable since 1:50 AM PT (08:50 UTC), and we have verified affected links render normally. A permanent fix ships later today. No data was lost and no customer action is needed.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "major",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-07-09T02:45:56.400-07:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-07-09T02:12:47.316-07:00",
 
233
  "body": "All systems are caught up and functioning normally.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "none",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-07-05T12:11:06.588-07:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-07-05T08:56:16.586-07:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-06-18T21:30:56.080-07:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-06-18T12:29:15.000-07:00",
 
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-06-04T16:05:35.687-07:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-06-04T11:55:08.000-07:00",
 
272
  "body": "Service has been restored for the Amplitude application, and users should now be able to access the application normally.\n\nWe have implemented a fix and are monitoring the system to ensure continued stability. We do not expect any data loss at this time.\n\nThank you for your patience.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "critical",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-06-03T06:26:38.443-07:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-06-03T06:13:13.489-07:00",
 
285
  "body": "We have resolved the issue affecting the Amplitude application, and services are operating normally again.\n\nWe do not expect any data loss as a result of this incident. Our team will continue to monitor the system to ensure stability.\n\nThank you for your patience.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "critical",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-06-03T05:52:37.689-07:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-06-03T05:25:01.137-07:00",
 
298
  "body": "The issue causing elevated application latency has been resolved. We have confirmed that system performance has returned to normal levels and continue to monitor closely to ensure ongoing stability.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-05-21T23:32:06.945-07:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-05-21T19:51:02.241-07:00",
 
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-05-19T06:02:42.792-07:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-05-19T05:45:51.777-07:00",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-05-14T19:03:53.426-07:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-05-14T14:42:22.022-07:00",
 
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-05-05T12:44:54.338-07:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-05-05T12:13:50.213-07:00",
 
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-04-29T07:33:06.509-07:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-04-29T01:15:23.000-07:00",
 
363
  "body": "The Amplitude web application in the US was briefly inaccessible. We identified the issue to be related to a misconfigured feature flag. The issue started at 10:00 AM PST, lasting 10 minutes, and is now resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-04-28T10:00:00.000-07:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-04-28T10:00:00.000-07:00",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-04-23T13:32:07.743-07:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-04-23T12:56:18.227-07:00",
 
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-04-15T18:11:53.438-07:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-04-15T16:09:27.612-07:00",
 
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "none",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-04-13T14:00:56.162-07:00",
407
  "resolved_inferred": false,
408
  "started_at": "2026-04-13T08:45:16.000-07:00",
 
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "critical",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-04-12T03:52:44.330-07:00",
420
  "resolved_inferred": false,
421
  "started_at": "2026-04-12T01:24:36.041-07:00",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-04-06T17:48:17.296-07:00",
433
  "resolved_inferred": false,
434
  "started_at": "2026-04-06T12:53:19.789-07:00",
 
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "critical",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-04-03T16:52:18.005-07:00",
446
  "resolved_inferred": false,
447
  "started_at": "2026-04-03T14:52:01.000-07:00",
 
454
  "body": "We have fixed the issue",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "critical",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-03-27T10:11:41.283-07:00",
459
  "resolved_inferred": false,
460
  "started_at": "2026-03-27T08:52:20.381-07:00",
 
467
  "body": "Some Flags and experiments that were targeting cohorts did not evaluate users into control and treatment correctly. This has been fixed",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "none",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-03-26T20:00:00.000-07:00",
472
  "resolved_inferred": false,
473
  "started_at": "2026-03-26T17:00:00.000-07:00",
 
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-03-25T11:09:09.739-07:00",
485
  "resolved_inferred": false,
486
  "started_at": "2026-03-25T11:00:50.187-07:00",
 
493
  "body": "This incident has been resolved.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "major",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2026-03-20T13:00:11.935-07:00",
498
  "resolved_inferred": false,
499
  "started_at": "2026-03-20T10:31:36.152-07:00",
 
506
  "body": "Duration: March 16, 2026, 11:20 AM PT to 1:17 PM PT\n\nBetween 11:20 AM PT and 1:17 PM PT, the Experiment Evaluation Service experienced a partial outage, resulting in elevated 500, 502, and 503 errors for some requests. Our team has successfully resolved the issue, and the service is now operating normally. We apologize for any inconvenience this disruption may have caused.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "none",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2026-03-16T13:55:39.780-07:00",
511
  "resolved_inferred": false,
512
  "started_at": "2026-03-16T13:55:39.724-07:00",
 
519
  "body": "Between 2026-03-16 08:57 AM PT (15:57 UTC) and 09:23 AM PT (16:23 UTC), some Amplitude users experienced intermittent 500 errors when loading charts, dashboards, and reports in Analytics and Experiment.\n\nA second brief interruption occurred at approximately 09:49 AM PT (16:49 UTC), during which some requests again returned 500 errors.\n\nThe issue was caused by a temporary database disruption that has since automatically recovered. Our team has confirmed that services are operating normally. No data loss occurred, and no customer action is needed.\n\nWe are actively investigating the root cause to prevent recurrence and will continue to monitor the system.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2026-03-16T09:00:00.000-07:00",
524
  "resolved_inferred": false,
525
  "started_at": "2026-03-16T09:00:00.000-07:00",
 
532
  "body": "A migration to transition some Growth orgs to a new permission system, which is activated by a feature flag, did not operate correctly, resulting in the appearance of lost role assignments for users. This affected some Growth orgs that have project-based permissions. Removing the feature flag for these orgs reverted them to the old permission system, restoring all role assignments correctly.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "major",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2026-03-10T09:00:00.000-07:00",
537
  "resolved_inferred": false,
538
  "started_at": "2026-03-10T09:00:00.000-07:00",
 
545
  "body": "This incident has been resolved.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2026-03-02T20:46:37.680-08:00",
550
  "resolved_inferred": false,
551
  "started_at": "2026-03-02T18:53:37.824-08:00",
 
558
  "body": "As of 3:10 PM PT, we have fully recovered and all systems are operating normally.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2026-02-27T15:47:57.347-08:00",
563
  "resolved_inferred": false,
564
  "started_at": "2026-02-27T14:22:46.000-08:00",
 
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "major",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2026-02-26T14:58:51.003-08:00",
576
  "resolved_inferred": false,
577
  "started_at": "2026-02-26T12:48:20.886-08:00",
 
584
  "body": "This incident has been resolved. The bug was isolated to a permissions issue with Amplitude users and did not impact any data ingestion, experiments, or other features. All user permissions should be back to operational.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "major",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2026-02-12T15:49:32.919-08:00",
589
  "resolved_inferred": false,
590
  "started_at": "2026-02-12T15:19:05.168-08:00",
 
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "minor",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2026-01-20T19:07:13.727-08:00",
602
  "resolved_inferred": false,
603
  "started_at": "2026-01-20T12:05:34.000-08:00",
 
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2026-01-08T09:17:41.960-08:00",
615
  "resolved_inferred": false,
616
  "started_at": "2026-01-08T06:07:32.961-08:00",
 
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "critical",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2025-12-10T00:46:00.275-08:00",
628
  "resolved_inferred": false,
629
  "started_at": "2025-12-09T19:40:30.695-08:00",
 
636
  "body": "As of Nov 22, 2025 14:00 UTC, this incident is resolved and customers should be able to see all historical data. Please reach out to support if you're still seeing gaps in your historical data.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2025-11-22T09:07:04.218-08:00",
641
  "resolved_inferred": false,
642
  "started_at": "2025-11-21T15:40:16.877-08:00",
 
649
  "body": "Amplitude's user interface and data ingestion were not impacted by the recent Cloudflare outage. However, your downstream destinations may have been impacted and we recommend checking with your vendor's status page to confirm impact.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "none",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2025-11-17T03:30:00.000-08:00",
654
  "resolved_inferred": false,
655
  "started_at": "2025-11-17T03:30:00.000-08:00",
api/v/amsoil-inc.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "amsoil-inc",
4
  "platform": "statuspage",
5
  "status_url": "https://status.amsoil.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-05-29T11:03:36.517-05:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-27T15:09:52.416-05:00",
@@ -25,7 +25,7 @@
25
  "body": "We have successfully resolved the issue causing degraded performance at AMSOIL.com and AMSOIL.ca. We apologize for any inconvenience this may have caused. \nSincerely, \n\nAMSOIL INC.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2025-11-18T09:03:39.127-06:00",
30
  "resolved_inferred": false,
31
  "started_at": "2025-11-18T08:22:58.379-06:00",
 
3
  "slug": "amsoil-inc",
4
  "platform": "statuspage",
5
  "status_url": "https://status.amsoil.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-05-29T11:03:36.517-05:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-27T15:09:52.416-05:00",
 
25
  "body": "We have successfully resolved the issue causing degraded performance at AMSOIL.com and AMSOIL.ca. We apologize for any inconvenience this may have caused. \nSincerely, \n\nAMSOIL INC.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2025-11-18T09:03:39.127-06:00",
30
  "resolved_inferred": false,
31
  "started_at": "2025-11-18T08:22:58.379-06:00",
api/v/anchor-host.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "anchor-host",
4
  "platform": "statuspage",
5
  "status_url": "https://anchorhost.statuspage.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "WP Rocket doesn't have a patch yet so we patched it directly with our v3.23.2.2. All customers affected with the WP Rocket + WordPress 7.1 compatible issue should be restored. Whenever WP Rocket does release an official fix, customers should automatically upgrade to that.\n\nThere were a few other plugins with similar compatible issues with v7.1. Reviewing and fixing as I discover them.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-19T17:54:39.976-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-19T17:31:57.739-04:00",
@@ -25,7 +25,7 @@
25
  "body": "The server has been stabilized. All customer websites should be restored.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-04-01T15:16:58.525-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-04-01T14:30:24.973-04:00",
@@ -38,7 +38,7 @@
38
  "body": "All customer website appears to be restored and healthy. Will continue to monitor the Cloudflare situation: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2025-11-18T09:57:00.361-05:00",
43
  "resolved_inferred": false,
44
  "started_at": "2025-11-18T08:17:48.295-05:00",
 
3
  "slug": "anchor-host",
4
  "platform": "statuspage",
5
  "status_url": "https://anchorhost.statuspage.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "WP Rocket doesn't have a patch yet so we patched it directly with our v3.23.2.2. All customers affected with the WP Rocket + WordPress 7.1 compatible issue should be restored. Whenever WP Rocket does release an official fix, customers should automatically upgrade to that.\n\nThere were a few other plugins with similar compatible issues with v7.1. Reviewing and fixing as I discover them.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-19T17:54:39.976-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-19T17:31:57.739-04:00",
 
25
  "body": "The server has been stabilized. All customer websites should be restored.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-04-01T15:16:58.525-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-04-01T14:30:24.973-04:00",
 
38
  "body": "All customer website appears to be restored and healthy. Will continue to monitor the Cloudflare situation: https://www.cloudflarestatus.com/incidents/8gmgl950y3h7.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2025-11-18T09:57:00.361-05:00",
43
  "resolved_inferred": false,
44
  "started_at": "2025-11-18T08:17:48.295-05:00",
api/v/anthropic.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "anthropic",
4
  "platform": "statuspage",
5
  "status_url": "https://status.anthropic.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:16:22Z",
@@ -12,7 +12,7 @@
12
  "body": "The issue affecting Claude Mythos 5.1, Claude Fable 5.1, and Claude Opus 5 has been resolved. Impact has ended as of 9:16 PT / 16:16 UTC.",
13
  "first_seen": "2026-09-04T07:16:22Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-03T16:23:12.052Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T13:26:04.201Z",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:16:22Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-09-03T12:56:26.632Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-09-03T12:37:31.766Z",
@@ -38,7 +38,7 @@
38
  "body": "The issue affecting Claude Sonnet 5 has been resolved. Impact occurred from 2:05pm PT / 21:05 UTC to 2:19pm PT / 21:19 UTC.",
39
  "first_seen": "2026-09-04T07:16:22Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-09-02T21:44:28.095Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-09-02T21:17:58.704Z",
@@ -51,7 +51,7 @@
51
  "body": "This issue has been resolved.",
52
  "first_seen": "2026-09-04T07:16:22Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-09-02T01:24:22.251Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-09-01T23:26:48.992Z",
@@ -64,7 +64,7 @@
64
  "body": "This issue has been resolved.",
65
  "first_seen": "2026-09-04T07:16:22Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-09-01T18:07:03.372Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-09-01T17:05:11.462Z",
@@ -77,7 +77,7 @@
77
  "body": "This issue has been resolved.",
78
  "first_seen": "2026-09-04T07:16:22Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-09-01T16:22:19.479Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-09-01T16:02:48.681Z",
@@ -90,7 +90,7 @@
90
  "body": "The issue affecting Claude Code has been resolved. Impact occurred from 16\u223655 to 19\u223616 UTC.",
91
  "first_seen": "2026-09-04T07:16:22Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-08-31T20:36:00.297Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-31T19:21:32.139Z",
@@ -103,7 +103,7 @@
103
  "body": "This issue has been resolved.",
104
  "first_seen": "2026-09-04T07:16:22Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-08-31T17:52:26.026Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-31T17:23:06.241Z",
@@ -116,7 +116,7 @@
116
  "body": "The issue affecting Claude Cowork and Claude Code on the web has been resolved.",
117
  "first_seen": "2026-09-04T07:16:22Z",
118
  "impact": "major",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-08-28T20:21:18.448Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-28T17:22:02.377Z",
@@ -129,7 +129,7 @@
129
  "body": "This issue has been resolved.",
130
  "first_seen": "2026-09-04T07:16:22Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-08-24T20:26:21.577Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-24T20:11:23.934Z",
@@ -142,7 +142,7 @@
142
  "body": "This issue has been resolved.",
143
  "first_seen": "2026-09-04T07:16:22Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-08-24T17:16:02.904Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-24T17:12:42.200Z",
@@ -155,7 +155,7 @@
155
  "body": "This issue has been resolved. From 9:50pm PT / 04:50 UTC through 00:36am PT / 07:36 UTC, users saw elevated errors on requests to Claude models, including Claude Opus 5 and Fable 5.",
156
  "first_seen": "2026-09-04T07:16:22Z",
157
  "impact": "major",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-08-24T08:30:47.615Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-08-24T05:06:39.493Z",
@@ -168,7 +168,7 @@
168
  "body": "This issue has been resolved.",
169
  "first_seen": "2026-09-04T07:16:22Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-08-20T19:42:38.692Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-08-20T19:16:24.932Z",
@@ -181,7 +181,7 @@
181
  "body": "This issue has been resolved.",
182
  "first_seen": "2026-09-04T07:16:22Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-08-20T19:01:03.844Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-08-20T18:32:13.296Z",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:16:22Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-08-19T11:02:18.264Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-08-19T09:42:37.414Z",
@@ -207,7 +207,7 @@
207
  "body": "The issue affecting Claude Opus 5 has been resolved. Impact occurred from 16:11 to 18:23 UTC.",
208
  "first_seen": "2026-09-04T07:16:22Z",
209
  "impact": "minor",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-08-18T19:01:45.447Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-08-18T16:20:22.240Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:16:22Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-08-17T15:29:25.545Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-08-17T13:56:41.055Z",
@@ -233,7 +233,7 @@
233
  "body": "The issue affecting claude.ai, platform.claude.com, the Claude API, Claude Code, and Claude Cowork has been resolved.",
234
  "first_seen": "2026-09-04T07:16:22Z",
235
  "impact": "critical",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-08-16T22:34:39.037Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-08-16T21:58:56.949Z",
@@ -246,7 +246,7 @@
246
  "body": "The issue affecting Claude services has been resolved. Impact occurred from 20:00 Aug 14, 2026 to 00:11 Aug 15 , 2026 UTC.",
247
  "first_seen": "2026-09-04T07:16:22Z",
248
  "impact": "major",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-08-15T00:27:36.893Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-08-14T23:57:16.567Z",
@@ -259,7 +259,7 @@
259
  "body": "The issue affecting the Claude API, Claude Code, and Claude Cowork has been resolved. Impact occurred from 20:14 to 20:38 UTC.",
260
  "first_seen": "2026-09-04T07:16:22Z",
261
  "impact": "major",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-08-14T21:58:12.691Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-08-14T20:30:36.289Z",
@@ -272,7 +272,7 @@
272
  "body": "The issue resulting in users being unable to reach status.claude.com has been resolved.",
273
  "first_seen": "2026-09-04T07:16:22Z",
274
  "impact": "none",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-08-14T10:53:22.898Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-08-14T07:58:11.620Z",
@@ -285,7 +285,7 @@
285
  "body": "The issue affecting Claude services has been resolved. Impact occurred from 23:42 to 00:50 UTC.",
286
  "first_seen": "2026-09-04T07:16:22Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-08-14T00:51:24.100Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-08-14T00:36:42.423Z",
@@ -298,7 +298,7 @@
298
  "body": "The issue affecting Claude Mythos 5 and Claude Fable 5 has been resolved.",
299
  "first_seen": "2026-09-04T07:16:22Z",
300
  "impact": "major",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-08-13T16:08:35.730Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-08-13T14:33:45.159Z",
@@ -311,7 +311,7 @@
311
  "body": "This issue has been resolved.",
312
  "first_seen": "2026-09-04T07:16:22Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-08-12T18:07:11.547Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-08-12T13:50:28.458Z",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:16:22Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-08-05T14:34:15.264Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-08-05T13:51:30.287Z",
@@ -337,7 +337,7 @@
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:16:22Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-08-05T14:14:36.006Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-08-05T07:05:54.000Z",
@@ -350,7 +350,7 @@
350
  "body": "This issue has been resolved.",
351
  "first_seen": "2026-09-04T07:16:22Z",
352
  "impact": "major",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-08-04T21:59:29.385Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-08-04T20:48:20.773Z",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:16:22Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-08-04T11:52:10.820Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-08-04T11:27:20.691Z",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:16:22Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-08-04T06:55:43.194Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-08-04T06:16:33.847Z",
@@ -389,7 +389,7 @@
389
  "body": "As of 15:20 UTC (8:20am PT), error rates on Claude Sonnet 5 have returned to baseline. This incident is resolved.",
390
  "first_seen": "2026-09-04T07:16:22Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-08-03T15:29:01.564Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-08-03T15:13:45.862Z",
@@ -402,7 +402,7 @@
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:16:22Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-08-03T14:17:14.797Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-08-03T12:52:52.852Z",
@@ -415,7 +415,7 @@
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:16:22Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-07-31T07:04:49.691Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-07-31T06:18:08.068Z",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:16:22Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2026-07-30T14:24:12.155Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-07-30T13:43:19.847Z",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:16:22Z",
443
  "impact": "major",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2026-07-30T10:48:56.631Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-07-30T05:57:43.524Z",
@@ -454,7 +454,7 @@
454
  "body": "This issue has been resolved.",
455
  "first_seen": "2026-09-04T07:16:22Z",
456
  "impact": "critical",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2026-07-29T22:36:20.701Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-07-29T19:49:45.388Z",
@@ -467,7 +467,7 @@
467
  "body": "As of 7:34 PST / 14:34 UTC the errors have returned to baseline.",
468
  "first_seen": "2026-09-04T07:16:22Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2026-07-27T14:36:43.730Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-07-27T13:39:52.265Z",
@@ -480,7 +480,7 @@
480
  "body": "As of 4:47 PST / 11:47 UTC the errors have returned to baseline.",
481
  "first_seen": "2026-09-04T07:16:22Z",
482
  "impact": "minor",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2026-07-27T12:30:22.946Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-07-27T11:27:38.071Z",
@@ -493,7 +493,7 @@
493
  "body": "As of 2:03 PST / 9:03 UTC the errors have returned to baseline.",
494
  "first_seen": "2026-09-04T07:16:22Z",
495
  "impact": "minor",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2026-07-27T09:05:24.911Z",
498
  "resolved_inferred": false,
499
  "started_at": "2026-07-27T08:16:57.590Z",
@@ -506,7 +506,7 @@
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:16:22Z",
508
  "impact": "major",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2026-07-26T10:44:14.944Z",
511
  "resolved_inferred": false,
512
  "started_at": "2026-07-26T09:17:12.697Z",
@@ -519,7 +519,7 @@
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:16:22Z",
521
  "impact": "major",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2026-07-25T22:08:41.677Z",
524
  "resolved_inferred": false,
525
  "started_at": "2026-07-25T21:34:51.173Z",
@@ -532,7 +532,7 @@
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:16:22Z",
534
  "impact": "major",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2026-07-25T19:44:32.851Z",
537
  "resolved_inferred": false,
538
  "started_at": "2026-07-25T18:40:31.869Z",
@@ -545,7 +545,7 @@
545
  "body": "For approximately 10 minutes, error rates on Sonnet 4.6 and 5 were elevated. Service returned to normal at approximately 11:07a PDT.",
546
  "first_seen": "2026-09-04T07:16:22Z",
547
  "impact": "none",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2026-07-25T18:13:01.000Z",
550
  "resolved_inferred": false,
551
  "started_at": "2026-07-25T18:13:01.000Z",
@@ -558,7 +558,7 @@
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:16:22Z",
560
  "impact": "minor",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2026-07-24T10:22:06.541Z",
563
  "resolved_inferred": false,
564
  "started_at": "2026-07-24T09:09:56.943Z",
@@ -571,7 +571,7 @@
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:16:22Z",
573
  "impact": "minor",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2026-07-23T00:10:17.291Z",
576
  "resolved_inferred": false,
577
  "started_at": "2026-07-22T23:52:59.578Z",
@@ -584,7 +584,7 @@
584
  "body": "This issue has been resolved.",
585
  "first_seen": "2026-09-04T07:16:22Z",
586
  "impact": "none",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2026-07-24T15:36:54.682Z",
589
  "resolved_inferred": false,
590
  "started_at": "2026-07-22T17:56:10.087Z",
@@ -597,7 +597,7 @@
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:16:22Z",
599
  "impact": "minor",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2026-07-22T17:45:37.482Z",
602
  "resolved_inferred": false,
603
  "started_at": "2026-07-22T17:27:36.523Z",
@@ -610,7 +610,7 @@
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:16:22Z",
612
  "impact": "minor",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2026-07-22T16:12:32.364Z",
615
  "resolved_inferred": false,
616
  "started_at": "2026-07-22T15:24:05.453Z",
@@ -623,7 +623,7 @@
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:16:22Z",
625
  "impact": "minor",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2026-07-22T15:23:37.914Z",
628
  "resolved_inferred": false,
629
  "started_at": "2026-07-22T13:37:28.237Z",
@@ -636,7 +636,7 @@
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:16:22Z",
638
  "impact": "minor",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2026-07-22T09:00:25.206Z",
641
  "resolved_inferred": false,
642
  "started_at": "2026-07-22T08:34:31.885Z",
@@ -649,7 +649,7 @@
649
  "body": "From 8:28am PT / 15:28 UTC through 9:26am PT / 16:26 UTC users experienced elevated errors on requests to multiple Claude models. This issue has been resolved.",
650
  "first_seen": "2026-09-04T07:16:22Z",
651
  "impact": "critical",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2026-07-21T18:18:55.036Z",
654
  "resolved_inferred": false,
655
  "started_at": "2026-07-21T15:35:03.996Z",
 
3
  "slug": "anthropic",
4
  "platform": "statuspage",
5
  "status_url": "https://status.anthropic.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:16:22Z",
 
12
  "body": "The issue affecting Claude Mythos 5.1, Claude Fable 5.1, and Claude Opus 5 has been resolved. Impact has ended as of 9:16 PT / 16:16 UTC.",
13
  "first_seen": "2026-09-04T07:16:22Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-03T16:23:12.052Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T13:26:04.201Z",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:16:22Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-09-03T12:56:26.632Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-09-03T12:37:31.766Z",
 
38
  "body": "The issue affecting Claude Sonnet 5 has been resolved. Impact occurred from 2:05pm PT / 21:05 UTC to 2:19pm PT / 21:19 UTC.",
39
  "first_seen": "2026-09-04T07:16:22Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-09-02T21:44:28.095Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-09-02T21:17:58.704Z",
 
51
  "body": "This issue has been resolved.",
52
  "first_seen": "2026-09-04T07:16:22Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-09-02T01:24:22.251Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-09-01T23:26:48.992Z",
 
64
  "body": "This issue has been resolved.",
65
  "first_seen": "2026-09-04T07:16:22Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-09-01T18:07:03.372Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-09-01T17:05:11.462Z",
 
77
  "body": "This issue has been resolved.",
78
  "first_seen": "2026-09-04T07:16:22Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-09-01T16:22:19.479Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-09-01T16:02:48.681Z",
 
90
  "body": "The issue affecting Claude Code has been resolved. Impact occurred from 16\u223655 to 19\u223616 UTC.",
91
  "first_seen": "2026-09-04T07:16:22Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-08-31T20:36:00.297Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-31T19:21:32.139Z",
 
103
  "body": "This issue has been resolved.",
104
  "first_seen": "2026-09-04T07:16:22Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-08-31T17:52:26.026Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-31T17:23:06.241Z",
 
116
  "body": "The issue affecting Claude Cowork and Claude Code on the web has been resolved.",
117
  "first_seen": "2026-09-04T07:16:22Z",
118
  "impact": "major",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-08-28T20:21:18.448Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-28T17:22:02.377Z",
 
129
  "body": "This issue has been resolved.",
130
  "first_seen": "2026-09-04T07:16:22Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-08-24T20:26:21.577Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-24T20:11:23.934Z",
 
142
  "body": "This issue has been resolved.",
143
  "first_seen": "2026-09-04T07:16:22Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-08-24T17:16:02.904Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-24T17:12:42.200Z",
 
155
  "body": "This issue has been resolved. From 9:50pm PT / 04:50 UTC through 00:36am PT / 07:36 UTC, users saw elevated errors on requests to Claude models, including Claude Opus 5 and Fable 5.",
156
  "first_seen": "2026-09-04T07:16:22Z",
157
  "impact": "major",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-08-24T08:30:47.615Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-08-24T05:06:39.493Z",
 
168
  "body": "This issue has been resolved.",
169
  "first_seen": "2026-09-04T07:16:22Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-08-20T19:42:38.692Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-08-20T19:16:24.932Z",
 
181
  "body": "This issue has been resolved.",
182
  "first_seen": "2026-09-04T07:16:22Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-08-20T19:01:03.844Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-08-20T18:32:13.296Z",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:16:22Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-08-19T11:02:18.264Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-08-19T09:42:37.414Z",
 
207
  "body": "The issue affecting Claude Opus 5 has been resolved. Impact occurred from 16:11 to 18:23 UTC.",
208
  "first_seen": "2026-09-04T07:16:22Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-08-18T19:01:45.447Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-08-18T16:20:22.240Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:16:22Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-08-17T15:29:25.545Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-08-17T13:56:41.055Z",
 
233
  "body": "The issue affecting claude.ai, platform.claude.com, the Claude API, Claude Code, and Claude Cowork has been resolved.",
234
  "first_seen": "2026-09-04T07:16:22Z",
235
  "impact": "critical",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-08-16T22:34:39.037Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-08-16T21:58:56.949Z",
 
246
  "body": "The issue affecting Claude services has been resolved. Impact occurred from 20:00 Aug 14, 2026 to 00:11 Aug 15 , 2026 UTC.",
247
  "first_seen": "2026-09-04T07:16:22Z",
248
  "impact": "major",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-08-15T00:27:36.893Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-08-14T23:57:16.567Z",
 
259
  "body": "The issue affecting the Claude API, Claude Code, and Claude Cowork has been resolved. Impact occurred from 20:14 to 20:38 UTC.",
260
  "first_seen": "2026-09-04T07:16:22Z",
261
  "impact": "major",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-08-14T21:58:12.691Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-08-14T20:30:36.289Z",
 
272
  "body": "The issue resulting in users being unable to reach status.claude.com has been resolved.",
273
  "first_seen": "2026-09-04T07:16:22Z",
274
  "impact": "none",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-08-14T10:53:22.898Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-08-14T07:58:11.620Z",
 
285
  "body": "The issue affecting Claude services has been resolved. Impact occurred from 23:42 to 00:50 UTC.",
286
  "first_seen": "2026-09-04T07:16:22Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-08-14T00:51:24.100Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-08-14T00:36:42.423Z",
 
298
  "body": "The issue affecting Claude Mythos 5 and Claude Fable 5 has been resolved.",
299
  "first_seen": "2026-09-04T07:16:22Z",
300
  "impact": "major",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-08-13T16:08:35.730Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-08-13T14:33:45.159Z",
 
311
  "body": "This issue has been resolved.",
312
  "first_seen": "2026-09-04T07:16:22Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-08-12T18:07:11.547Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-08-12T13:50:28.458Z",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:16:22Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-08-05T14:34:15.264Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-08-05T13:51:30.287Z",
 
337
  "body": "This incident has been resolved.",
338
  "first_seen": "2026-09-04T07:16:22Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-08-05T14:14:36.006Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-08-05T07:05:54.000Z",
 
350
  "body": "This issue has been resolved.",
351
  "first_seen": "2026-09-04T07:16:22Z",
352
  "impact": "major",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-08-04T21:59:29.385Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-08-04T20:48:20.773Z",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:16:22Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-08-04T11:52:10.820Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-08-04T11:27:20.691Z",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:16:22Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-08-04T06:55:43.194Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-08-04T06:16:33.847Z",
 
389
  "body": "As of 15:20 UTC (8:20am PT), error rates on Claude Sonnet 5 have returned to baseline. This incident is resolved.",
390
  "first_seen": "2026-09-04T07:16:22Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-08-03T15:29:01.564Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-08-03T15:13:45.862Z",
 
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:16:22Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-08-03T14:17:14.797Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-08-03T12:52:52.852Z",
 
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:16:22Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-07-31T07:04:49.691Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-07-31T06:18:08.068Z",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:16:22Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-07-30T14:24:12.155Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-07-30T13:43:19.847Z",
 
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:16:22Z",
443
  "impact": "major",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-07-30T10:48:56.631Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-07-30T05:57:43.524Z",
 
454
  "body": "This issue has been resolved.",
455
  "first_seen": "2026-09-04T07:16:22Z",
456
  "impact": "critical",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-07-29T22:36:20.701Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-07-29T19:49:45.388Z",
 
467
  "body": "As of 7:34 PST / 14:34 UTC the errors have returned to baseline.",
468
  "first_seen": "2026-09-04T07:16:22Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-07-27T14:36:43.730Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-07-27T13:39:52.265Z",
 
480
  "body": "As of 4:47 PST / 11:47 UTC the errors have returned to baseline.",
481
  "first_seen": "2026-09-04T07:16:22Z",
482
  "impact": "minor",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-07-27T12:30:22.946Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-07-27T11:27:38.071Z",
 
493
  "body": "As of 2:03 PST / 9:03 UTC the errors have returned to baseline.",
494
  "first_seen": "2026-09-04T07:16:22Z",
495
  "impact": "minor",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2026-07-27T09:05:24.911Z",
498
  "resolved_inferred": false,
499
  "started_at": "2026-07-27T08:16:57.590Z",
 
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:16:22Z",
508
  "impact": "major",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2026-07-26T10:44:14.944Z",
511
  "resolved_inferred": false,
512
  "started_at": "2026-07-26T09:17:12.697Z",
 
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:16:22Z",
521
  "impact": "major",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2026-07-25T22:08:41.677Z",
524
  "resolved_inferred": false,
525
  "started_at": "2026-07-25T21:34:51.173Z",
 
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:16:22Z",
534
  "impact": "major",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2026-07-25T19:44:32.851Z",
537
  "resolved_inferred": false,
538
  "started_at": "2026-07-25T18:40:31.869Z",
 
545
  "body": "For approximately 10 minutes, error rates on Sonnet 4.6 and 5 were elevated. Service returned to normal at approximately 11:07a PDT.",
546
  "first_seen": "2026-09-04T07:16:22Z",
547
  "impact": "none",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2026-07-25T18:13:01.000Z",
550
  "resolved_inferred": false,
551
  "started_at": "2026-07-25T18:13:01.000Z",
 
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:16:22Z",
560
  "impact": "minor",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2026-07-24T10:22:06.541Z",
563
  "resolved_inferred": false,
564
  "started_at": "2026-07-24T09:09:56.943Z",
 
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:16:22Z",
573
  "impact": "minor",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2026-07-23T00:10:17.291Z",
576
  "resolved_inferred": false,
577
  "started_at": "2026-07-22T23:52:59.578Z",
 
584
  "body": "This issue has been resolved.",
585
  "first_seen": "2026-09-04T07:16:22Z",
586
  "impact": "none",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2026-07-24T15:36:54.682Z",
589
  "resolved_inferred": false,
590
  "started_at": "2026-07-22T17:56:10.087Z",
 
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:16:22Z",
599
  "impact": "minor",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2026-07-22T17:45:37.482Z",
602
  "resolved_inferred": false,
603
  "started_at": "2026-07-22T17:27:36.523Z",
 
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:16:22Z",
612
  "impact": "minor",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2026-07-22T16:12:32.364Z",
615
  "resolved_inferred": false,
616
  "started_at": "2026-07-22T15:24:05.453Z",
 
623
  "body": "This incident has been resolved.",
624
  "first_seen": "2026-09-04T07:16:22Z",
625
  "impact": "minor",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2026-07-22T15:23:37.914Z",
628
  "resolved_inferred": false,
629
  "started_at": "2026-07-22T13:37:28.237Z",
 
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:16:22Z",
638
  "impact": "minor",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2026-07-22T09:00:25.206Z",
641
  "resolved_inferred": false,
642
  "started_at": "2026-07-22T08:34:31.885Z",
 
649
  "body": "From 8:28am PT / 15:28 UTC through 9:26am PT / 16:26 UTC users experienced elevated errors on requests to multiple Claude models. This issue has been resolved.",
650
  "first_seen": "2026-09-04T07:16:22Z",
651
  "impact": "critical",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2026-07-21T18:18:55.036Z",
654
  "resolved_inferred": false,
655
  "started_at": "2026-07-21T15:35:03.996Z",
api/v/apaleo.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "apaleo",
4
  "platform": "statuspage",
5
  "status_url": "https://status.apaleo.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Systems have been stable and working correctly for over 1 hour. We continue monitoring.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-27T17:44:44.515Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-27T13:30:00.392Z",
@@ -25,7 +25,7 @@
25
  "body": "Between 11:10 and 11:35 UTC (13:10\u201313:35 CEST), some users may have experienced errors when signing in via SSO. The issue was intermittent and affected only SSO-based authentication. Sign-ins using other authentication methods were not impacted and continued to work normally. The problem has since been resolved, and SSO login is now operating as expected. Users who were affected should now be able to log in without issue. We apologize for any inconvenience.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-11T11:00:00.000Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-11T11:00:00.000Z",
@@ -38,7 +38,7 @@
38
  "body": "An update was deployed that has improved the performance.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-07-20T13:09:08.296Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-20T11:21:02.635Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-06-30T17:59:18.327Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-06-30T16:34:06.170Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-05-05T10:55:17.567Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-05-05T10:16:39.868Z",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-03-10T15:38:24.450Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-03-10T08:27:58.427Z",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-03-09T16:52:12.451Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-03-09T16:26:10.470Z",
@@ -103,7 +103,7 @@
103
  "body": "All pending night audits have now been successfully processed, and systems are operating normally. Our team will continue to monitor to ensure stability.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-03-06T10:39:41.476Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-03-06T08:21:53.631Z",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "critical",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-02-21T00:53:24.158Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-02-21T00:36:07.850Z",
@@ -129,7 +129,7 @@
129
  "body": "We experienced an infrastructure failover on a backend system, the issue has been resolved and delayed processing has been caught up.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-02-20T19:00:00.000Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-02-20T19:00:00.000Z",
@@ -142,7 +142,7 @@
142
  "body": "All systems are working nominally, any webhook delays cleared.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-02-17T22:14:40.744Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-02-17T21:39:12.069Z",
@@ -155,7 +155,7 @@
155
  "body": "A transient issue affecting both the UI and API layers resulted in incorrect permission-related messages being returned. The issue was resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-02-11T15:50:00.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-02-11T14:30:00.000Z",
@@ -168,7 +168,7 @@
168
  "body": "We experienced a technical issue with GET /finance/v1/folios endpoint that has now been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-01-29T09:00:00.000Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-01-29T09:00:00.000Z",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2025-11-18T17:53:35.064Z",
186
  "resolved_inferred": false,
187
  "started_at": "2025-11-18T13:23:45.598Z",
@@ -194,7 +194,7 @@
194
  "body": "For approx. 20 minutes",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "none",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2025-11-05T08:30:00.000Z",
199
  "resolved_inferred": false,
200
  "started_at": "2025-11-05T08:30:00.000Z",
@@ -207,7 +207,7 @@
207
  "body": "We continue to monitor",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2025-10-23T14:41:10.691Z",
212
  "resolved_inferred": false,
213
  "started_at": "2025-10-23T11:30:50.000Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "critical",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2025-10-01T12:12:51.367Z",
225
  "resolved_inferred": false,
226
  "started_at": "2025-10-01T09:03:22.776Z",
@@ -233,7 +233,7 @@
233
  "body": "Webhook delivery performance has returned to normal, and the vast majority of events are now processing on time. We consider this incident resolved, but our team will continue to monitor the system to ensure sustained stability.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2025-08-22T08:51:18.823Z",
238
  "resolved_inferred": false,
239
  "started_at": "2025-08-20T09:12:25.970Z",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2025-08-07T12:06:34.168Z",
251
  "resolved_inferred": false,
252
  "started_at": "2025-08-07T11:24:18.838Z",
 
3
  "slug": "apaleo",
4
  "platform": "statuspage",
5
  "status_url": "https://status.apaleo.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Systems have been stable and working correctly for over 1 hour. We continue monitoring.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-27T17:44:44.515Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-27T13:30:00.392Z",
 
25
  "body": "Between 11:10 and 11:35 UTC (13:10\u201313:35 CEST), some users may have experienced errors when signing in via SSO. The issue was intermittent and affected only SSO-based authentication. Sign-ins using other authentication methods were not impacted and continued to work normally. The problem has since been resolved, and SSO login is now operating as expected. Users who were affected should now be able to log in without issue. We apologize for any inconvenience.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-11T11:00:00.000Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-11T11:00:00.000Z",
 
38
  "body": "An update was deployed that has improved the performance.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-07-20T13:09:08.296Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-20T11:21:02.635Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-06-30T17:59:18.327Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-06-30T16:34:06.170Z",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-05-05T10:55:17.567Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-05-05T10:16:39.868Z",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-03-10T15:38:24.450Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-03-10T08:27:58.427Z",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-03-09T16:52:12.451Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-03-09T16:26:10.470Z",
 
103
  "body": "All pending night audits have now been successfully processed, and systems are operating normally. Our team will continue to monitor to ensure stability.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-03-06T10:39:41.476Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-03-06T08:21:53.631Z",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "critical",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-02-21T00:53:24.158Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-02-21T00:36:07.850Z",
 
129
  "body": "We experienced an infrastructure failover on a backend system, the issue has been resolved and delayed processing has been caught up.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-02-20T19:00:00.000Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-02-20T19:00:00.000Z",
 
142
  "body": "All systems are working nominally, any webhook delays cleared.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-02-17T22:14:40.744Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-02-17T21:39:12.069Z",
 
155
  "body": "A transient issue affecting both the UI and API layers resulted in incorrect permission-related messages being returned. The issue was resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-02-11T15:50:00.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-02-11T14:30:00.000Z",
 
168
  "body": "We experienced a technical issue with GET /finance/v1/folios endpoint that has now been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-01-29T09:00:00.000Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-01-29T09:00:00.000Z",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2025-11-18T17:53:35.064Z",
186
  "resolved_inferred": false,
187
  "started_at": "2025-11-18T13:23:45.598Z",
 
194
  "body": "For approx. 20 minutes",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "none",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2025-11-05T08:30:00.000Z",
199
  "resolved_inferred": false,
200
  "started_at": "2025-11-05T08:30:00.000Z",
 
207
  "body": "We continue to monitor",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2025-10-23T14:41:10.691Z",
212
  "resolved_inferred": false,
213
  "started_at": "2025-10-23T11:30:50.000Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "critical",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2025-10-01T12:12:51.367Z",
225
  "resolved_inferred": false,
226
  "started_at": "2025-10-01T09:03:22.776Z",
 
233
  "body": "Webhook delivery performance has returned to normal, and the vast majority of events are now processing on time. We consider this incident resolved, but our team will continue to monitor the system to ensure sustained stability.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2025-08-22T08:51:18.823Z",
238
  "resolved_inferred": false,
239
  "started_at": "2025-08-20T09:12:25.970Z",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2025-08-07T12:06:34.168Z",
251
  "resolved_inferred": false,
252
  "started_at": "2025-08-07T11:24:18.838Z",
api/v/api-video.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "api-video",
4
  "platform": "statuspage",
5
  "status_url": "https://status.api.video",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "The issue affecting the Analytics database has been resolved, and all Analytics services are now fully operational.\nData retrieval through both the dashboard and API has been restored. \nThank you for your patience.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-07-21T07:33:01.055Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-20T09:32:02.667Z",
@@ -25,7 +25,7 @@
25
  "body": "The issue affecting our database has been resolved, and all services are operating normally again.\nThe incident was caused by an issue with our database provider, which has since been resolved. We appreciate your patience while we worked with our provider to restore full service.\nThank you for your understanding. If you continue to experience any issues, please contact our support team.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-07-20T06:59:38.308Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-19T17:27:47.137Z",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-07-07T10:37:55.637Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-07T08:06:28.819Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-06T15:07:21.121Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-06T12:35:55.428Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-06-09T08:54:27.164Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-06-09T07:48:22.189Z",
@@ -77,7 +77,7 @@
77
  "body": "The encoding queue has been fully processed and the pipeline is now operating normally. All pending videos have been cleared, and processing times have returned to the standard latency. No further delays are expected at this time.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-04-27T09:02:13.110Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-04-27T08:33:32.257Z",
@@ -90,7 +90,7 @@
90
  "body": "A service disruption occurred due to an unexpected underlying infrastructure malfunction.\nWe apologize for any inconvenience caused and appreciate your understanding.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "major",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-04-13T12:03:03.274Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-04-13T09:36:26.000Z",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "major",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-03-26T13:30:18.993Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-03-26T13:07:15.511Z",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.\nHeavy traffic on our database servers caused access issues to our content delivery servers and affected the dashboard.\nWe sincerely apologize for the outage and any inconvenience this may have caused.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "critical",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-03-23T12:21:50.590Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-03-23T10:13:52.657Z",
@@ -129,7 +129,7 @@
129
  "body": "A network-related issue caused DNS resolution failures for some of our internal services, which affected service availability for a significant portion of users during 55 minutes.\nOur team identified the root cause, resolved the network/DNS issue, and services are now fully restored.\nWe apologize for the disruption and appreciate your patience.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-03-11T20:12:45.159Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-03-11T19:21:00.437Z",
@@ -142,7 +142,7 @@
142
  "body": "Queue has been treated, service is back to normal.\nAn hypervisor failure was identified has the root cause of the slowdown",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-12-10T10:58:34.666Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-12-10T10:09:12.460Z",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-12-02T17:19:06.216Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-02T07:43:27.336Z",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-11-05T08:54:12.654Z",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-05T07:49:37.999Z",
@@ -181,7 +181,7 @@
181
  "body": "The service has fully recovered. Performances have been optimal since 18:00 UTC.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2025-10-18T19:11:21.532Z",
186
  "resolved_inferred": false,
187
  "started_at": "2025-10-17T16:35:20.239Z",
@@ -194,7 +194,7 @@
194
  "body": "The incident has been resolved.\nPending tasks are being processed.\nWe apologize for any inconvenience caused.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2025-09-30T09:32:50.264Z",
199
  "resolved_inferred": false,
200
  "started_at": "2025-09-30T09:13:00.400Z",
@@ -207,7 +207,7 @@
207
  "body": "The storage has fully recover. The VOD ingest and delivery service are operational since 18:09 UTC.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "critical",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2025-09-02T18:21:36.842Z",
212
  "resolved_inferred": false,
213
  "started_at": "2025-09-02T16:33:32.182Z",
 
3
  "slug": "api-video",
4
  "platform": "statuspage",
5
  "status_url": "https://status.api.video",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "The issue affecting the Analytics database has been resolved, and all Analytics services are now fully operational.\nData retrieval through both the dashboard and API has been restored. \nThank you for your patience.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-07-21T07:33:01.055Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-20T09:32:02.667Z",
 
25
  "body": "The issue affecting our database has been resolved, and all services are operating normally again.\nThe incident was caused by an issue with our database provider, which has since been resolved. We appreciate your patience while we worked with our provider to restore full service.\nThank you for your understanding. If you continue to experience any issues, please contact our support team.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-07-20T06:59:38.308Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-19T17:27:47.137Z",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-07-07T10:37:55.637Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-07T08:06:28.819Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-06T15:07:21.121Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-06T12:35:55.428Z",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-06-09T08:54:27.164Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-06-09T07:48:22.189Z",
 
77
  "body": "The encoding queue has been fully processed and the pipeline is now operating normally. All pending videos have been cleared, and processing times have returned to the standard latency. No further delays are expected at this time.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-04-27T09:02:13.110Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-04-27T08:33:32.257Z",
 
90
  "body": "A service disruption occurred due to an unexpected underlying infrastructure malfunction.\nWe apologize for any inconvenience caused and appreciate your understanding.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "major",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-04-13T12:03:03.274Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-04-13T09:36:26.000Z",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "major",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-03-26T13:30:18.993Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-03-26T13:07:15.511Z",
 
116
  "body": "This incident has been resolved.\nHeavy traffic on our database servers caused access issues to our content delivery servers and affected the dashboard.\nWe sincerely apologize for the outage and any inconvenience this may have caused.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "critical",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-03-23T12:21:50.590Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-03-23T10:13:52.657Z",
 
129
  "body": "A network-related issue caused DNS resolution failures for some of our internal services, which affected service availability for a significant portion of users during 55 minutes.\nOur team identified the root cause, resolved the network/DNS issue, and services are now fully restored.\nWe apologize for the disruption and appreciate your patience.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-03-11T20:12:45.159Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-03-11T19:21:00.437Z",
 
142
  "body": "Queue has been treated, service is back to normal.\nAn hypervisor failure was identified has the root cause of the slowdown",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-12-10T10:58:34.666Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-12-10T10:09:12.460Z",
 
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-12-02T17:19:06.216Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-02T07:43:27.336Z",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-11-05T08:54:12.654Z",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-05T07:49:37.999Z",
 
181
  "body": "The service has fully recovered. Performances have been optimal since 18:00 UTC.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2025-10-18T19:11:21.532Z",
186
  "resolved_inferred": false,
187
  "started_at": "2025-10-17T16:35:20.239Z",
 
194
  "body": "The incident has been resolved.\nPending tasks are being processed.\nWe apologize for any inconvenience caused.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2025-09-30T09:32:50.264Z",
199
  "resolved_inferred": false,
200
  "started_at": "2025-09-30T09:13:00.400Z",
 
207
  "body": "The storage has fully recover. The VOD ingest and delivery service are operational since 18:09 UTC.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "critical",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2025-09-02T18:21:36.842Z",
212
  "resolved_inferred": false,
213
  "started_at": "2025-09-02T16:33:32.182Z",
api/v/apify.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "apify",
4
  "platform": "statuspage",
5
  "status_url": "https://status.apify.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-20T18:14:23.779+02:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-20T16:05:26.370+02:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-14T16:05:05.683+02:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-13T17:38:56.958+02:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-08T20:59:11.474+02:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-07T23:00:02.249+02:00",
@@ -51,7 +51,7 @@
51
  "body": "The Google SERP Proxy is stabilized, and we continue to monitor its performance.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "major",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-05T15:30:14.000+02:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-04T01:56:45.122+02:00",
@@ -64,7 +64,7 @@
64
  "body": "The problem has been resolved. Impact was an increased error rate at the Actor Standby API, not other component was affected. There was no downtime during the period of the incident.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-26T09:57:43.065+02:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-26T08:53:28.418+02:00",
@@ -77,7 +77,7 @@
77
  "body": "The database is fully recovered, and all systems are operational. We apologize for any inconvenience this might have caused. We are currently implementing new measures to ensure this won't happen again.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "critical",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-07-22T04:38:42.765+02:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-21T16:49:36.548+02:00",
@@ -90,7 +90,7 @@
90
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-07-21T13:53:36.743+02:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-21T08:52:32.166+02:00",
@@ -103,7 +103,7 @@
103
  "body": "The issue has been resolved.\nBoth the response time and success rate have returned to normal levels.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-17T22:08:31.551+02:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-17T16:04:46.135+02:00",
@@ -116,7 +116,7 @@
116
  "body": "Webhooks are operational, and we apologize for any inconvenience this might have caused.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-06-04T19:07:34.129+02:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-04T17:07:50.012+02:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-05-16T07:28:09.245+02:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-15T13:48:36.116+02:00",
@@ -142,7 +142,7 @@
142
  "body": "We experienced degraded performance on our proxy due to an unexpected increase in load. This caused slower response times for some users.\n\nThe issue lasted approximately 5 minutes and has been fully resolved. All systems are now operating normally.\n\nWe apologize for the inconvenience.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "critical",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-05-14T09:20:00.000+02:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-14T07:20:00.000+02:00",
@@ -155,7 +155,7 @@
155
  "body": "We have implemented a fix for the OAuth flow, and the connections are now working normally.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-05-07T10:27:00.250+02:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-06T22:08:34.494+02:00",
@@ -168,7 +168,7 @@
168
  "body": "We've resolved an issue where a key-value store API update caused some Actor runs to time out.\n\nIf your Actor run timed out you can get it back by resurrecting it. There was no data loss.\n\nWe sincerely apologize for any inconvenience this may have caused.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-05-05T16:34:55.748+02:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-05T15:50:20.781+02:00",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-05-01T13:57:11.814+02:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-01T13:23:58.449+02:00",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-04-29T17:13:32.497+02:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-29T14:35:09.564+02:00",
@@ -207,7 +207,7 @@
207
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused. We are currently implementing new measures to make sure that this won't happen again.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-04-09T11:15:57.630+02:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-08T12:01:20.919+02:00",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-03-12T10:34:56.026+01:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-11T13:48:42.994+01:00",
@@ -233,7 +233,7 @@
233
  "body": "Datacenter proxy performance has been fully restored.\nWe apologize for any inconvenience this may have caused.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-03-06T20:05:09.355+01:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-06T18:27:45.340+01:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-01-27T10:37:36.015+01:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-01-27T05:10:23.229+01:00",
@@ -259,7 +259,7 @@
259
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused. We are currently implementing new measures to make sure that this won't happen again.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "critical",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-01-21T16:19:46.721+01:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-01-21T16:17:28.000+01:00",
@@ -272,7 +272,7 @@
272
  "body": "A fix has been implemented, and Apify Store is back to normal operations.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-01-12T09:58:12.130+01:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-01-12T09:22:09.053+01:00",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-01-09T22:13:37.064+01:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-09T21:26:39.377+01:00",
@@ -298,7 +298,7 @@
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "major",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2025-12-31T11:50:03.495+01:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-12-31T11:31:49.397+01:00",
@@ -311,7 +311,7 @@
311
  "body": "The issue affecting the creation of new Actors from Actor templates has now been fully resolved.\nService is operating normally again.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2025-12-11T18:26:25.056+01:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-12-11T15:56:27.440+01:00",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2025-10-29T21:21:34.133+01:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-10-29T20:06:38.973+01:00",
@@ -337,7 +337,7 @@
337
  "body": "As of 07:30 UTC, the Apify platform is operating normally. Amazon Web Services have also marked their incident as resolved, which gives us confidence that the outage has concluded. We will continue to monitor the situation and apologize for any inconvenience this may have caused.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "critical",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2025-10-21T09:30:06.000+02:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-10-20T16:42:47.133+02:00",
@@ -350,7 +350,7 @@
350
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused. We are currently implementing new measures to make sure that this won't happen again.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2025-10-20T16:40:57.916+02:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-10-20T09:00:17.000+02:00",
@@ -363,7 +363,7 @@
363
  "body": "Incident has been resolved",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2025-10-14T18:37:42.542+02:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-10-14T18:35:02.714+02:00",
@@ -376,7 +376,7 @@
376
  "body": "Actor build success rate has fully recovered. If your Actor builds failed, please rerun them. We apologize for any inconvenience caused.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "critical",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-09-25T03:48:23.006+02:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-09-25T01:16:14.887+02:00",
@@ -389,7 +389,7 @@
389
  "body": "The latest version of the apify/send-mail Actor failed to email all recipients. The issue lasted from around 13:50 to 14:05 CEST. The root cause was identified, and the service of the Actor was restored.\n\nWe apologize for any inconvenience this might have caused. We take this problem seriously and will take steps to prevent such issues from occurring in the future.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "none",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-09-15T14:38:10.455+02:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-09-15T14:38:10.412+02:00",
@@ -402,7 +402,7 @@
402
  "body": "All affected Actors have been rebuilt, and all builds are working correctly now.\n\nWe will continue to monitor the situation in case more failed builds appear.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-09-09T17:06:36.154+02:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-09-09T13:17:28.328+02:00",
@@ -415,7 +415,7 @@
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-08-07T18:15:45.098+02:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-08-07T16:44:33.073+02:00",
@@ -428,7 +428,7 @@
428
  "body": "The issue with country codes for datacenter proxies has been resolved.\nDatacenter proxies with country codes are now fully operational again.\n\nWe apologize for any inconvenience this may have caused, and thank you for your patience!",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "major",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-08-01T15:21:44.655+02:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-08-01T11:03:54.683+02:00",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved. We are sorry for the inconvenience.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-08-01T10:13:49.905+02:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-08-01T08:30:48.318+02:00",
 
3
  "slug": "apify",
4
  "platform": "statuspage",
5
  "status_url": "https://status.apify.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "none",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-20T18:14:23.779+02:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-20T16:05:26.370+02:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-14T16:05:05.683+02:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-13T17:38:56.958+02:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-08T20:59:11.474+02:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-07T23:00:02.249+02:00",
 
51
  "body": "The Google SERP Proxy is stabilized, and we continue to monitor its performance.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "major",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-05T15:30:14.000+02:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-04T01:56:45.122+02:00",
 
64
  "body": "The problem has been resolved. Impact was an increased error rate at the Actor Standby API, not other component was affected. There was no downtime during the period of the incident.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-26T09:57:43.065+02:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-26T08:53:28.418+02:00",
 
77
  "body": "The database is fully recovered, and all systems are operational. We apologize for any inconvenience this might have caused. We are currently implementing new measures to ensure this won't happen again.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "critical",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-07-22T04:38:42.765+02:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-21T16:49:36.548+02:00",
 
90
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-07-21T13:53:36.743+02:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-21T08:52:32.166+02:00",
 
103
  "body": "The issue has been resolved.\nBoth the response time and success rate have returned to normal levels.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-17T22:08:31.551+02:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-17T16:04:46.135+02:00",
 
116
  "body": "Webhooks are operational, and we apologize for any inconvenience this might have caused.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-06-04T19:07:34.129+02:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-04T17:07:50.012+02:00",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-05-16T07:28:09.245+02:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-15T13:48:36.116+02:00",
 
142
  "body": "We experienced degraded performance on our proxy due to an unexpected increase in load. This caused slower response times for some users.\n\nThe issue lasted approximately 5 minutes and has been fully resolved. All systems are now operating normally.\n\nWe apologize for the inconvenience.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "critical",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-05-14T09:20:00.000+02:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-14T07:20:00.000+02:00",
 
155
  "body": "We have implemented a fix for the OAuth flow, and the connections are now working normally.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-05-07T10:27:00.250+02:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-06T22:08:34.494+02:00",
 
168
  "body": "We've resolved an issue where a key-value store API update caused some Actor runs to time out.\n\nIf your Actor run timed out you can get it back by resurrecting it. There was no data loss.\n\nWe sincerely apologize for any inconvenience this may have caused.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-05-05T16:34:55.748+02:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-05T15:50:20.781+02:00",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-05-01T13:57:11.814+02:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-01T13:23:58.449+02:00",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-04-29T17:13:32.497+02:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-29T14:35:09.564+02:00",
 
207
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused. We are currently implementing new measures to make sure that this won't happen again.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-04-09T11:15:57.630+02:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-08T12:01:20.919+02:00",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-03-12T10:34:56.026+01:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-11T13:48:42.994+01:00",
 
233
  "body": "Datacenter proxy performance has been fully restored.\nWe apologize for any inconvenience this may have caused.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-03-06T20:05:09.355+01:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-06T18:27:45.340+01:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-01-27T10:37:36.015+01:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-01-27T05:10:23.229+01:00",
 
259
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused. We are currently implementing new measures to make sure that this won't happen again.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "critical",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-01-21T16:19:46.721+01:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-01-21T16:17:28.000+01:00",
 
272
  "body": "A fix has been implemented, and Apify Store is back to normal operations.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-01-12T09:58:12.130+01:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-01-12T09:22:09.053+01:00",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-01-09T22:13:37.064+01:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-01-09T21:26:39.377+01:00",
 
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "major",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2025-12-31T11:50:03.495+01:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-12-31T11:31:49.397+01:00",
 
311
  "body": "The issue affecting the creation of new Actors from Actor templates has now been fully resolved.\nService is operating normally again.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2025-12-11T18:26:25.056+01:00",
316
  "resolved_inferred": false,
317
  "started_at": "2025-12-11T15:56:27.440+01:00",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "minor",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2025-10-29T21:21:34.133+01:00",
329
  "resolved_inferred": false,
330
  "started_at": "2025-10-29T20:06:38.973+01:00",
 
337
  "body": "As of 07:30 UTC, the Apify platform is operating normally. Amazon Web Services have also marked their incident as resolved, which gives us confidence that the outage has concluded. We will continue to monitor the situation and apologize for any inconvenience this may have caused.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "critical",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2025-10-21T09:30:06.000+02:00",
342
  "resolved_inferred": false,
343
  "started_at": "2025-10-20T16:42:47.133+02:00",
 
350
  "body": "All systems are operational, and we apologize for any inconvenience this might have caused. We are currently implementing new measures to make sure that this won't happen again.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2025-10-20T16:40:57.916+02:00",
355
  "resolved_inferred": false,
356
  "started_at": "2025-10-20T09:00:17.000+02:00",
 
363
  "body": "Incident has been resolved",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2025-10-14T18:37:42.542+02:00",
368
  "resolved_inferred": false,
369
  "started_at": "2025-10-14T18:35:02.714+02:00",
 
376
  "body": "Actor build success rate has fully recovered. If your Actor builds failed, please rerun them. We apologize for any inconvenience caused.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "critical",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-09-25T03:48:23.006+02:00",
381
  "resolved_inferred": false,
382
  "started_at": "2025-09-25T01:16:14.887+02:00",
 
389
  "body": "The latest version of the apify/send-mail Actor failed to email all recipients. The issue lasted from around 13:50 to 14:05 CEST. The root cause was identified, and the service of the Actor was restored.\n\nWe apologize for any inconvenience this might have caused. We take this problem seriously and will take steps to prevent such issues from occurring in the future.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "none",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-09-15T14:38:10.455+02:00",
394
  "resolved_inferred": false,
395
  "started_at": "2025-09-15T14:38:10.412+02:00",
 
402
  "body": "All affected Actors have been rebuilt, and all builds are working correctly now.\n\nWe will continue to monitor the situation in case more failed builds appear.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-09-09T17:06:36.154+02:00",
407
  "resolved_inferred": false,
408
  "started_at": "2025-09-09T13:17:28.328+02:00",
 
415
  "body": "This incident has been resolved.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-08-07T18:15:45.098+02:00",
420
  "resolved_inferred": false,
421
  "started_at": "2025-08-07T16:44:33.073+02:00",
 
428
  "body": "The issue with country codes for datacenter proxies has been resolved.\nDatacenter proxies with country codes are now fully operational again.\n\nWe apologize for any inconvenience this may have caused, and thank you for your patience!",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "major",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-08-01T15:21:44.655+02:00",
433
  "resolved_inferred": false,
434
  "started_at": "2025-08-01T11:03:54.683+02:00",
 
441
  "body": "This incident has been resolved. We are sorry for the inconvenience.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-08-01T10:13:49.905+02:00",
446
  "resolved_inferred": false,
447
  "started_at": "2025-08-01T08:30:48.318+02:00",
api/v/apigee.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "apigee",
4
  "platform": "statuspage",
5
  "status_url": "https://status.apigee.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "apigee",
4
  "platform": "statuspage",
5
  "status_url": "https://status.apigee.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/apollo.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "apollo",
4
  "platform": "statuspage",
5
  "status_url": "http://status.apollographql.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Our third party vendor has confirmed the issue is now resolved, and all Apollo products have recovered.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-01T20:18:54Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T15:41:44Z",
@@ -24,7 +24,7 @@
24
  "body": "The fix has been deployed. These failed operations would have appeared as rate limit errors, but the rate limit was being incorrectly applied. We have made changes to ensure the rate limit works as expected.",
25
  "first_seen": "2026-09-04T07:06:16Z",
26
  "impact": "major",
27
- "last_seen": "2026-09-04T09:06:33Z",
28
  "resolved_at": "2026-08-26T23:36:51Z",
29
  "resolved_inferred": false,
30
  "started_at": "2026-08-26T22:12:39Z",
@@ -36,7 +36,7 @@
36
  "body": "The issue has been resolved.",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "minor",
39
- "last_seen": "2026-09-04T09:06:33Z",
40
  "resolved_at": "2026-08-11T23:19:08Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-08-11T19:11:37Z",
@@ -48,7 +48,7 @@
48
  "body": "The issue has been fixed.",
49
  "first_seen": "2026-09-04T07:06:16Z",
50
  "impact": "major",
51
- "last_seen": "2026-09-04T09:06:33Z",
52
  "resolved_at": "2026-08-05T10:08:58Z",
53
  "resolved_inferred": false,
54
  "started_at": "2026-08-05T09:43:26Z",
@@ -60,7 +60,7 @@
60
  "body": "The error rate for Proposals has returned to normal, no further impact expected.",
61
  "first_seen": "2026-09-04T07:06:16Z",
62
  "impact": "minor",
63
- "last_seen": "2026-09-04T09:06:33Z",
64
  "resolved_at": "2026-07-09T18:09:55Z",
65
  "resolved_inferred": false,
66
  "started_at": "2026-07-09T15:41:29Z",
@@ -72,7 +72,7 @@
72
  "body": "The backlock of schema coordinate (object field, input object field, and enum value) metrics has now cleared and there is no more metric ingestion delay. The metrics for input object fields, enum values, and the operation and client breakdown of object fields is inaccurate for June 27 4-5am and 8-9pm, and missing between 5am to 8pm (all times in UTC). All other metrics were not impacted.",
73
  "first_seen": "2026-09-04T07:06:16Z",
74
  "impact": "major",
75
- "last_seen": "2026-09-04T09:06:33Z",
76
  "resolved_at": "2026-06-28T20:16:19Z",
77
  "resolved_inferred": false,
78
  "started_at": "2026-06-28T03:13:19Z",
@@ -84,7 +84,7 @@
84
  "body": "The metric ingestion backlog has been fully processed and all metrics have resumed normal ingestion. We do not believe any data was lost as a result of this incident. All metric types should now be operating as expected. Thank you for your patience throughout this incident.",
85
  "first_seen": "2026-09-04T07:06:16Z",
86
  "impact": "minor",
87
- "last_seen": "2026-09-04T09:06:33Z",
88
  "resolved_at": "2026-06-15T22:16:12Z",
89
  "resolved_inferred": false,
90
  "started_at": "2026-06-15T14:38:25Z",
@@ -96,7 +96,7 @@
96
  "body": "After extended monitoring, we have confirmed that the issue is resolved. Post-incident action items will continue after the end of the incident. As with all incidents, we will be conducting an internal post-mortem. We appreciate your patience.",
97
  "first_seen": "2026-09-04T07:06:16Z",
98
  "impact": "none",
99
- "last_seen": "2026-09-04T09:06:33Z",
100
  "resolved_at": "2026-06-01T11:39:54Z",
101
  "resolved_inferred": false,
102
  "started_at": "2026-06-01T08:35:25Z",
@@ -108,7 +108,7 @@
108
  "body": "The issue affecting the visibility of the \u201cSubmit a Request\u201d and \u201cMy Requests\u201d buttons in the Apollo Support Portal has been resolved.\nPortal functionality has been restored, and users should now be able to access these options normally.\nThank you for your patience while we worked to resolve this issue.",
109
  "first_seen": "2026-09-04T07:06:16Z",
110
  "impact": "none",
111
- "last_seen": "2026-09-04T09:06:33Z",
112
  "resolved_at": "2026-05-26T12:58:43Z",
113
  "resolved_inferred": false,
114
  "started_at": "2026-05-25T19:50:43Z",
@@ -120,7 +120,7 @@
120
  "body": "We have observed sustained restored functionality in our Studio-initiated support ticket form and are marking this as fully resolved.",
121
  "first_seen": "2026-09-04T07:06:16Z",
122
  "impact": "none",
123
- "last_seen": "2026-09-04T09:06:33Z",
124
  "resolved_at": "2026-04-27T10:29:10Z",
125
  "resolved_inferred": false,
126
  "started_at": "2026-04-27T08:34:51Z",
@@ -132,7 +132,7 @@
132
  "body": "We have resolved the issue. Customers should see full functionality.",
133
  "first_seen": "2026-09-04T07:06:16Z",
134
  "impact": "none",
135
- "last_seen": "2026-09-04T09:06:33Z",
136
  "resolved_at": "2026-04-24T20:53:27Z",
137
  "resolved_inferred": false,
138
  "started_at": "2026-04-24T19:27:20Z",
@@ -144,7 +144,7 @@
144
  "body": "SSO login is now fixed.",
145
  "first_seen": "2026-09-04T07:06:16Z",
146
  "impact": "critical",
147
- "last_seen": "2026-09-04T09:06:33Z",
148
  "resolved_at": "2026-04-21T17:47:38Z",
149
  "resolved_inferred": false,
150
  "started_at": "2026-04-21T17:05:47Z",
@@ -156,7 +156,7 @@
156
  "body": "Proposals errors have been clear for ~2 hours since the rollback reached prod. Marking resolved.",
157
  "first_seen": "2026-09-04T07:06:16Z",
158
  "impact": "minor",
159
- "last_seen": "2026-09-04T09:06:33Z",
160
  "resolved_at": "2026-04-16T15:43:07Z",
161
  "resolved_inferred": false,
162
  "started_at": "2026-04-16T12:45:07Z",
@@ -168,7 +168,7 @@
168
  "body": "Retries of delayed transaction emails have been successful. If you have not received an email you were expecting for account reasons, we suggest retrying the workflow which triggered the email.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-03-31T07:39:56Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-03-31T06:59:02Z",
@@ -180,7 +180,7 @@
180
  "body": "We've identified an issue where our metrics ingestion pipeline was falling behind for several hours. Systems have now fully recovered and no data was lost, however some customers may have experienced delays viewing insights data in Studio and / or slower page load times during this event. Apologies for the interruption.",
181
  "first_seen": "2026-09-04T07:06:16Z",
182
  "impact": "none",
183
- "last_seen": "2026-09-04T09:06:33Z",
184
  "resolved_at": "2026-02-10T16:00:00Z",
185
  "resolved_inferred": false,
186
  "started_at": "2026-02-12T06:06:22Z",
@@ -192,7 +192,7 @@
192
  "body": "The issue has been resolved.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "minor",
195
- "last_seen": "2026-09-04T09:06:33Z",
196
  "resolved_at": "2025-11-21T21:25:39Z",
197
  "resolved_inferred": false,
198
  "started_at": "2025-11-21T18:05:32Z",
@@ -204,7 +204,7 @@
204
  "body": "There was a period of degraded performance on schema publishing. The root cause has been identified and service restored.",
205
  "first_seen": "2026-09-04T07:06:16Z",
206
  "impact": "none",
207
- "last_seen": "2026-09-04T09:06:33Z",
208
  "resolved_at": "2025-11-18T17:30:00Z",
209
  "resolved_inferred": false,
210
  "started_at": "2025-11-18T19:06:04Z",
@@ -216,7 +216,7 @@
216
  "body": "We are marking this incident resolved on the Apollo side.\n\nFor any continuing matters, please consult our support portal: https://support.apollographql.com/",
217
  "first_seen": "2026-09-04T07:06:16Z",
218
  "impact": "major",
219
- "last_seen": "2026-09-04T09:06:33Z",
220
  "resolved_at": "2025-11-18T15:38:24Z",
221
  "resolved_inferred": false,
222
  "started_at": "2025-11-18T13:05:25Z",
@@ -228,7 +228,7 @@
228
  "body": "Cloud Routers are experiencing elevated errors due to an upstream external provider incident.",
229
  "first_seen": "2026-09-04T07:06:16Z",
230
  "impact": "none",
231
- "last_seen": "2026-09-04T09:06:33Z",
232
  "resolved_at": "2025-11-18T12:30:00Z",
233
  "resolved_inferred": false,
234
  "started_at": "2025-11-18T13:05:25Z",
@@ -240,7 +240,7 @@
240
  "body": "We've confirmed that the issue with federation versions 2.9, 2.10, and 2.11 is resolved.",
241
  "first_seen": "2026-09-04T07:06:16Z",
242
  "impact": "major",
243
- "last_seen": "2026-09-04T09:06:33Z",
244
  "resolved_at": "2025-11-05T15:12:28Z",
245
  "resolved_inferred": false,
246
  "started_at": "2025-11-05T14:05:49Z",
@@ -252,7 +252,7 @@
252
  "body": "No schema publishing or checks issues have been observed for couple of hours now. We are continuing to monitor our services in relation to the AWS outage today on the other open incident.",
253
  "first_seen": "2026-09-04T07:06:16Z",
254
  "impact": "minor",
255
- "last_seen": "2026-09-04T09:06:33Z",
256
  "resolved_at": "2025-10-21T05:26:55Z",
257
  "resolved_inferred": false,
258
  "started_at": "2025-10-20T21:06:09Z",
@@ -264,7 +264,7 @@
264
  "body": "We will mark this as resolved as issues impacting our service have been resolved either through mitigation or upstream provider resolution. While some of our dependent services have indicated there is on-going stabilization of their own systems (following on the AWS us-east-1 disruptions yesterday) any unresolved items have NO impact to our offerings. In the event that we have new findings or degradations, we will open a new incident.\n\nThank you for your patience while we adapted toward changing circumstances following on yesterday's events, and thank you to teams across the industry who worked (or may still be working) tirelessly toward recovery.",
265
  "first_seen": "2026-09-04T07:06:16Z",
266
  "impact": "minor",
267
- "last_seen": "2026-09-04T09:06:33Z",
268
  "resolved_at": "2025-10-21T10:00:48Z",
269
  "resolved_inferred": false,
270
  "started_at": "2025-10-20T16:56:25Z",
@@ -276,7 +276,7 @@
276
  "body": "As a result of the AWS us-east-1 system recovery, our own systems have also recovered, including AWS Uplink and AWS-hosted Cloud Routers. At this time we will mark this issue as Resolved, though we will continue to monitor for any possible reoccurrence.\n\nAs noted in a previous update, the default configuration for Apollo Router and Apollo Gateway deployments is to roam between Google Cloud Platform (GCP) and Amazon Web Services (AWS) endpoints in the event that one or the other is available. If you have changed your configuration to rely on merely one provider, we recommend considering a configuration with fallback redundancy. Please contact support if you need assistance with this configuration.\n\nAdditionally, our support systems have recovered and we believe any issues opened during the AWS incident have been received by our support teams. If you believe your issue has not been received, please feel free to reach out to our support team again.",
277
  "first_seen": "2026-09-04T07:06:16Z",
278
  "impact": "major",
279
- "last_seen": "2026-09-04T09:06:33Z",
280
  "resolved_at": "2025-10-20T10:39:12Z",
281
  "resolved_inferred": false,
282
  "started_at": "2025-10-20T08:14:38Z",
@@ -288,7 +288,7 @@
288
  "body": "This incident has been resolved.",
289
  "first_seen": "2026-09-04T07:06:16Z",
290
  "impact": "none",
291
- "last_seen": "2026-09-04T09:06:33Z",
292
  "resolved_at": "2025-09-17T11:52:11Z",
293
  "resolved_inferred": false,
294
  "started_at": "2025-09-17T11:05:53Z",
@@ -300,7 +300,7 @@
300
  "body": "This incident has been resolved.",
301
  "first_seen": "2026-09-04T07:06:16Z",
302
  "impact": "critical",
303
- "last_seen": "2026-09-04T09:06:33Z",
304
  "resolved_at": "2025-08-21T21:22:06Z",
305
  "resolved_inferred": false,
306
  "started_at": "2025-08-21T22:06:05Z",
 
3
  "slug": "apollo",
4
  "platform": "statuspage",
5
  "status_url": "http://status.apollographql.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Our third party vendor has confirmed the issue is now resolved, and all Apollo products have recovered.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-01T20:18:54Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T15:41:44Z",
 
24
  "body": "The fix has been deployed. These failed operations would have appeared as rate limit errors, but the rate limit was being incorrectly applied. We have made changes to ensure the rate limit works as expected.",
25
  "first_seen": "2026-09-04T07:06:16Z",
26
  "impact": "major",
27
+ "last_seen": "2026-09-04T10:17:20Z",
28
  "resolved_at": "2026-08-26T23:36:51Z",
29
  "resolved_inferred": false,
30
  "started_at": "2026-08-26T22:12:39Z",
 
36
  "body": "The issue has been resolved.",
37
  "first_seen": "2026-09-04T07:06:16Z",
38
  "impact": "minor",
39
+ "last_seen": "2026-09-04T10:17:20Z",
40
  "resolved_at": "2026-08-11T23:19:08Z",
41
  "resolved_inferred": false,
42
  "started_at": "2026-08-11T19:11:37Z",
 
48
  "body": "The issue has been fixed.",
49
  "first_seen": "2026-09-04T07:06:16Z",
50
  "impact": "major",
51
+ "last_seen": "2026-09-04T10:17:20Z",
52
  "resolved_at": "2026-08-05T10:08:58Z",
53
  "resolved_inferred": false,
54
  "started_at": "2026-08-05T09:43:26Z",
 
60
  "body": "The error rate for Proposals has returned to normal, no further impact expected.",
61
  "first_seen": "2026-09-04T07:06:16Z",
62
  "impact": "minor",
63
+ "last_seen": "2026-09-04T10:17:20Z",
64
  "resolved_at": "2026-07-09T18:09:55Z",
65
  "resolved_inferred": false,
66
  "started_at": "2026-07-09T15:41:29Z",
 
72
  "body": "The backlock of schema coordinate (object field, input object field, and enum value) metrics has now cleared and there is no more metric ingestion delay. The metrics for input object fields, enum values, and the operation and client breakdown of object fields is inaccurate for June 27 4-5am and 8-9pm, and missing between 5am to 8pm (all times in UTC). All other metrics were not impacted.",
73
  "first_seen": "2026-09-04T07:06:16Z",
74
  "impact": "major",
75
+ "last_seen": "2026-09-04T10:17:20Z",
76
  "resolved_at": "2026-06-28T20:16:19Z",
77
  "resolved_inferred": false,
78
  "started_at": "2026-06-28T03:13:19Z",
 
84
  "body": "The metric ingestion backlog has been fully processed and all metrics have resumed normal ingestion. We do not believe any data was lost as a result of this incident. All metric types should now be operating as expected. Thank you for your patience throughout this incident.",
85
  "first_seen": "2026-09-04T07:06:16Z",
86
  "impact": "minor",
87
+ "last_seen": "2026-09-04T10:17:20Z",
88
  "resolved_at": "2026-06-15T22:16:12Z",
89
  "resolved_inferred": false,
90
  "started_at": "2026-06-15T14:38:25Z",
 
96
  "body": "After extended monitoring, we have confirmed that the issue is resolved. Post-incident action items will continue after the end of the incident. As with all incidents, we will be conducting an internal post-mortem. We appreciate your patience.",
97
  "first_seen": "2026-09-04T07:06:16Z",
98
  "impact": "none",
99
+ "last_seen": "2026-09-04T10:17:20Z",
100
  "resolved_at": "2026-06-01T11:39:54Z",
101
  "resolved_inferred": false,
102
  "started_at": "2026-06-01T08:35:25Z",
 
108
  "body": "The issue affecting the visibility of the \u201cSubmit a Request\u201d and \u201cMy Requests\u201d buttons in the Apollo Support Portal has been resolved.\nPortal functionality has been restored, and users should now be able to access these options normally.\nThank you for your patience while we worked to resolve this issue.",
109
  "first_seen": "2026-09-04T07:06:16Z",
110
  "impact": "none",
111
+ "last_seen": "2026-09-04T10:17:20Z",
112
  "resolved_at": "2026-05-26T12:58:43Z",
113
  "resolved_inferred": false,
114
  "started_at": "2026-05-25T19:50:43Z",
 
120
  "body": "We have observed sustained restored functionality in our Studio-initiated support ticket form and are marking this as fully resolved.",
121
  "first_seen": "2026-09-04T07:06:16Z",
122
  "impact": "none",
123
+ "last_seen": "2026-09-04T10:17:20Z",
124
  "resolved_at": "2026-04-27T10:29:10Z",
125
  "resolved_inferred": false,
126
  "started_at": "2026-04-27T08:34:51Z",
 
132
  "body": "We have resolved the issue. Customers should see full functionality.",
133
  "first_seen": "2026-09-04T07:06:16Z",
134
  "impact": "none",
135
+ "last_seen": "2026-09-04T10:17:20Z",
136
  "resolved_at": "2026-04-24T20:53:27Z",
137
  "resolved_inferred": false,
138
  "started_at": "2026-04-24T19:27:20Z",
 
144
  "body": "SSO login is now fixed.",
145
  "first_seen": "2026-09-04T07:06:16Z",
146
  "impact": "critical",
147
+ "last_seen": "2026-09-04T10:17:20Z",
148
  "resolved_at": "2026-04-21T17:47:38Z",
149
  "resolved_inferred": false,
150
  "started_at": "2026-04-21T17:05:47Z",
 
156
  "body": "Proposals errors have been clear for ~2 hours since the rollback reached prod. Marking resolved.",
157
  "first_seen": "2026-09-04T07:06:16Z",
158
  "impact": "minor",
159
+ "last_seen": "2026-09-04T10:17:20Z",
160
  "resolved_at": "2026-04-16T15:43:07Z",
161
  "resolved_inferred": false,
162
  "started_at": "2026-04-16T12:45:07Z",
 
168
  "body": "Retries of delayed transaction emails have been successful. If you have not received an email you were expecting for account reasons, we suggest retrying the workflow which triggered the email.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-03-31T07:39:56Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-03-31T06:59:02Z",
 
180
  "body": "We've identified an issue where our metrics ingestion pipeline was falling behind for several hours. Systems have now fully recovered and no data was lost, however some customers may have experienced delays viewing insights data in Studio and / or slower page load times during this event. Apologies for the interruption.",
181
  "first_seen": "2026-09-04T07:06:16Z",
182
  "impact": "none",
183
+ "last_seen": "2026-09-04T10:17:20Z",
184
  "resolved_at": "2026-02-10T16:00:00Z",
185
  "resolved_inferred": false,
186
  "started_at": "2026-02-12T06:06:22Z",
 
192
  "body": "The issue has been resolved.",
193
  "first_seen": "2026-09-04T07:06:16Z",
194
  "impact": "minor",
195
+ "last_seen": "2026-09-04T10:17:20Z",
196
  "resolved_at": "2025-11-21T21:25:39Z",
197
  "resolved_inferred": false,
198
  "started_at": "2025-11-21T18:05:32Z",
 
204
  "body": "There was a period of degraded performance on schema publishing. The root cause has been identified and service restored.",
205
  "first_seen": "2026-09-04T07:06:16Z",
206
  "impact": "none",
207
+ "last_seen": "2026-09-04T10:17:20Z",
208
  "resolved_at": "2025-11-18T17:30:00Z",
209
  "resolved_inferred": false,
210
  "started_at": "2025-11-18T19:06:04Z",
 
216
  "body": "We are marking this incident resolved on the Apollo side.\n\nFor any continuing matters, please consult our support portal: https://support.apollographql.com/",
217
  "first_seen": "2026-09-04T07:06:16Z",
218
  "impact": "major",
219
+ "last_seen": "2026-09-04T10:17:20Z",
220
  "resolved_at": "2025-11-18T15:38:24Z",
221
  "resolved_inferred": false,
222
  "started_at": "2025-11-18T13:05:25Z",
 
228
  "body": "Cloud Routers are experiencing elevated errors due to an upstream external provider incident.",
229
  "first_seen": "2026-09-04T07:06:16Z",
230
  "impact": "none",
231
+ "last_seen": "2026-09-04T10:17:20Z",
232
  "resolved_at": "2025-11-18T12:30:00Z",
233
  "resolved_inferred": false,
234
  "started_at": "2025-11-18T13:05:25Z",
 
240
  "body": "We've confirmed that the issue with federation versions 2.9, 2.10, and 2.11 is resolved.",
241
  "first_seen": "2026-09-04T07:06:16Z",
242
  "impact": "major",
243
+ "last_seen": "2026-09-04T10:17:20Z",
244
  "resolved_at": "2025-11-05T15:12:28Z",
245
  "resolved_inferred": false,
246
  "started_at": "2025-11-05T14:05:49Z",
 
252
  "body": "No schema publishing or checks issues have been observed for couple of hours now. We are continuing to monitor our services in relation to the AWS outage today on the other open incident.",
253
  "first_seen": "2026-09-04T07:06:16Z",
254
  "impact": "minor",
255
+ "last_seen": "2026-09-04T10:17:20Z",
256
  "resolved_at": "2025-10-21T05:26:55Z",
257
  "resolved_inferred": false,
258
  "started_at": "2025-10-20T21:06:09Z",
 
264
  "body": "We will mark this as resolved as issues impacting our service have been resolved either through mitigation or upstream provider resolution. While some of our dependent services have indicated there is on-going stabilization of their own systems (following on the AWS us-east-1 disruptions yesterday) any unresolved items have NO impact to our offerings. In the event that we have new findings or degradations, we will open a new incident.\n\nThank you for your patience while we adapted toward changing circumstances following on yesterday's events, and thank you to teams across the industry who worked (or may still be working) tirelessly toward recovery.",
265
  "first_seen": "2026-09-04T07:06:16Z",
266
  "impact": "minor",
267
+ "last_seen": "2026-09-04T10:17:20Z",
268
  "resolved_at": "2025-10-21T10:00:48Z",
269
  "resolved_inferred": false,
270
  "started_at": "2025-10-20T16:56:25Z",
 
276
  "body": "As a result of the AWS us-east-1 system recovery, our own systems have also recovered, including AWS Uplink and AWS-hosted Cloud Routers. At this time we will mark this issue as Resolved, though we will continue to monitor for any possible reoccurrence.\n\nAs noted in a previous update, the default configuration for Apollo Router and Apollo Gateway deployments is to roam between Google Cloud Platform (GCP) and Amazon Web Services (AWS) endpoints in the event that one or the other is available. If you have changed your configuration to rely on merely one provider, we recommend considering a configuration with fallback redundancy. Please contact support if you need assistance with this configuration.\n\nAdditionally, our support systems have recovered and we believe any issues opened during the AWS incident have been received by our support teams. If you believe your issue has not been received, please feel free to reach out to our support team again.",
277
  "first_seen": "2026-09-04T07:06:16Z",
278
  "impact": "major",
279
+ "last_seen": "2026-09-04T10:17:20Z",
280
  "resolved_at": "2025-10-20T10:39:12Z",
281
  "resolved_inferred": false,
282
  "started_at": "2025-10-20T08:14:38Z",
 
288
  "body": "This incident has been resolved.",
289
  "first_seen": "2026-09-04T07:06:16Z",
290
  "impact": "none",
291
+ "last_seen": "2026-09-04T10:17:20Z",
292
  "resolved_at": "2025-09-17T11:52:11Z",
293
  "resolved_inferred": false,
294
  "started_at": "2025-09-17T11:05:53Z",
 
300
  "body": "This incident has been resolved.",
301
  "first_seen": "2026-09-04T07:06:16Z",
302
  "impact": "critical",
303
+ "last_seen": "2026-09-04T10:17:20Z",
304
  "resolved_at": "2025-08-21T21:22:06Z",
305
  "resolved_inferred": false,
306
  "started_at": "2025-08-21T22:06:05Z",
api/v/appen.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "appen",
4
  "platform": "statuspage",
5
  "status_url": "https://status.appen.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2025-09-11T02:58:10.818-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2025-09-11T02:54:11.921-07:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2025-09-11T02:34:03.272-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2025-09-11T02:30:07.226-07:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2025-09-11T02:04:37.358-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2025-09-11T02:03:13.955-07:00",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2025-09-09T07:28:41.403-07:00",
56
  "resolved_inferred": false,
57
  "started_at": "2025-09-09T07:16:25.464-07:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2025-09-09T07:11:25.289-07:00",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-09T07:10:57.630-07:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "major",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-09-09T07:07:07.621-07:00",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-09T06:54:11.145-07:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-09-09T07:29:22.253-07:00",
95
  "resolved_inferred": false,
96
  "started_at": "2025-09-09T06:47:06.876-07:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2025-09-02T07:06:22.869-07:00",
108
  "resolved_inferred": false,
109
  "started_at": "2025-09-02T04:20:55.634-07:00",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2025-09-02T07:06:40.053-07:00",
121
  "resolved_inferred": false,
122
  "started_at": "2025-09-02T04:17:53.174-07:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-09-02T07:07:00.897-07:00",
134
  "resolved_inferred": false,
135
  "started_at": "2025-09-02T04:04:32.005-07:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-09-02T07:07:16.984-07:00",
147
  "resolved_inferred": false,
148
  "started_at": "2025-09-02T03:54:29.511-07:00",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-09-02T07:07:31.486-07:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-09-02T03:53:00.479-07:00",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-09-02T07:07:45.175-07:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-09-02T02:48:51.611-07:00",
 
3
  "slug": "appen",
4
  "platform": "statuspage",
5
  "status_url": "https://status.appen.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2025-09-11T02:58:10.818-07:00",
17
  "resolved_inferred": false,
18
  "started_at": "2025-09-11T02:54:11.921-07:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2025-09-11T02:34:03.272-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2025-09-11T02:30:07.226-07:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2025-09-11T02:04:37.358-07:00",
43
  "resolved_inferred": false,
44
  "started_at": "2025-09-11T02:03:13.955-07:00",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2025-09-09T07:28:41.403-07:00",
56
  "resolved_inferred": false,
57
  "started_at": "2025-09-09T07:16:25.464-07:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2025-09-09T07:11:25.289-07:00",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-09T07:10:57.630-07:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "major",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-09-09T07:07:07.621-07:00",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-09T06:54:11.145-07:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-09-09T07:29:22.253-07:00",
95
  "resolved_inferred": false,
96
  "started_at": "2025-09-09T06:47:06.876-07:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "critical",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2025-09-02T07:06:22.869-07:00",
108
  "resolved_inferred": false,
109
  "started_at": "2025-09-02T04:20:55.634-07:00",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2025-09-02T07:06:40.053-07:00",
121
  "resolved_inferred": false,
122
  "started_at": "2025-09-02T04:17:53.174-07:00",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-09-02T07:07:00.897-07:00",
134
  "resolved_inferred": false,
135
  "started_at": "2025-09-02T04:04:32.005-07:00",
 
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-09-02T07:07:16.984-07:00",
147
  "resolved_inferred": false,
148
  "started_at": "2025-09-02T03:54:29.511-07:00",
 
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-09-02T07:07:31.486-07:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-09-02T03:53:00.479-07:00",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "none",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-09-02T07:07:45.175-07:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-09-02T02:48:51.611-07:00",
api/v/appriver.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "appriver",
4
  "platform": "statuspage",
5
  "status_url": "https://status.appriver.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "unknown",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "appriver",
4
  "platform": "statuspage",
5
  "status_url": "https://status.appriver.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "unknown",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/appsflyer.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "appsflyer",
4
  "platform": "statuspage",
5
  "status_url": "https://status.appsflyer.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Some of our services were impacted by a DNS issue between 14:35 and 15:35 UTC.\nDuring this time: clicks and impressions processing was delayed, which resulted in a temporary increase in organic attribution; the Onelink API was partially available; and some processed events are missing geo data.\nThe issue has been fully resolved.\nPlease contact our support team with any questions.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-07-27T16:53:33.075Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-27T15:08:43.785Z",
@@ -25,7 +25,7 @@
25
  "body": "We are seeing significantly fewer reports related to domain mapping and expect the DNS propagation process to complete in the coming hours. \nWe are marking this incident as resolved.\nIf you have any questions or need assistance, our team is available to help.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-03-12T12:34:39.082Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-03-10T04:09:46.425Z",
@@ -38,7 +38,7 @@
38
  "body": "Dashboard availability has been fully restored.\nOur teams continue to monitor performance.\nIf you encounter any further issues, please contact Technical Support.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-02-10T22:46:14.478Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-02-10T21:08:17.899Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-01-26T21:03:55.639Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-01-25T09:35:49.000Z",
@@ -64,7 +64,7 @@
64
  "body": "Meta API availability has returned to normal, and we continue to monitor conversion rates closely.\nWe will update this page if any further anomalies occur.\nThank you for your patience.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2025-12-17T05:57:50.808Z",
69
  "resolved_inferred": false,
70
  "started_at": "2025-12-16T15:39:58.049Z",
@@ -77,7 +77,7 @@
77
  "body": "Our teams reprocessed engagements from approximately 10:25 AM UTC to 11:15 AM UTC, and those engagements are now available for new conversions. \nThank you for your patience, and please contact us for any related questions.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-10-26T15:02:09.720Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-10-26T11:14:46.505Z",
@@ -90,7 +90,7 @@
90
  "body": "Meta API availability has returned to normal, and we continue to monitor conversion rates closely.\nWe will update this page if any further anomalies occur.\nThank you for your patience.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-09-20T11:33:56.101Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-09-20T07:12:27.000Z",
@@ -103,7 +103,7 @@
103
  "body": "The Push API delay issue is resolved. The backlog of events not sent since 01:07 UTC is now being delivered and will clear over the next few hours. We\u2019re monitoring until completion.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2025-08-20T14:27:24.072Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-08-20T14:14:34.119Z",
@@ -116,7 +116,7 @@
116
  "body": "We can confirm that the issue is now resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2025-08-05T10:55:05.830Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-08-05T10:33:34.882Z",
@@ -129,7 +129,7 @@
129
  "body": "The issue has been resolved and the cost, clicks and impressions data is now available in all the reports and dashboards",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-08-02T13:20:01.265Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-08-01T19:05:52.821Z",
 
3
  "slug": "appsflyer",
4
  "platform": "statuspage",
5
  "status_url": "https://status.appsflyer.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Some of our services were impacted by a DNS issue between 14:35 and 15:35 UTC.\nDuring this time: clicks and impressions processing was delayed, which resulted in a temporary increase in organic attribution; the Onelink API was partially available; and some processed events are missing geo data.\nThe issue has been fully resolved.\nPlease contact our support team with any questions.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-07-27T16:53:33.075Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-27T15:08:43.785Z",
 
25
  "body": "We are seeing significantly fewer reports related to domain mapping and expect the DNS propagation process to complete in the coming hours. \nWe are marking this incident as resolved.\nIf you have any questions or need assistance, our team is available to help.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-03-12T12:34:39.082Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-03-10T04:09:46.425Z",
 
38
  "body": "Dashboard availability has been fully restored.\nOur teams continue to monitor performance.\nIf you encounter any further issues, please contact Technical Support.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-02-10T22:46:14.478Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-02-10T21:08:17.899Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-01-26T21:03:55.639Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-01-25T09:35:49.000Z",
 
64
  "body": "Meta API availability has returned to normal, and we continue to monitor conversion rates closely.\nWe will update this page if any further anomalies occur.\nThank you for your patience.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2025-12-17T05:57:50.808Z",
69
  "resolved_inferred": false,
70
  "started_at": "2025-12-16T15:39:58.049Z",
 
77
  "body": "Our teams reprocessed engagements from approximately 10:25 AM UTC to 11:15 AM UTC, and those engagements are now available for new conversions. \nThank you for your patience, and please contact us for any related questions.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-10-26T15:02:09.720Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-10-26T11:14:46.505Z",
 
90
  "body": "Meta API availability has returned to normal, and we continue to monitor conversion rates closely.\nWe will update this page if any further anomalies occur.\nThank you for your patience.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-09-20T11:33:56.101Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-09-20T07:12:27.000Z",
 
103
  "body": "The Push API delay issue is resolved. The backlog of events not sent since 01:07 UTC is now being delivered and will clear over the next few hours. We\u2019re monitoring until completion.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2025-08-20T14:27:24.072Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-08-20T14:14:34.119Z",
 
116
  "body": "We can confirm that the issue is now resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2025-08-05T10:55:05.830Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-08-05T10:33:34.882Z",
 
129
  "body": "The issue has been resolved and the cost, clicks and impressions data is now available in all the reports and dashboards",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-08-02T13:20:01.265Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-08-01T19:05:52.821Z",
api/v/appwrite.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "appwrite",
4
  "platform": "betterstack",
5
  "status_url": "https://status.appwrite.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "appwrite",
4
  "platform": "betterstack",
5
  "status_url": "https://status.appwrite.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/aptible.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "aptible",
4
  "platform": "statuspage",
5
  "status_url": "https://status.aptible.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-07-27T11:12:00.684-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-27T06:31:04.452-04:00",
@@ -25,7 +25,7 @@
25
  "body": "Following the fixes deployed per the previous update, we have seen stable performance on the LLM Gateway since 7:12 EDT and are resolving the issue.\n\nThe root cause of this issue was a severe performance degradation in 3 specific endpoints:\n\u2022\u00a0`GET /models`\n\u2022\u00a0`GET /v1/models`\n\u2022\u00a0`GET /metadata/models`\n\n...all of which return a list of available models. The performance issue on these endpoints was severe enough to cause significant request queueing and degraded performance for other unaffected endpoints. The fix we deployed added caching on this endpoint to ensure fast responses. Since those fixes have been deployed, we are no longer seeing request queueing or impacts to other LLM Gateway API endpoints.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-07-17T13:04:04.670-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-16T18:31:08.575-04:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-06-23T17:48:13.568-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-06-08T14:28:46.841-04:00",
@@ -51,7 +51,7 @@
51
  "body": "As of 18:42 UTC the upstream provider began to accept log messages again consistently and this issue is now remediated.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-06-03T15:16:20.104-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-06-03T12:02:30.705-04:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-05-08T11:35:02.686-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-05-08T01:02:07.845-04:00",
@@ -77,7 +77,7 @@
77
  "body": "An upstream AWS issue affected infrastructure in a single Availability Zone in us-east-1. During the event, we blocked provisioning into the affected zone and monitored AWS\u2019s recovery efforts.\n\nAWS has since recovered enough of the affected availability zone for the impacted Aptible infrastructure to recover. We have also completed recovery of any Aptible-managed resources that required follow-up action on our side.\n\nAny customers with directly affected resources have been notified of resolution. We are continuing normal platform monitoring, but we are marking this incident as resolved on our end.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-05-08T23:35:54.117-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-05-07T21:05:42.870-04:00",
@@ -90,7 +90,7 @@
90
  "body": "Aptible is aware of CVE-2026-31431, also known as \u201cCopy Fail,\u201d a recently disclosed Linux kernel vulnerability that may allow local privilege escalation under certain conditions [0].\n\nWe have taken action across the Aptible platform to protect all customer workloads against this vulnerability. No customer action is required at this time.\n\nWe will continue to monitor upstream kernel, distribution, and security vendor guidance related to this CVE and will take any additional action if needed.\n\n[0] https://copy.fail/",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-04-29T18:40:43.316-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-04-29T18:40:43.273-04:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-04-18T23:10:17.839-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-04-18T22:03:58.794-04:00",
@@ -116,7 +116,7 @@
116
  "body": "Additional detail about timeline: we observed a relative increase in DNS resolver errors in us-east-1 beginning at approximately 2026-03-17 18:30 UTC. The elevated error rate was intermittent rather than constant, with the most visible clusters occurring from roughly 18:30-18:55 UTC and again from about 20:55-21:40 UTC. Error rates returned to normal shortly after 21:40 UTC.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-03-17T19:33:35.883-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-03-17T18:33:47.740-04:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-12-31T09:49:00.737-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2025-12-31T05:48:35.671-05:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-12-30T12:15:34.065-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2025-12-29T21:14:23.204-05:00",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-12-08T11:52:22.240-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-05T09:39:55.817-05:00",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-11-05T11:07:49.146-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-05T10:59:59.035-05:00",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2025-10-29T17:50:27.460-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-10-29T17:17:17.088-04:00",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "none",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2025-10-28T17:08:52.592-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2025-10-28T13:09:06.240-04:00",
@@ -207,7 +207,7 @@
207
  "body": "AWS has marked the underlying issue in us-east-1 as resolved, and we\u2019ve confirmed continued stability across all EC2-related operations.\n\nAll Aptible operations are functioning normally, and this incident is now closed.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2025-10-20T19:04:19.807-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2025-10-20T07:53:09.171-04:00",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2025-10-20T05:46:00.046-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2025-10-20T03:47:14.947-04:00",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "none",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2025-10-11T23:40:31.265-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2025-10-11T22:30:16.257-04:00",
@@ -246,7 +246,7 @@
246
  "body": "Aptible has reviewed and addressed the Redis vulnerability described in <a href=\"https://redis.io/blog/security-advisory-cve-2025-49844/\" target=\"_blank\">https://redis.io/blog/security-advisory-cve-2025-49844/</a>.\n\nWe have confirmed that all internal Redis instances used in delivering the Aptible platform are secure and have no exploitation path related to this CVE.\n\nFor Aptible customers who do not have their Redis databases publicly exposed, a path to exploitation is similarly unlikely. Additionally, for customers using Redis 6.2 databases on Aptible, a patched version will be available by Oct 10th at 5pm EST, and additional releases (7.2) are upcoming; see <a href=\"https://www.aptible.com/changelog/\" target=\"_blank\">aptible.com/changelog</a> for ongoing release updates. To ensure you are running the latest minor version when available, please run the cli command: aptible db:reload for each Redis database.\n\nFor more information on using this command, visit <a href=\"https://www.aptible.com/docs/reference/aptible-cli/cli-commands/cli-db-reload\" target=\"_blank\">https://www.aptible.com/docs/reference/aptible-cli/cli-commands/cli-db-reload</a>.\n\nIf you have any specific questions or concerns related to this CVE, please <a href=\"https://contact.aptible.com/\" target=\"_blank\">contact us</a>.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2025-10-10T11:53:25.000-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2025-10-10T11:53:25.000-04:00",
@@ -259,7 +259,7 @@
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2025-08-07T10:21:32.490-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-08-07T09:43:14.966-04:00",
 
3
  "slug": "aptible",
4
  "platform": "statuspage",
5
  "status_url": "https://status.aptible.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-07-27T11:12:00.684-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-07-27T06:31:04.452-04:00",
 
25
  "body": "Following the fixes deployed per the previous update, we have seen stable performance on the LLM Gateway since 7:12 EDT and are resolving the issue.\n\nThe root cause of this issue was a severe performance degradation in 3 specific endpoints:\n\u2022\u00a0`GET /models`\n\u2022\u00a0`GET /v1/models`\n\u2022\u00a0`GET /metadata/models`\n\n...all of which return a list of available models. The performance issue on these endpoints was severe enough to cause significant request queueing and degraded performance for other unaffected endpoints. The fix we deployed added caching on this endpoint to ensure fast responses. Since those fixes have been deployed, we are no longer seeing request queueing or impacts to other LLM Gateway API endpoints.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-07-17T13:04:04.670-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-07-16T18:31:08.575-04:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-06-23T17:48:13.568-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-06-08T14:28:46.841-04:00",
 
51
  "body": "As of 18:42 UTC the upstream provider began to accept log messages again consistently and this issue is now remediated.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-06-03T15:16:20.104-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-06-03T12:02:30.705-04:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-05-08T11:35:02.686-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-05-08T01:02:07.845-04:00",
 
77
  "body": "An upstream AWS issue affected infrastructure in a single Availability Zone in us-east-1. During the event, we blocked provisioning into the affected zone and monitored AWS\u2019s recovery efforts.\n\nAWS has since recovered enough of the affected availability zone for the impacted Aptible infrastructure to recover. We have also completed recovery of any Aptible-managed resources that required follow-up action on our side.\n\nAny customers with directly affected resources have been notified of resolution. We are continuing normal platform monitoring, but we are marking this incident as resolved on our end.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-05-08T23:35:54.117-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-05-07T21:05:42.870-04:00",
 
90
  "body": "Aptible is aware of CVE-2026-31431, also known as \u201cCopy Fail,\u201d a recently disclosed Linux kernel vulnerability that may allow local privilege escalation under certain conditions [0].\n\nWe have taken action across the Aptible platform to protect all customer workloads against this vulnerability. No customer action is required at this time.\n\nWe will continue to monitor upstream kernel, distribution, and security vendor guidance related to this CVE and will take any additional action if needed.\n\n[0] https://copy.fail/",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-04-29T18:40:43.316-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-04-29T18:40:43.273-04:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-04-18T23:10:17.839-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-04-18T22:03:58.794-04:00",
 
116
  "body": "Additional detail about timeline: we observed a relative increase in DNS resolver errors in us-east-1 beginning at approximately 2026-03-17 18:30 UTC. The elevated error rate was intermittent rather than constant, with the most visible clusters occurring from roughly 18:30-18:55 UTC and again from about 20:55-21:40 UTC. Error rates returned to normal shortly after 21:40 UTC.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-03-17T19:33:35.883-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-03-17T18:33:47.740-04:00",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "critical",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-12-31T09:49:00.737-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2025-12-31T05:48:35.671-05:00",
 
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-12-30T12:15:34.065-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2025-12-29T21:14:23.204-05:00",
 
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "none",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-12-08T11:52:22.240-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-05T09:39:55.817-05:00",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-11-05T11:07:49.146-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-05T10:59:59.035-05:00",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2025-10-29T17:50:27.460-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-10-29T17:17:17.088-04:00",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "none",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2025-10-28T17:08:52.592-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2025-10-28T13:09:06.240-04:00",
 
207
  "body": "AWS has marked the underlying issue in us-east-1 as resolved, and we\u2019ve confirmed continued stability across all EC2-related operations.\n\nAll Aptible operations are functioning normally, and this incident is now closed.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2025-10-20T19:04:19.807-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2025-10-20T07:53:09.171-04:00",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2025-10-20T05:46:00.046-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2025-10-20T03:47:14.947-04:00",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "none",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2025-10-11T23:40:31.265-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2025-10-11T22:30:16.257-04:00",
 
246
  "body": "Aptible has reviewed and addressed the Redis vulnerability described in <a href=\"https://redis.io/blog/security-advisory-cve-2025-49844/\" target=\"_blank\">https://redis.io/blog/security-advisory-cve-2025-49844/</a>.\n\nWe have confirmed that all internal Redis instances used in delivering the Aptible platform are secure and have no exploitation path related to this CVE.\n\nFor Aptible customers who do not have their Redis databases publicly exposed, a path to exploitation is similarly unlikely. Additionally, for customers using Redis 6.2 databases on Aptible, a patched version will be available by Oct 10th at 5pm EST, and additional releases (7.2) are upcoming; see <a href=\"https://www.aptible.com/changelog/\" target=\"_blank\">aptible.com/changelog</a> for ongoing release updates. To ensure you are running the latest minor version when available, please run the cli command: aptible db:reload for each Redis database.\n\nFor more information on using this command, visit <a href=\"https://www.aptible.com/docs/reference/aptible-cli/cli-commands/cli-db-reload\" target=\"_blank\">https://www.aptible.com/docs/reference/aptible-cli/cli-commands/cli-db-reload</a>.\n\nIf you have any specific questions or concerns related to this CVE, please <a href=\"https://contact.aptible.com/\" target=\"_blank\">contact us</a>.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2025-10-10T11:53:25.000-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2025-10-10T11:53:25.000-04:00",
 
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2025-08-07T10:21:32.490-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-08-07T09:43:14.966-04:00",
api/v/apwide.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "apwide",
4
  "platform": "statuspage",
5
  "status_url": "https://apwide.statuspage.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "We have identified and resolved the root cause of the issue.\nOne of our nodes was unable to perform DNS resolution due to routing errors.\nThe routing issues have now been fixed, and DNS resolution is working correctly.\n\nWe apologize for the inconvenience caused.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-03-10T21:27:10.497+01:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-03-10T20:04:58.869+01:00",
@@ -25,7 +25,7 @@
25
  "body": "**07:23 UTC** \u2013 The support team was alerted by monitoring that some database queries were taking longer than expected.\n\n**07:34 UTC** \u2013 Our uptime probes began raising alerts indicating that Golive was no longer accessible to end users.\n\n**07:46 UTC** \u2013 The support team updated the status page to notify users of a Golive outage.\n\n**08:23 UTC** \u2013 The support team identified an abnormal traffic spike originating from Atlassian webhooks. Under normal conditions, traffic peaks reach around 1,000 webhook calls per minute; however, we experienced a sustained spike exceeding 9,000 calls per minute. This caused one of our components to open more database connections than it was designed to handle, forcing it to restart repeatedly. To protect the Golive application, webhook traffic was temporarily disabled. The component stopped restarting and access to Golive was restored.\n\n**11:20 UTC** \u2013 The engineering team implemented an initial performance improvement on the affected component. The fix was deployed to production, and webhook traffic was re-enabled to evaluate performance.\n\n**11:44 UTC** \u2013 Webhook traffic was suspended again as the initial fix proved insufficient. Although database connections were no longer an issue, the component was still receiving excessive request traffic.\n\n**14:01 UTC** \u2013 A second improvement was implemented, this time at the gateway level. The fix was deployed to production and webhook traffic was re-enabled. No further restarts were observed, and Golive appeared to be fully operational.\n\n**14:45 UTC** \u2013 After several traffic peaks reaching up to 5,000 webhook calls per minute, all components continued to operate normally, with sufficient margins in terms of database connections and execution threads. The incident was closed. \n \nWith the additional performance improvements, the infrastructure now appears capable of handling a significantly higher load than originally designed.\n\nFurthermore, traffic should be better segregated to isolate asynchronous workloads \\(webhooks, conflict checking, automation, etc.\\) from transactional traffic \\(UI application usage\\). This separation should help mitigate the risk of asynchronous traffic impacting normal user navigation.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-02-05T15:56:54.317+01:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-02-05T08:46:30.902+01:00",
@@ -38,7 +38,7 @@
38
  "body": "**Outage Recap**\n\n* **2025-11-05 at 5:56 AM UTC**, our monitoring system began raising alerts indicating that some of our services were unable to communicate with the database.\n* **6:20 AM UTC:** We reported an outage affecting the **Golive** and **Time Squad** services on our status page.\n* **6:26 AM UTC:** We suspected the issue originated from our hosting provider\u2019s managed database service. We contacted their support team and opened a ticket.\n* **6:57 AM UTC:** The hosting provider confirmed the issue on their side and announced a general outage on their platform. [Incident link](https://public-cloud.status-ovhcloud.com/incidents/9qmxv0gbky43)\n* **7:58 AM UTC:** The hosting provider reported that the issue had been resolved. We restarted our **Golive** and **Time Squad** services.\n* **8:19 AM UTC:** All of our services were fully restored, and we updated our status page accordingly.\n* **8:31 AM UTC:** The hosting provider informed us that the root cause was a **DNS issue** on their end.\n\nWe apologize for the inconvenience caused and appreciate your patience and understanding.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2025-11-05T11:07:55.539+01:00",
43
  "resolved_inferred": false,
44
  "started_at": "2025-11-05T07:20:24.892+01:00",
 
3
  "slug": "apwide",
4
  "platform": "statuspage",
5
  "status_url": "https://apwide.statuspage.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "We have identified and resolved the root cause of the issue.\nOne of our nodes was unable to perform DNS resolution due to routing errors.\nThe routing issues have now been fixed, and DNS resolution is working correctly.\n\nWe apologize for the inconvenience caused.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-03-10T21:27:10.497+01:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-03-10T20:04:58.869+01:00",
 
25
  "body": "**07:23 UTC** \u2013 The support team was alerted by monitoring that some database queries were taking longer than expected.\n\n**07:34 UTC** \u2013 Our uptime probes began raising alerts indicating that Golive was no longer accessible to end users.\n\n**07:46 UTC** \u2013 The support team updated the status page to notify users of a Golive outage.\n\n**08:23 UTC** \u2013 The support team identified an abnormal traffic spike originating from Atlassian webhooks. Under normal conditions, traffic peaks reach around 1,000 webhook calls per minute; however, we experienced a sustained spike exceeding 9,000 calls per minute. This caused one of our components to open more database connections than it was designed to handle, forcing it to restart repeatedly. To protect the Golive application, webhook traffic was temporarily disabled. The component stopped restarting and access to Golive was restored.\n\n**11:20 UTC** \u2013 The engineering team implemented an initial performance improvement on the affected component. The fix was deployed to production, and webhook traffic was re-enabled to evaluate performance.\n\n**11:44 UTC** \u2013 Webhook traffic was suspended again as the initial fix proved insufficient. Although database connections were no longer an issue, the component was still receiving excessive request traffic.\n\n**14:01 UTC** \u2013 A second improvement was implemented, this time at the gateway level. The fix was deployed to production and webhook traffic was re-enabled. No further restarts were observed, and Golive appeared to be fully operational.\n\n**14:45 UTC** \u2013 After several traffic peaks reaching up to 5,000 webhook calls per minute, all components continued to operate normally, with sufficient margins in terms of database connections and execution threads. The incident was closed. \n \nWith the additional performance improvements, the infrastructure now appears capable of handling a significantly higher load than originally designed.\n\nFurthermore, traffic should be better segregated to isolate asynchronous workloads \\(webhooks, conflict checking, automation, etc.\\) from transactional traffic \\(UI application usage\\). This separation should help mitigate the risk of asynchronous traffic impacting normal user navigation.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-02-05T15:56:54.317+01:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-02-05T08:46:30.902+01:00",
 
38
  "body": "**Outage Recap**\n\n* **2025-11-05 at 5:56 AM UTC**, our monitoring system began raising alerts indicating that some of our services were unable to communicate with the database.\n* **6:20 AM UTC:** We reported an outage affecting the **Golive** and **Time Squad** services on our status page.\n* **6:26 AM UTC:** We suspected the issue originated from our hosting provider\u2019s managed database service. We contacted their support team and opened a ticket.\n* **6:57 AM UTC:** The hosting provider confirmed the issue on their side and announced a general outage on their platform. [Incident link](https://public-cloud.status-ovhcloud.com/incidents/9qmxv0gbky43)\n* **7:58 AM UTC:** The hosting provider reported that the issue had been resolved. We restarted our **Golive** and **Time Squad** services.\n* **8:19 AM UTC:** All of our services were fully restored, and we updated our status page accordingly.\n* **8:31 AM UTC:** The hosting provider informed us that the root cause was a **DNS issue** on their end.\n\nWe apologize for the inconvenience caused and appreciate your patience and understanding.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2025-11-05T11:07:55.539+01:00",
43
  "resolved_inferred": false,
44
  "started_at": "2025-11-05T07:20:24.892+01:00",
api/v/aqua.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "aqua",
4
  "platform": "statuspage",
5
  "status_url": "https://status.aquasec.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Aqua Supply Chain Vulnerability Scanning Service Disruption Notice - Resolved\n\nSince approximately 09:00 UTC on August 31, 2025, our Supply Chain Vulnerability Scanning service experienced a degradation, causing CI/CD pipeline timeouts and timeouts on the Supply Chain page.\n\nUpdate: The applied fix has been confirmed effective following a period of active monitoring, and the service has returned to normal operation. The Supply Chain Vulnerability Scanning component status has been updated to Operational.\n\nWe apologize for the inconvenience this incident may have caused and thank you for your patience.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-31T19:30:45.477Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-31T17:18:15.683Z",
@@ -25,7 +25,7 @@
25
  "body": "Since approximately 09:00 UTC on August 31, 2025, our Supply Chain Vulnerability Scanning service has been experiencing a degradation. This is currently causing CI/CD pipeline timeouts and timeouts on the Supply Chain page.\n\nOur team is actively investigating and has engaged the relevant internal teams to work toward resolution. We will share updates as they become available. We apologize for any inconvenience this is causing.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-31T13:00:00.000Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-31T13:00:00.000Z",
@@ -38,7 +38,7 @@
38
  "body": "The issues affecting login performance have been mitigated, and services are now operating normally.\nWe continue to monitor the situation to ensure stability.\nThank you for your patience and understanding.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2025-10-21T01:52:41.464Z",
43
  "resolved_inferred": false,
44
  "started_at": "2025-10-20T15:01:36.162Z",
@@ -51,7 +51,7 @@
51
  "body": "On October 1st, 2025, at approximately 08:10 AM UTC, our Container Image Scanning service experienced a performance degradation. This caused the resulting in partial impact on scanning requests.\n\nThe Aqua team promptly identified the issue and engaged the India team for resolution. The incident was mitigated at 08:56 AM UTC on October 1st, 2025.\n\nWe apologize for any inconvenience caused by this disruption. To prevent recurrence, we are enhancing our monitoring and alerting systems and implementing automated remediation measures where possible.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2025-10-01T08:00:00.000Z",
56
  "resolved_inferred": false,
57
  "started_at": "2025-10-01T08:00:00.000Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2025-09-08T10:55:52.972Z",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-08T08:34:31.108Z",
@@ -77,7 +77,7 @@
77
  "body": "The maintenance for the CSPM scanning service has been completed. All systems are fully operational.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "maintenance",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-09-05T03:26:21.907Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-04T19:30:40.000Z",
 
3
  "slug": "aqua",
4
  "platform": "statuspage",
5
  "status_url": "https://status.aquasec.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Aqua Supply Chain Vulnerability Scanning Service Disruption Notice - Resolved\n\nSince approximately 09:00 UTC on August 31, 2025, our Supply Chain Vulnerability Scanning service experienced a degradation, causing CI/CD pipeline timeouts and timeouts on the Supply Chain page.\n\nUpdate: The applied fix has been confirmed effective following a period of active monitoring, and the service has returned to normal operation. The Supply Chain Vulnerability Scanning component status has been updated to Operational.\n\nWe apologize for the inconvenience this incident may have caused and thank you for your patience.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-31T19:30:45.477Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-31T17:18:15.683Z",
 
25
  "body": "Since approximately 09:00 UTC on August 31, 2025, our Supply Chain Vulnerability Scanning service has been experiencing a degradation. This is currently causing CI/CD pipeline timeouts and timeouts on the Supply Chain page.\n\nOur team is actively investigating and has engaged the relevant internal teams to work toward resolution. We will share updates as they become available. We apologize for any inconvenience this is causing.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-31T13:00:00.000Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-31T13:00:00.000Z",
 
38
  "body": "The issues affecting login performance have been mitigated, and services are now operating normally.\nWe continue to monitor the situation to ensure stability.\nThank you for your patience and understanding.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2025-10-21T01:52:41.464Z",
43
  "resolved_inferred": false,
44
  "started_at": "2025-10-20T15:01:36.162Z",
 
51
  "body": "On October 1st, 2025, at approximately 08:10 AM UTC, our Container Image Scanning service experienced a performance degradation. This caused the resulting in partial impact on scanning requests.\n\nThe Aqua team promptly identified the issue and engaged the India team for resolution. The incident was mitigated at 08:56 AM UTC on October 1st, 2025.\n\nWe apologize for any inconvenience caused by this disruption. To prevent recurrence, we are enhancing our monitoring and alerting systems and implementing automated remediation measures where possible.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2025-10-01T08:00:00.000Z",
56
  "resolved_inferred": false,
57
  "started_at": "2025-10-01T08:00:00.000Z",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2025-09-08T10:55:52.972Z",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-08T08:34:31.108Z",
 
77
  "body": "The maintenance for the CSPM scanning service has been completed. All systems are fully operational.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "maintenance",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-09-05T03:26:21.907Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-04T19:30:40.000Z",
api/v/arista-cloudvision.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "arista-cloudvision",
4
  "platform": "statuspage",
5
  "status_url": "https://status.arista.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "A mitigation was put in place and the performance is now stabilized. We will continue to monitor the situation. Thank you",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-01T04:47:56.942Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T03:22:34.450Z",
@@ -25,7 +25,7 @@
25
  "body": "This incident arose from unexpected localized network partitioning due to underlying conditions. Our systems automatically detected the event in <5m of the start of the impact, and began recovery, with minimal manual intervention involved. We are analyzing further hardening against the underlying conditions of this nature.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-28T20:40:36.781Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-28T17:39:57.230Z",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-20T05:09:23.081Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-20T02:54:03.744Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-12T19:03:50.725Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-12T18:51:17.000Z",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-08-13T05:25:27.232Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-12T16:19:38.427Z",
@@ -77,7 +77,7 @@
77
  "body": "The issue has been identified and a mitigation has been put in place. Streaming latencies have returned to their expected level.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-08-06T11:47:35.502Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-06T10:45:23.704Z",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-07-15T21:45:15.101Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-15T21:45:01.991Z",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "major",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-15T03:27:33.953Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-15T01:09:33.713Z",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-07-10T18:46:39.905Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-10T18:25:05.679Z",
@@ -129,7 +129,7 @@
129
  "body": "This issue is resolved. Please follow https://status.arista.io/incidents/5vx7cvb07k7d for postmortem update when it becomes available.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-07-13T23:54:59.538Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-07-07T22:58:26.134Z",
@@ -142,7 +142,7 @@
142
  "body": "**Incident Report: CVaaS Service Disruption - June 26th, 2026**\n\nOn June 26th, 2026 10:00AM PDT - 12:30PM PDT CVaaS service region cv-prod-us-central1-b experienced significant ingestion delay into NetDL that caused the following incorrect states to be observed by users:\n\n* Devices incorrectly marked as Inactive,\n* Multiple inactionable \u201cDevice Stopped Streaming\u201d events,\n* Multiple inactionable \u201cHigh Streaming Latency\u201d events\n\nDuring this time period, executing device provisioning actions may have been delayed or failed. There was no data loss. However, data ingested from actively streaming devices into CVaaS may have only become accessible after some delay. This may have impacted users accessing the UI, or other services consuming that data from CloudVision via API integrations. \n\nBetween June 26, 2026 12:30PM PDT - June 27th, 12:30PM PDT, some users may have experienced the above behaviors intermittently impact their devices, but not block device provisioning activities.\n\nBy June 27th, 2026, all mitigations were in place, and we transitioned to mitigating intermittent instances of elevated tail latency along the data ingestion path into NetDL. Between June 27th, 2026 and July 6th, 2026 a small subset of users of the cv-prod-us-central1-b service region may have experienced rare, but intermittent instances where CloudVision reported Event \u201cHigh Streaming Latency\u201d, potentially due to brief delays in NetDL ingestion. Users were not blocked from performing device provisioning activities.\n\n\u200c\n\n**Root Cause**\n\nNetwork performance degradation and instabilities in our underlying cloud provider were the ultimate root causes of delays ingesting data into the part of the system responsible for storing, processing, and updating device streaming status and streaming latency. Our mitigation activities between June 26th, 2026 and June 27th, 2026 stabilized the vast majority of the impact, but the changing underlying conditions prolonged the total duration of incident. This incident was not caused by software change\\(s\\), monitoring gaps, or software bugs in CloudVision as-a-Service.\n\n\u200c\n\n**Our Response**\n\nMultiple teams at Arista engaged around the clock from June 26th, 2026 until July 6th, 2026 to ensure we fully resolved this incident, as well as reviewed all details in our internal reviews. We continue to actively monitor this service region, as well as all of our CloudVision as-a-Service service regions.\n\nArista takes full responsibility for the performance and availability of the service regardless of the underlying cloud platform conditions. We are committed to making changes in both the short and long term that will provide greater resilience to underlying provider instabilities and changing real-time conditions.\n\nThank you for using CloudVision as-a-Service.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-07-07T22:57:18.224Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-06-26T17:27:17.754Z",
@@ -155,7 +155,7 @@
155
  "body": "We identified the source of the problem and the data ingestion latency has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-06-10T16:03:13.608Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-06-10T11:48:01.850Z",
@@ -168,7 +168,7 @@
168
  "body": "**Incident Report: CVaaS Service Disruption - May 29, 2026**\n\nOn May 29th, 2026, CloudVision as-a-Service delivered a software change for a set of services that provide the Network Provisioning workflows in the product. All services regions were impacted by this Network Provisioning feature update.\u00a0\n\nThis update introduced a critical bug across all service regions. As a result, customers utilizing the Network Provisioning workflows \\(see [https://www.arista.io/help/articles/provisioning-network-provisioning#network-provisioning](https://www.arista.io/help/articles/provisioning-network-provisioning#network-provisioning)\\) may have experienced instances where devices were mapped to the incorrect containers in the network provisioning hierarchy, creating a risk that unintended configuration states could be applied if customers then attempted to roll out additional changes to devices. The Network Provisioning workflows were disabled while we recovered from the issue, meaning that customers could not make any changes to their network configuration during this time.\n\nCustomers only defining their network configuration using Studios workflows \\(see [https://www.arista.io/help/articles/provisioning-studios](https://www.arista.io/help/articles/provisioning-studios)\\) were not impacted.\n\nThe software change that caused this issue was rolled back on May 29th, 2026. The delay in mitigation was due to gaps in our automated monitoring systems.\n\nFAQ:\n\n* _Did this bug cause a network outage for customers?_ No.\n* _Was there any data loss?_ No.\n* Was overall CloudVision service availability impacted?No.\n* _Are there any additional steps to recovery?_ No; the vast majority of impacted customers were recovered without requiring customer intervention. At this moment if you have not been directly contacted by us, no further action is required from you.\n\n\u200c\n\n**Root Cause**\n\nThe bug was due to logic applied to an incorrect data state within the Network Provisioning feature. This caused an incorrect device container mapping during the device state reconciliation phase. This was not caught during testing or during the post deployment evaluation phase in various environments prior to being released to production. Additionally, the rollout strategy used in the continuous delivery applicable for this particular set of services allowed the bug to propagate quickly across all CloudVision as-a-Service regions.\n\n\u200c\n\n**Our Response**\n\nOnce the bug was identified on May 29th, 2026, our team rolled back the update responsible within approximately a five hour period on all production regions. In addition, API usage restrictions were established as a protective measure against customers that may inadvertently execute a configuration change on their network without knowledge of this bug and device state change. Between May 29th and June 1st, 2026, our team engaged in continuous efforts to restore services for all affected customers and devices. The majority of these recovery operations were successfully concluded by May 30th, 2026. Throughout this period, we maintained regular updates on Statuspage to keep our customers informed regarding our progress.\n\nWe understand a disruption of this nature is unacceptable for our customers. We are conducting a full review of design, testing, validation, delivery, monitoring, and incident response as part of the postmortem review, and we are committed to ensuring we do not run into incidents of this nature in the future.\u00a0\n\nThank you for using CloudVision as-a-Service.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-06-04T00:50:38.220Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-29T20:24:49.338Z",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-05-29T21:02:17.763Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-29T17:45:17.916Z",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved. We will follow up with a postmortem.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-05-27T01:02:39.759Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-05-26T15:38:23.965Z",
@@ -207,7 +207,7 @@
207
  "body": "We experienced high device streaming latency on this affected cluster. \n\nSome impact may be user visible, such as:\n- A delay in processing streamed device data. Some events such as \"Device stopped streaming\" or \"Streaming Latency Breached Threshold\" may fire as a result of this. In this case, the device updates are behind schedule and will be processed with some delay during the impact window.\n- There may be some stale data, or sporadic timeouts viewing parts of the UI.\n- Some provisioning features may be delayed or timeout due to the high latency.\n\nThis was due to an internal component upgrade in our cloud environment; we continue to work on decreasing the impact of this upgrade process. Thank you for your patience.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-05-18T13:35:22.839Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-05-18T13:35:22.776Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "major",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-05-15T17:30:14.843Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-05-15T17:24:21.000Z",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-04-15T12:34:33.103Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-04-15T12:04:42.879Z",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-03-19T00:57:11.179Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-19T00:38:53.548Z",
@@ -259,7 +259,7 @@
259
  "body": "The fix has been successfully deployed to all regions. Customers will have to reload the UI for the changes to take effect.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-03-12T21:57:50.933Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-12T15:33:08.562Z",
@@ -272,7 +272,7 @@
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-03-04T06:43:05.682Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-03-04T05:23:36.000Z",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-03-03T04:31:27.923Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-03-03T04:15:47.058Z",
@@ -298,7 +298,7 @@
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-02-17T16:54:04.498Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-02-13T01:30:08.000Z",
@@ -311,7 +311,7 @@
311
  "body": "**Incident Report: Platform Outage - January 31st, 2026**\n\nOn January 31, 2026, CloudVision as-a-Service experienced a platform-wide incident within the cv-prod-us-central1-a region that lasted a total of 1 hour and 18 minutes. During the first hour of this window, the platform remained operational despite intermittent connectivity disruptions that impacted <1% of total traffic. In the final 18 minutes of the incident, traffic loss increased to approximately 2%. During this period, users likely experienced a gradual loss of connectivity and platform access. This included disruptions to device streaming, where devices may have started to coalesce data to resume streaming once platform stabilized, which is the standard failure-mode behavior designed to preserve data integrity during network instability.\n\nThis incident was not the result of a security breach, unauthorized intrusion, or any malicious activity.\n\n\u200c\n\n**Root Cause**\n\nThe root cause of this disruption was identified as a catastrophic networking loss within our third-party cloud infrastructure provider.\n\n\u200c\n\n**Our Response**\n\nOur team detected the outage within five minutes of the initial failure and remained in constant communication with the provider to manage triage, recovery, and remediation efforts. During the incident, we made the strategic decision not to initiate a full site disaster recovery. Our technical assessment concluded that a full failover would have been significantly more disruptive to the user experience and would have ultimately prolonged the duration of the incident.\n\n\u200c\n\nWe understand that any service interruption is an unacceptable outcome for our users. We are currently working on internal initiatives to make our architecture more resilient to these specific modes of failure while simultaneously partnering with our cloud provider to ensure better stability of the underlying infrastructure.\n\n\u200c\n\nWe appreciate your patience and your continued use of CloudVision as-a-Service.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-01-31T01:42:31.826Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-01-31T00:16:11.984Z",
@@ -324,7 +324,7 @@
324
  "body": "**Incident Report: Login By Email Service Outage - January 30th, 2026**\n\nOn January 30, 2026, CloudVision as-a-Service experienced a service outage affecting the \"Login By Email\" functionality lasting 2 hours and 36 minutes. During this window, customers attempting to access their accounts using Login By Email failed to receive the invitation emails. This incident was isolated strictly to the Login By Email service; SSO and SAML based login remained fully operational.\n\nThere was no data loss or compromise of customer information. This outage was not the result of a security breach, unauthorized intrusion, or any malicious activity.\n\n**Root Cause**\n\nOur investigation identified a gap in monitoring for a critical third-party integration. Because this specific telemetry was missing, early warning signals were missed, leading to the eventual service disruption. Additionally, we identified internal process failures that contributed to the duration of the outage.\n\n**Our Response**\n\nInternal escalation protocols successfully engaged subject matter experts within 30 minutes of the first reported case. Initial delays in resolution were primarily due to various process failures including delays in required coordination with third party vendor. We are implementing the missing monitoring triggers for third-party integrations to ensure early detection, as well as reviewing our processes as part of various fixes we are addressing.\n\nWe understand that any service disruption is impactful. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again.\n\nThank you for using CloudVision as-a-Service.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-01-30T16:05:26.723Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-01-30T14:36:34.310Z",
@@ -337,7 +337,7 @@
337
  "body": "Telemetry was delayed for up to 30 minutes due to an disruptive infrastructure reconfiguration. The incident has now been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-01-23T12:13:47.702Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-01-23T09:28:30.595Z",
@@ -350,7 +350,7 @@
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "none",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-01-15T23:49:30.238Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-01-15T20:53:52.525Z",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "none",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-01-13T00:11:03.157Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-01-12T21:48:47.442Z",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "none",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-12-19T22:17:01.161Z",
381
  "resolved_inferred": false,
382
  "started_at": "2025-12-19T17:22:14.735Z",
@@ -389,7 +389,7 @@
389
  "body": "Closing this courtesy notice.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "none",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-12-09T23:59:34.329Z",
394
  "resolved_inferred": false,
395
  "started_at": "2025-12-09T17:42:18.000Z",
@@ -402,7 +402,7 @@
402
  "body": "Hello CloudVision as a Service customers,\n\nWe have identified an issue impacting a small subset of customers where all EOS devices in a tenant were incorrectly marked as inactive. Importantly, the devices were actively streaming and all data and telemetry were generated and stored correctly.\n\nImpacted customers may have observed this incorrect streaming status displayed for several consecutive hours or days since November 25th, 2025. \n\nWe have identified the root cause and deployed an immediate fix. There is no action required from you as the customer. This is a courtesy notice only.\n\nIf you have any questions about this issue or if your tenant was affected, please reach out to support@arista.com.\n\nThank you for being a valued CloudVision as a Service customer.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "none",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-12-08T23:57:38.551Z",
407
  "resolved_inferred": false,
408
  "started_at": "2025-12-08T23:57:38.505Z",
@@ -415,7 +415,7 @@
415
  "body": "The data processing pipeline has fully recovered, and the service is now operating in a healthy state.\n\nThe ingestion of device telemetry data was not impacted during the incident. There was no data loss.\n\nPostmortem for this incident is still pending. Our team is currently actively working on reviewing this incident, and postmortem update.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "major",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-10-12T14:15:00.312Z",
420
  "resolved_inferred": false,
421
  "started_at": "2025-10-12T11:05:27.234Z",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "none",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-09-16T19:01:13.690Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-09-16T18:38:05.616Z",
@@ -441,7 +441,7 @@
441
  "body": "This incident is resolved",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "none",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-09-11T23:17:38.156Z",
446
  "resolved_inferred": false,
447
  "started_at": "2025-09-11T18:00:35.380Z",
@@ -454,7 +454,7 @@
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "none",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-09-11T00:32:19.636Z",
459
  "resolved_inferred": false,
460
  "started_at": "2025-09-10T23:18:33.114Z",
@@ -467,7 +467,7 @@
467
  "body": "**Incident Report: CVaaS Service Disruption - September 8, 2025** \nOn September 8, 2025, CloudVision as-a-Service experienced a service disruption, lasting from 8 minutes in our UK region \\(cv-prod-uk-1\\) to 25 minutes in a US region \\(us-central1-a\\). During this time, users were unable to establish new connections, and transient connection errors occurred for those with existing connections.\n\nWe do not expect any data loss, as device state streaming was coalesced and resumed after the disruption. This incident was not caused by a security breach, intrusion, or other malicious activity.\n\n\u200c\n\n**Root Cause**\n\nAn internal certificate expired within our trust chain, causing a disruption. The certificate was not properly monitored in our system, which notifies and automatically renews certificates, leading to its expiration.\n\n\u200c\n\n**Our Response**\n\nOur team was alerted to similar service disruptions across various global regions, and a status page incident was posted because the issue was not transient and was unrelated to our service provider. The disruption was triaged, the root cause identified, and mitigations implemented within 20 minutes. Corrective actions were taken simultaneously over the next approximately 35 minutes. The incident was closed after an assessment of all regions was completed, and services were restored.\n\nWe understand that an outage of this nature is unacceptable and apologize to all affected CloudVision as-a-Service users impacted by this incident. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again.\n\nThank you for using CloudVision as-a-Service.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "critical",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-09-08T15:35:04.842Z",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-08T12:56:47.000Z",
@@ -480,7 +480,7 @@
480
  "body": "## **Incident Report: CVaaS Service Disruption - September 1, 2025**\n\nOn September 1, 2025, CloudVision as-a-Service region cv-prod-euwest-2 experienced a disruption that lasted 2h. During this time some devices may have experienced state update becoming visible to be delayed up to those 2h. There was no data loss of device state. This incident was not due to a security breach, intrusion, or otherwise malicious activity.\u200c\n\n**Root Cause**\n\nThe root cause of this incident was caused by residual impact that was as described [in this incident](https://status.arista.io/incidents/7bcj2khfpqcy). Please find further details of root cause, and our response as described in this linked post.\n\nThank you for using CloudVision as-a-Service.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "none",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-09-02T05:38:02.043Z",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-02T03:38:10.444Z",
@@ -493,7 +493,7 @@
493
  "body": "## **Incident Report: CVaaS Service Disruption - September 1, 2025**\n\nOn September 1, 2025, CloudVision as-a-Service region cv-prod-euwest-2 experienced a disruption that lasted 11 hours and 48 minutes. During this time, the service was unable to ingest flow data successfully. As a result, a gap in data might be seen when viewing traffic flow dashboards, flows in Topology views, event-specific details related to traffic flows, or UNO-related product reporting during this period. This incident was not due to a security breach, intrusion, or otherwise malicious activity.\n\n \n**Root cause**\n\nThis outage was caused by a subset of our data becoming unreadable. The particular corner case was a result of a race condition found in a specific part of the system that controls data lifecycle and enforces access control through checking permissions. Successful authz is required for any CRUD operations on any part of our data to be successful. When we reach an inconsistent state as such, our system\u2019s default behavior is to fail close. This design, while protective, led to this incident where we could not successfully ingest and write flow data, and the system remained secure by design.\n\n \n**Our Response**\n\nOur team worked non-stop to resolve the issue. The extended duration of the outage was due to an initial misdiagnosis of the root cause. Once the correct cause was identified, our team was able to resolve the issue and restore full functionality within approximately 30 minutes.\n\nWe understand this broad outage and the impact on your experience is unacceptable. We sincerely apologize to all affected CloudVision as-a-Service users in the affected region. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again. \n\nThank you for using CloudVision as-a-Service.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-09-02T05:27:01.000Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-09-01T17:39:23.067Z",
@@ -506,7 +506,7 @@
506
  "body": "The fix has been deployed and this incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "none",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-09-01T14:26:29.658Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-09-01T14:09:08.656Z",
@@ -519,7 +519,7 @@
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "none",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2025-08-26T23:14:51.685Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-08-26T20:59:19.277Z",
@@ -532,7 +532,7 @@
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2025-08-21T18:36:43.756Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-08-21T17:41:34.013Z",
@@ -545,7 +545,7 @@
545
  "body": "This is a retroactive post for the event that occurred earlier today on us1b on August 13th, 8:30 UTC that lasted about 10 minutes.\n\nSome impact may have been user visible, such as:\n- Some events, such as \"Device stopped streaming\" or \"Streaming Latency Breached Threshold\" may have fired incorrectly during this period.\n- There may have been sporadic timeouts when viewing parts of the UI.\n- There may have been general slowdown of provisioning activities, potentially resulting in timeouts or errors.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "none",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2025-08-13T15:27:32.710Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-08-13T15:27:32.652Z",
@@ -558,7 +558,7 @@
558
  "body": "A fix has been implemented and performance has returned to normal.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2025-08-13T13:23:16.832Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-08-13T13:04:53.609Z",
@@ -571,7 +571,7 @@
571
  "body": "This is a retroactive post for the event that occurred on us1b on August 8th, 2:41 UTC that lasted about 10minutes.\n\nSome impact may have been user visible, such as:\n- There is no data loss, however due to delay in processing streamed device data, some events such as \"Device stopped streaming\" or \"Streaming Latency Breached Threshold\" may fire. Please note that there is no data loss and all data will be processed with some delay during the impact window.\n- There may be some stale data, or sporadic timeouts viewing parts of the UI.\n\nWe are currently investigating the issue and working on mitigation. Thank you for your patience.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2025-08-08T16:23:41.446Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-08-08T16:23:41.400Z",
 
3
  "slug": "arista-cloudvision",
4
  "platform": "statuspage",
5
  "status_url": "https://status.arista.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "A mitigation was put in place and the performance is now stabilized. We will continue to monitor the situation. Thank you",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-01T04:47:56.942Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-01T03:22:34.450Z",
 
25
  "body": "This incident arose from unexpected localized network partitioning due to underlying conditions. Our systems automatically detected the event in <5m of the start of the impact, and began recovery, with minimal manual intervention involved. We are analyzing further hardening against the underlying conditions of this nature.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-28T20:40:36.781Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-28T17:39:57.230Z",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-20T05:09:23.081Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-20T02:54:03.744Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-12T19:03:50.725Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-12T18:51:17.000Z",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-08-13T05:25:27.232Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-12T16:19:38.427Z",
 
77
  "body": "The issue has been identified and a mitigation has been put in place. Streaming latencies have returned to their expected level.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-08-06T11:47:35.502Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-06T10:45:23.704Z",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-07-15T21:45:15.101Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-15T21:45:01.991Z",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "major",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-15T03:27:33.953Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-15T01:09:33.713Z",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-07-10T18:46:39.905Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-10T18:25:05.679Z",
 
129
  "body": "This issue is resolved. Please follow https://status.arista.io/incidents/5vx7cvb07k7d for postmortem update when it becomes available.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-07-13T23:54:59.538Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-07-07T22:58:26.134Z",
 
142
  "body": "**Incident Report: CVaaS Service Disruption - June 26th, 2026**\n\nOn June 26th, 2026 10:00AM PDT - 12:30PM PDT CVaaS service region cv-prod-us-central1-b experienced significant ingestion delay into NetDL that caused the following incorrect states to be observed by users:\n\n* Devices incorrectly marked as Inactive,\n* Multiple inactionable \u201cDevice Stopped Streaming\u201d events,\n* Multiple inactionable \u201cHigh Streaming Latency\u201d events\n\nDuring this time period, executing device provisioning actions may have been delayed or failed. There was no data loss. However, data ingested from actively streaming devices into CVaaS may have only become accessible after some delay. This may have impacted users accessing the UI, or other services consuming that data from CloudVision via API integrations. \n\nBetween June 26, 2026 12:30PM PDT - June 27th, 12:30PM PDT, some users may have experienced the above behaviors intermittently impact their devices, but not block device provisioning activities.\n\nBy June 27th, 2026, all mitigations were in place, and we transitioned to mitigating intermittent instances of elevated tail latency along the data ingestion path into NetDL. Between June 27th, 2026 and July 6th, 2026 a small subset of users of the cv-prod-us-central1-b service region may have experienced rare, but intermittent instances where CloudVision reported Event \u201cHigh Streaming Latency\u201d, potentially due to brief delays in NetDL ingestion. Users were not blocked from performing device provisioning activities.\n\n\u200c\n\n**Root Cause**\n\nNetwork performance degradation and instabilities in our underlying cloud provider were the ultimate root causes of delays ingesting data into the part of the system responsible for storing, processing, and updating device streaming status and streaming latency. Our mitigation activities between June 26th, 2026 and June 27th, 2026 stabilized the vast majority of the impact, but the changing underlying conditions prolonged the total duration of incident. This incident was not caused by software change\\(s\\), monitoring gaps, or software bugs in CloudVision as-a-Service.\n\n\u200c\n\n**Our Response**\n\nMultiple teams at Arista engaged around the clock from June 26th, 2026 until July 6th, 2026 to ensure we fully resolved this incident, as well as reviewed all details in our internal reviews. We continue to actively monitor this service region, as well as all of our CloudVision as-a-Service service regions.\n\nArista takes full responsibility for the performance and availability of the service regardless of the underlying cloud platform conditions. We are committed to making changes in both the short and long term that will provide greater resilience to underlying provider instabilities and changing real-time conditions.\n\nThank you for using CloudVision as-a-Service.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-07-07T22:57:18.224Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-06-26T17:27:17.754Z",
 
155
  "body": "We identified the source of the problem and the data ingestion latency has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-06-10T16:03:13.608Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-06-10T11:48:01.850Z",
 
168
  "body": "**Incident Report: CVaaS Service Disruption - May 29, 2026**\n\nOn May 29th, 2026, CloudVision as-a-Service delivered a software change for a set of services that provide the Network Provisioning workflows in the product. All services regions were impacted by this Network Provisioning feature update.\u00a0\n\nThis update introduced a critical bug across all service regions. As a result, customers utilizing the Network Provisioning workflows \\(see [https://www.arista.io/help/articles/provisioning-network-provisioning#network-provisioning](https://www.arista.io/help/articles/provisioning-network-provisioning#network-provisioning)\\) may have experienced instances where devices were mapped to the incorrect containers in the network provisioning hierarchy, creating a risk that unintended configuration states could be applied if customers then attempted to roll out additional changes to devices. The Network Provisioning workflows were disabled while we recovered from the issue, meaning that customers could not make any changes to their network configuration during this time.\n\nCustomers only defining their network configuration using Studios workflows \\(see [https://www.arista.io/help/articles/provisioning-studios](https://www.arista.io/help/articles/provisioning-studios)\\) were not impacted.\n\nThe software change that caused this issue was rolled back on May 29th, 2026. The delay in mitigation was due to gaps in our automated monitoring systems.\n\nFAQ:\n\n* _Did this bug cause a network outage for customers?_ No.\n* _Was there any data loss?_ No.\n* Was overall CloudVision service availability impacted?No.\n* _Are there any additional steps to recovery?_ No; the vast majority of impacted customers were recovered without requiring customer intervention. At this moment if you have not been directly contacted by us, no further action is required from you.\n\n\u200c\n\n**Root Cause**\n\nThe bug was due to logic applied to an incorrect data state within the Network Provisioning feature. This caused an incorrect device container mapping during the device state reconciliation phase. This was not caught during testing or during the post deployment evaluation phase in various environments prior to being released to production. Additionally, the rollout strategy used in the continuous delivery applicable for this particular set of services allowed the bug to propagate quickly across all CloudVision as-a-Service regions.\n\n\u200c\n\n**Our Response**\n\nOnce the bug was identified on May 29th, 2026, our team rolled back the update responsible within approximately a five hour period on all production regions. In addition, API usage restrictions were established as a protective measure against customers that may inadvertently execute a configuration change on their network without knowledge of this bug and device state change. Between May 29th and June 1st, 2026, our team engaged in continuous efforts to restore services for all affected customers and devices. The majority of these recovery operations were successfully concluded by May 30th, 2026. Throughout this period, we maintained regular updates on Statuspage to keep our customers informed regarding our progress.\n\nWe understand a disruption of this nature is unacceptable for our customers. We are conducting a full review of design, testing, validation, delivery, monitoring, and incident response as part of the postmortem review, and we are committed to ensuring we do not run into incidents of this nature in the future.\u00a0\n\nThank you for using CloudVision as-a-Service.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-06-04T00:50:38.220Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-29T20:24:49.338Z",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-05-29T21:02:17.763Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-29T17:45:17.916Z",
 
194
  "body": "This incident has been resolved. We will follow up with a postmortem.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-05-27T01:02:39.759Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-05-26T15:38:23.965Z",
 
207
  "body": "We experienced high device streaming latency on this affected cluster. \n\nSome impact may be user visible, such as:\n- A delay in processing streamed device data. Some events such as \"Device stopped streaming\" or \"Streaming Latency Breached Threshold\" may fire as a result of this. In this case, the device updates are behind schedule and will be processed with some delay during the impact window.\n- There may be some stale data, or sporadic timeouts viewing parts of the UI.\n- Some provisioning features may be delayed or timeout due to the high latency.\n\nThis was due to an internal component upgrade in our cloud environment; we continue to work on decreasing the impact of this upgrade process. Thank you for your patience.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-05-18T13:35:22.839Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-05-18T13:35:22.776Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "major",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-05-15T17:30:14.843Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-05-15T17:24:21.000Z",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-04-15T12:34:33.103Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-04-15T12:04:42.879Z",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-03-19T00:57:11.179Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-19T00:38:53.548Z",
 
259
  "body": "The fix has been successfully deployed to all regions. Customers will have to reload the UI for the changes to take effect.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-03-12T21:57:50.933Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-12T15:33:08.562Z",
 
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-03-04T06:43:05.682Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-03-04T05:23:36.000Z",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-03-03T04:31:27.923Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-03-03T04:15:47.058Z",
 
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-02-17T16:54:04.498Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-02-13T01:30:08.000Z",
 
311
  "body": "**Incident Report: Platform Outage - January 31st, 2026**\n\nOn January 31, 2026, CloudVision as-a-Service experienced a platform-wide incident within the cv-prod-us-central1-a region that lasted a total of 1 hour and 18 minutes. During the first hour of this window, the platform remained operational despite intermittent connectivity disruptions that impacted <1% of total traffic. In the final 18 minutes of the incident, traffic loss increased to approximately 2%. During this period, users likely experienced a gradual loss of connectivity and platform access. This included disruptions to device streaming, where devices may have started to coalesce data to resume streaming once platform stabilized, which is the standard failure-mode behavior designed to preserve data integrity during network instability.\n\nThis incident was not the result of a security breach, unauthorized intrusion, or any malicious activity.\n\n\u200c\n\n**Root Cause**\n\nThe root cause of this disruption was identified as a catastrophic networking loss within our third-party cloud infrastructure provider.\n\n\u200c\n\n**Our Response**\n\nOur team detected the outage within five minutes of the initial failure and remained in constant communication with the provider to manage triage, recovery, and remediation efforts. During the incident, we made the strategic decision not to initiate a full site disaster recovery. Our technical assessment concluded that a full failover would have been significantly more disruptive to the user experience and would have ultimately prolonged the duration of the incident.\n\n\u200c\n\nWe understand that any service interruption is an unacceptable outcome for our users. We are currently working on internal initiatives to make our architecture more resilient to these specific modes of failure while simultaneously partnering with our cloud provider to ensure better stability of the underlying infrastructure.\n\n\u200c\n\nWe appreciate your patience and your continued use of CloudVision as-a-Service.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-01-31T01:42:31.826Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-01-31T00:16:11.984Z",
 
324
  "body": "**Incident Report: Login By Email Service Outage - January 30th, 2026**\n\nOn January 30, 2026, CloudVision as-a-Service experienced a service outage affecting the \"Login By Email\" functionality lasting 2 hours and 36 minutes. During this window, customers attempting to access their accounts using Login By Email failed to receive the invitation emails. This incident was isolated strictly to the Login By Email service; SSO and SAML based login remained fully operational.\n\nThere was no data loss or compromise of customer information. This outage was not the result of a security breach, unauthorized intrusion, or any malicious activity.\n\n**Root Cause**\n\nOur investigation identified a gap in monitoring for a critical third-party integration. Because this specific telemetry was missing, early warning signals were missed, leading to the eventual service disruption. Additionally, we identified internal process failures that contributed to the duration of the outage.\n\n**Our Response**\n\nInternal escalation protocols successfully engaged subject matter experts within 30 minutes of the first reported case. Initial delays in resolution were primarily due to various process failures including delays in required coordination with third party vendor. We are implementing the missing monitoring triggers for third-party integrations to ensure early detection, as well as reviewing our processes as part of various fixes we are addressing.\n\nWe understand that any service disruption is impactful. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again.\n\nThank you for using CloudVision as-a-Service.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-01-30T16:05:26.723Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-01-30T14:36:34.310Z",
 
337
  "body": "Telemetry was delayed for up to 30 minutes due to an disruptive infrastructure reconfiguration. The incident has now been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-01-23T12:13:47.702Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-01-23T09:28:30.595Z",
 
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "none",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-01-15T23:49:30.238Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-01-15T20:53:52.525Z",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "none",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-01-13T00:11:03.157Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-01-12T21:48:47.442Z",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "none",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-12-19T22:17:01.161Z",
381
  "resolved_inferred": false,
382
  "started_at": "2025-12-19T17:22:14.735Z",
 
389
  "body": "Closing this courtesy notice.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "none",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-12-09T23:59:34.329Z",
394
  "resolved_inferred": false,
395
  "started_at": "2025-12-09T17:42:18.000Z",
 
402
  "body": "Hello CloudVision as a Service customers,\n\nWe have identified an issue impacting a small subset of customers where all EOS devices in a tenant were incorrectly marked as inactive. Importantly, the devices were actively streaming and all data and telemetry were generated and stored correctly.\n\nImpacted customers may have observed this incorrect streaming status displayed for several consecutive hours or days since November 25th, 2025. \n\nWe have identified the root cause and deployed an immediate fix. There is no action required from you as the customer. This is a courtesy notice only.\n\nIf you have any questions about this issue or if your tenant was affected, please reach out to support@arista.com.\n\nThank you for being a valued CloudVision as a Service customer.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "none",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-12-08T23:57:38.551Z",
407
  "resolved_inferred": false,
408
  "started_at": "2025-12-08T23:57:38.505Z",
 
415
  "body": "The data processing pipeline has fully recovered, and the service is now operating in a healthy state.\n\nThe ingestion of device telemetry data was not impacted during the incident. There was no data loss.\n\nPostmortem for this incident is still pending. Our team is currently actively working on reviewing this incident, and postmortem update.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "major",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-10-12T14:15:00.312Z",
420
  "resolved_inferred": false,
421
  "started_at": "2025-10-12T11:05:27.234Z",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "none",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-09-16T19:01:13.690Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-09-16T18:38:05.616Z",
 
441
  "body": "This incident is resolved",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "none",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-09-11T23:17:38.156Z",
446
  "resolved_inferred": false,
447
  "started_at": "2025-09-11T18:00:35.380Z",
 
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "none",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-09-11T00:32:19.636Z",
459
  "resolved_inferred": false,
460
  "started_at": "2025-09-10T23:18:33.114Z",
 
467
  "body": "**Incident Report: CVaaS Service Disruption - September 8, 2025** \nOn September 8, 2025, CloudVision as-a-Service experienced a service disruption, lasting from 8 minutes in our UK region \\(cv-prod-uk-1\\) to 25 minutes in a US region \\(us-central1-a\\). During this time, users were unable to establish new connections, and transient connection errors occurred for those with existing connections.\n\nWe do not expect any data loss, as device state streaming was coalesced and resumed after the disruption. This incident was not caused by a security breach, intrusion, or other malicious activity.\n\n\u200c\n\n**Root Cause**\n\nAn internal certificate expired within our trust chain, causing a disruption. The certificate was not properly monitored in our system, which notifies and automatically renews certificates, leading to its expiration.\n\n\u200c\n\n**Our Response**\n\nOur team was alerted to similar service disruptions across various global regions, and a status page incident was posted because the issue was not transient and was unrelated to our service provider. The disruption was triaged, the root cause identified, and mitigations implemented within 20 minutes. Corrective actions were taken simultaneously over the next approximately 35 minutes. The incident was closed after an assessment of all regions was completed, and services were restored.\n\nWe understand that an outage of this nature is unacceptable and apologize to all affected CloudVision as-a-Service users impacted by this incident. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again.\n\nThank you for using CloudVision as-a-Service.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "critical",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-09-08T15:35:04.842Z",
472
  "resolved_inferred": false,
473
  "started_at": "2025-09-08T12:56:47.000Z",
 
480
  "body": "## **Incident Report: CVaaS Service Disruption - September 1, 2025**\n\nOn September 1, 2025, CloudVision as-a-Service region cv-prod-euwest-2 experienced a disruption that lasted 2h. During this time some devices may have experienced state update becoming visible to be delayed up to those 2h. There was no data loss of device state. This incident was not due to a security breach, intrusion, or otherwise malicious activity.\u200c\n\n**Root Cause**\n\nThe root cause of this incident was caused by residual impact that was as described [in this incident](https://status.arista.io/incidents/7bcj2khfpqcy). Please find further details of root cause, and our response as described in this linked post.\n\nThank you for using CloudVision as-a-Service.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "none",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-09-02T05:38:02.043Z",
485
  "resolved_inferred": false,
486
  "started_at": "2025-09-02T03:38:10.444Z",
 
493
  "body": "## **Incident Report: CVaaS Service Disruption - September 1, 2025**\n\nOn September 1, 2025, CloudVision as-a-Service region cv-prod-euwest-2 experienced a disruption that lasted 11 hours and 48 minutes. During this time, the service was unable to ingest flow data successfully. As a result, a gap in data might be seen when viewing traffic flow dashboards, flows in Topology views, event-specific details related to traffic flows, or UNO-related product reporting during this period. This incident was not due to a security breach, intrusion, or otherwise malicious activity.\n\n \n**Root cause**\n\nThis outage was caused by a subset of our data becoming unreadable. The particular corner case was a result of a race condition found in a specific part of the system that controls data lifecycle and enforces access control through checking permissions. Successful authz is required for any CRUD operations on any part of our data to be successful. When we reach an inconsistent state as such, our system\u2019s default behavior is to fail close. This design, while protective, led to this incident where we could not successfully ingest and write flow data, and the system remained secure by design.\n\n \n**Our Response**\n\nOur team worked non-stop to resolve the issue. The extended duration of the outage was due to an initial misdiagnosis of the root cause. Once the correct cause was identified, our team was able to resolve the issue and restore full functionality within approximately 30 minutes.\n\nWe understand this broad outage and the impact on your experience is unacceptable. We sincerely apologize to all affected CloudVision as-a-Service users in the affected region. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again. \n\nThank you for using CloudVision as-a-Service.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-09-02T05:27:01.000Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-09-01T17:39:23.067Z",
 
506
  "body": "The fix has been deployed and this incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "none",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-09-01T14:26:29.658Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-09-01T14:09:08.656Z",
 
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "none",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-08-26T23:14:51.685Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-08-26T20:59:19.277Z",
 
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-08-21T18:36:43.756Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-08-21T17:41:34.013Z",
 
545
  "body": "This is a retroactive post for the event that occurred earlier today on us1b on August 13th, 8:30 UTC that lasted about 10 minutes.\n\nSome impact may have been user visible, such as:\n- Some events, such as \"Device stopped streaming\" or \"Streaming Latency Breached Threshold\" may have fired incorrectly during this period.\n- There may have been sporadic timeouts when viewing parts of the UI.\n- There may have been general slowdown of provisioning activities, potentially resulting in timeouts or errors.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "none",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-08-13T15:27:32.710Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-08-13T15:27:32.652Z",
 
558
  "body": "A fix has been implemented and performance has returned to normal.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2025-08-13T13:23:16.832Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-08-13T13:04:53.609Z",
 
571
  "body": "This is a retroactive post for the event that occurred on us1b on August 8th, 2:41 UTC that lasted about 10minutes.\n\nSome impact may have been user visible, such as:\n- There is no data loss, however due to delay in processing streamed device data, some events such as \"Device stopped streaming\" or \"Streaming Latency Breached Threshold\" may fire. Please note that there is no data loss and all data will be processed with some delay during the impact window.\n- There may be some stale data, or sporadic timeouts viewing parts of the UI.\n\nWe are currently investigating the issue and working on mitigation. Thank you for your patience.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-08-08T16:23:41.446Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-08-08T16:23:41.400Z",
api/v/array.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "array",
4
  "platform": "statuspage",
5
  "status_url": "https://status.array.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "TransUnion services have remained stable, and we are no longer seeing the service issues impacting enrollments, Score Simulator, and report ordering. This incident is now resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-03T14:14:15.486-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T10:33:56.917-04:00",
@@ -25,7 +25,7 @@
25
  "body": "The issue affecting Financial Calculators has been resolved, and functionality has been fully restored. Our teams have confirmed that the calculators are operating as expected. Thank you for your patience while we worked to resolve this issue.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-31T18:02:15.807-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-31T10:07:07.000-04:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-30T00:44:55.851-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-30T00:40:32.980-04:00",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-30T01:16:01.784-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-29T23:29:04.881-04:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-08-29T22:10:22.713-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-29T22:04:24.786-04:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-08-21T13:46:43.370-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-21T12:05:29.537-04:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-08-15T00:08:17.954-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-14T22:46:59.022-04:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-08-12T04:06:42.902-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-12T03:15:44.450-04:00",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-08-10T08:59:46.659-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-10T08:21:47.190-04:00",
@@ -129,7 +129,7 @@
129
  "body": "This issue has been resolved",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-08-06T16:44:34.380-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-05T10:26:21.297-04:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-08-06T12:16:12.326-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-04T12:27:05.370-04:00",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-07-30T20:09:40.090-04:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-07-30T18:20:18.633-04:00",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved and credit reports should now be returning data successfully.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-07-24T13:26:38.857-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-24T10:54:44.200-04:00",
@@ -181,7 +181,7 @@
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-07-14T14:01:33.347-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-14T11:54:47.950-04:00",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-07-14T14:01:56.206-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-14T11:13:57.000-04:00",
@@ -207,7 +207,7 @@
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-07-13T01:55:29.771-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-13T01:18:58.332-04:00",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-07-13T01:07:25.017-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-07-12T23:22:11.772-04:00",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-07-11T00:06:41.136-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-07-10T19:16:02.548-04:00",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-07-07T23:23:05.454-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-07-07T23:06:49.953-04:00",
@@ -259,7 +259,7 @@
259
  "body": "Services are restored",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "critical",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-07-07T12:38:24.080-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-07-07T10:24:04.869-04:00",
@@ -272,7 +272,7 @@
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "none",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-07-06T11:40:47.044-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-07-06T10:31:18.000-04:00",
@@ -285,7 +285,7 @@
285
  "body": "We have reached out to TU to confirm if any issues on their end & monitoring.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-07-02T20:23:57.863-04:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-07-02T17:58:23.468-04:00",
@@ -298,7 +298,7 @@
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-07-01T17:10:13.361-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-07-01T16:07:49.172-04:00",
@@ -311,7 +311,7 @@
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "none",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-07-01T17:11:28.373-04:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-07-01T14:22:49.923-04:00",
@@ -324,7 +324,7 @@
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "none",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-07-01T13:33:08.373-04:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-07-01T12:31:34.011-04:00",
@@ -337,7 +337,7 @@
337
  "body": "This incident affecting white label websites has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-06-25T13:54:01.000-04:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-06-25T13:06:57.000-04:00",
@@ -350,7 +350,7 @@
350
  "body": "This incident in regards to latency in our response time has been resolved",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "none",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-06-15T15:03:29.158-04:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-06-15T14:03:36.744-04:00",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-06-10T14:38:10.975-04:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-06-10T12:55:51.347-04:00",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-06-04T14:20:10.432-04:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-06-04T13:02:15.000-04:00",
@@ -389,7 +389,7 @@
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "critical",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-06-02T21:10:17.742-04:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-06-02T20:12:58.526-04:00",
@@ -402,7 +402,7 @@
402
  "body": "Service performance has remained stable, and we have not observed a recurrence of the previously reported impact to Identity Protection (IDP) and My Credit Manager (MCM) alerts following the mitigation efforts implemented earlier.\n\nAt this time, we are considering the incident resolved. Our teams will continue to monitor the affected services to confirm continued stability. We appreciate your patience and understanding throughout this incident.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-06-02T12:27:00.541-04:00",
407
  "resolved_inferred": false,
408
  "started_at": "2026-06-01T10:16:37.000-04:00",
@@ -415,7 +415,7 @@
415
  "body": "This incident has been resolved. Report pulls for My Credit Manager were operational as of 11:45 am ET",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-05-31T13:32:33.216-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2026-05-31T07:58:16.921-04:00",
@@ -428,7 +428,7 @@
428
  "body": "The issue affecting Privacy Protect has been resolved, and services have returned to normal operation.\n\nAs part of the recovery process, delayed verifications and affected background scans will continue to be processed throughout the afternoon. Clients may receive verification webhooks for records that were impacted during the incident, including some records that may no longer exist in their systems. Any verification webhooks that do not correspond to an active record on your end can be safely ignored.\n\nWe appreciate your patience and understanding throughout this incident.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2026-06-03T13:25:30.000-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2026-05-28T21:57:09.867-04:00",
@@ -441,7 +441,7 @@
441
  "body": "We have implemented a fix for this issue.\nHowever, users may still see duplicate records on their scan results as we clean up these records.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "none",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2026-05-27T20:17:40.373-04:00",
446
  "resolved_inferred": false,
447
  "started_at": "2026-05-27T16:41:49.796-04:00",
@@ -454,7 +454,7 @@
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "none",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2026-05-21T16:19:56.180-04:00",
459
  "resolved_inferred": false,
460
  "started_at": "2026-05-21T16:16:43.942-04:00",
@@ -467,7 +467,7 @@
467
  "body": "This incident has been resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2026-05-21T16:15:00.420-04:00",
472
  "resolved_inferred": false,
473
  "started_at": "2026-05-21T15:47:29.358-04:00",
@@ -480,7 +480,7 @@
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "none",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2026-05-11T12:02:26.752-04:00",
485
  "resolved_inferred": false,
486
  "started_at": "2026-05-11T09:50:11.000-04:00",
@@ -493,7 +493,7 @@
493
  "body": "This incident has been resolved.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2026-05-09T04:20:06.623-04:00",
498
  "resolved_inferred": false,
499
  "started_at": "2026-05-08T17:49:50.000-04:00",
@@ -506,7 +506,7 @@
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "minor",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2026-05-06T17:00:57.147-04:00",
511
  "resolved_inferred": false,
512
  "started_at": "2026-05-06T16:04:31.179-04:00",
@@ -519,7 +519,7 @@
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2026-05-06T16:22:41.237-04:00",
524
  "resolved_inferred": false,
525
  "started_at": "2026-05-06T15:49:44.793-04:00",
@@ -532,7 +532,7 @@
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2026-05-01T15:36:10.796-04:00",
537
  "resolved_inferred": false,
538
  "started_at": "2026-05-01T08:47:06.690-04:00",
@@ -545,7 +545,7 @@
545
  "body": "This incident has been resolved.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2026-04-27T15:29:52.937-04:00",
550
  "resolved_inferred": false,
551
  "started_at": "2026-04-27T14:45:48.000-04:00",
@@ -558,7 +558,7 @@
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2026-04-22T19:53:43.305-04:00",
563
  "resolved_inferred": false,
564
  "started_at": "2026-04-22T19:27:53.677-04:00",
@@ -571,7 +571,7 @@
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2026-04-14T17:53:49.434-04:00",
576
  "resolved_inferred": false,
577
  "started_at": "2026-04-14T17:48:52.418-04:00",
@@ -584,7 +584,7 @@
584
  "body": "This issue has been resolved. We\u2019re continuing to monitor performance to ensure everything remains stable.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "none",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2026-04-08T16:03:12.558-04:00",
589
  "resolved_inferred": false,
590
  "started_at": "2026-04-08T15:44:45.289-04:00",
@@ -597,7 +597,7 @@
597
  "body": "our monitoring indicated a low-volume occurrence of delayed response times for a small number of report storage / retrieval requests, we investigated and remediated.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "none",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2026-04-02T11:44:35.074-04:00",
602
  "resolved_inferred": false,
603
  "started_at": "2026-04-02T11:16:19.800-04:00",
@@ -610,7 +610,7 @@
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2026-04-01T18:19:22.857-04:00",
615
  "resolved_inferred": false,
616
  "started_at": "2026-04-01T17:41:59.000-04:00",
@@ -623,7 +623,7 @@
623
  "body": "All systems have stabilized all services to a steady state volume.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "minor",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2026-03-31T16:03:46.723-04:00",
628
  "resolved_inferred": false,
629
  "started_at": "2026-03-31T15:31:39.980-04:00",
@@ -636,7 +636,7 @@
636
  "body": "We observed an issue with the RabbitMQ cluster in shared prod. The cluster was reconnected and services are restored.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "none",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2026-03-30T12:49:47.464-04:00",
641
  "resolved_inferred": false,
642
  "started_at": "2026-03-30T12:04:31.000-04:00",
@@ -649,7 +649,7 @@
649
  "body": "This incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "none",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2026-03-19T07:32:24.970-04:00",
654
  "resolved_inferred": false,
655
  "started_at": "2026-03-19T03:18:50.406-04:00",
 
3
  "slug": "array",
4
  "platform": "statuspage",
5
  "status_url": "https://status.array.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "TransUnion services have remained stable, and we are no longer seeing the service issues impacting enrollments, Score Simulator, and report ordering. This incident is now resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-03T14:14:15.486-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T10:33:56.917-04:00",
 
25
  "body": "The issue affecting Financial Calculators has been resolved, and functionality has been fully restored. Our teams have confirmed that the calculators are operating as expected. Thank you for your patience while we worked to resolve this issue.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "critical",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-31T18:02:15.807-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-31T10:07:07.000-04:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-30T00:44:55.851-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-30T00:40:32.980-04:00",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-30T01:16:01.784-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-29T23:29:04.881-04:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-08-29T22:10:22.713-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-08-29T22:04:24.786-04:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "none",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-08-21T13:46:43.370-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-08-21T12:05:29.537-04:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-08-15T00:08:17.954-04:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-08-14T22:46:59.022-04:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-08-12T04:06:42.902-04:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-08-12T03:15:44.450-04:00",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-08-10T08:59:46.659-04:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-08-10T08:21:47.190-04:00",
 
129
  "body": "This issue has been resolved",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-08-06T16:44:34.380-04:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-08-05T10:26:21.297-04:00",
 
142
  "body": "This incident has been resolved",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "none",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-08-06T12:16:12.326-04:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-08-04T12:27:05.370-04:00",
 
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-07-30T20:09:40.090-04:00",
160
  "resolved_inferred": false,
161
  "started_at": "2026-07-30T18:20:18.633-04:00",
 
168
  "body": "This incident has been resolved and credit reports should now be returning data successfully.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-07-24T13:26:38.857-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2026-07-24T10:54:44.200-04:00",
 
181
  "body": "This incident has been resolved.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-07-14T14:01:33.347-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2026-07-14T11:54:47.950-04:00",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-07-14T14:01:56.206-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2026-07-14T11:13:57.000-04:00",
 
207
  "body": "This incident has been resolved.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-07-13T01:55:29.771-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2026-07-13T01:18:58.332-04:00",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-07-13T01:07:25.017-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2026-07-12T23:22:11.772-04:00",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-07-11T00:06:41.136-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2026-07-10T19:16:02.548-04:00",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-07-07T23:23:05.454-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2026-07-07T23:06:49.953-04:00",
 
259
  "body": "Services are restored",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "critical",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-07-07T12:38:24.080-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2026-07-07T10:24:04.869-04:00",
 
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "none",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-07-06T11:40:47.044-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2026-07-06T10:31:18.000-04:00",
 
285
  "body": "We have reached out to TU to confirm if any issues on their end & monitoring.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "none",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-07-02T20:23:57.863-04:00",
290
  "resolved_inferred": false,
291
  "started_at": "2026-07-02T17:58:23.468-04:00",
 
298
  "body": "This incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-07-01T17:10:13.361-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2026-07-01T16:07:49.172-04:00",
 
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "none",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-07-01T17:11:28.373-04:00",
316
  "resolved_inferred": false,
317
  "started_at": "2026-07-01T14:22:49.923-04:00",
 
324
  "body": "This incident has been resolved.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "none",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-07-01T13:33:08.373-04:00",
329
  "resolved_inferred": false,
330
  "started_at": "2026-07-01T12:31:34.011-04:00",
 
337
  "body": "This incident affecting white label websites has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-06-25T13:54:01.000-04:00",
342
  "resolved_inferred": false,
343
  "started_at": "2026-06-25T13:06:57.000-04:00",
 
350
  "body": "This incident in regards to latency in our response time has been resolved",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "none",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-06-15T15:03:29.158-04:00",
355
  "resolved_inferred": false,
356
  "started_at": "2026-06-15T14:03:36.744-04:00",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-06-10T14:38:10.975-04:00",
368
  "resolved_inferred": false,
369
  "started_at": "2026-06-10T12:55:51.347-04:00",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-06-04T14:20:10.432-04:00",
381
  "resolved_inferred": false,
382
  "started_at": "2026-06-04T13:02:15.000-04:00",
 
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "critical",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-06-02T21:10:17.742-04:00",
394
  "resolved_inferred": false,
395
  "started_at": "2026-06-02T20:12:58.526-04:00",
 
402
  "body": "Service performance has remained stable, and we have not observed a recurrence of the previously reported impact to Identity Protection (IDP) and My Credit Manager (MCM) alerts following the mitigation efforts implemented earlier.\n\nAt this time, we are considering the incident resolved. Our teams will continue to monitor the affected services to confirm continued stability. We appreciate your patience and understanding throughout this incident.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-06-02T12:27:00.541-04:00",
407
  "resolved_inferred": false,
408
  "started_at": "2026-06-01T10:16:37.000-04:00",
 
415
  "body": "This incident has been resolved. Report pulls for My Credit Manager were operational as of 11:45 am ET",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-05-31T13:32:33.216-04:00",
420
  "resolved_inferred": false,
421
  "started_at": "2026-05-31T07:58:16.921-04:00",
 
428
  "body": "The issue affecting Privacy Protect has been resolved, and services have returned to normal operation.\n\nAs part of the recovery process, delayed verifications and affected background scans will continue to be processed throughout the afternoon. Clients may receive verification webhooks for records that were impacted during the incident, including some records that may no longer exist in their systems. Any verification webhooks that do not correspond to an active record on your end can be safely ignored.\n\nWe appreciate your patience and understanding throughout this incident.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-06-03T13:25:30.000-04:00",
433
  "resolved_inferred": false,
434
  "started_at": "2026-05-28T21:57:09.867-04:00",
 
441
  "body": "We have implemented a fix for this issue.\nHowever, users may still see duplicate records on their scan results as we clean up these records.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "none",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-05-27T20:17:40.373-04:00",
446
  "resolved_inferred": false,
447
  "started_at": "2026-05-27T16:41:49.796-04:00",
 
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "none",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-05-21T16:19:56.180-04:00",
459
  "resolved_inferred": false,
460
  "started_at": "2026-05-21T16:16:43.942-04:00",
 
467
  "body": "This incident has been resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "major",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-05-21T16:15:00.420-04:00",
472
  "resolved_inferred": false,
473
  "started_at": "2026-05-21T15:47:29.358-04:00",
 
480
  "body": "This incident has been resolved.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "none",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-05-11T12:02:26.752-04:00",
485
  "resolved_inferred": false,
486
  "started_at": "2026-05-11T09:50:11.000-04:00",
 
493
  "body": "This incident has been resolved.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2026-05-09T04:20:06.623-04:00",
498
  "resolved_inferred": false,
499
  "started_at": "2026-05-08T17:49:50.000-04:00",
 
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "minor",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2026-05-06T17:00:57.147-04:00",
511
  "resolved_inferred": false,
512
  "started_at": "2026-05-06T16:04:31.179-04:00",
 
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "minor",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2026-05-06T16:22:41.237-04:00",
524
  "resolved_inferred": false,
525
  "started_at": "2026-05-06T15:49:44.793-04:00",
 
532
  "body": "This incident has been resolved.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2026-05-01T15:36:10.796-04:00",
537
  "resolved_inferred": false,
538
  "started_at": "2026-05-01T08:47:06.690-04:00",
 
545
  "body": "This incident has been resolved.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2026-04-27T15:29:52.937-04:00",
550
  "resolved_inferred": false,
551
  "started_at": "2026-04-27T14:45:48.000-04:00",
 
558
  "body": "This incident has been resolved.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2026-04-22T19:53:43.305-04:00",
563
  "resolved_inferred": false,
564
  "started_at": "2026-04-22T19:27:53.677-04:00",
 
571
  "body": "This incident has been resolved.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2026-04-14T17:53:49.434-04:00",
576
  "resolved_inferred": false,
577
  "started_at": "2026-04-14T17:48:52.418-04:00",
 
584
  "body": "This issue has been resolved. We\u2019re continuing to monitor performance to ensure everything remains stable.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "none",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2026-04-08T16:03:12.558-04:00",
589
  "resolved_inferred": false,
590
  "started_at": "2026-04-08T15:44:45.289-04:00",
 
597
  "body": "our monitoring indicated a low-volume occurrence of delayed response times for a small number of report storage / retrieval requests, we investigated and remediated.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "none",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2026-04-02T11:44:35.074-04:00",
602
  "resolved_inferred": false,
603
  "started_at": "2026-04-02T11:16:19.800-04:00",
 
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "minor",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2026-04-01T18:19:22.857-04:00",
615
  "resolved_inferred": false,
616
  "started_at": "2026-04-01T17:41:59.000-04:00",
 
623
  "body": "All systems have stabilized all services to a steady state volume.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "minor",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2026-03-31T16:03:46.723-04:00",
628
  "resolved_inferred": false,
629
  "started_at": "2026-03-31T15:31:39.980-04:00",
 
636
  "body": "We observed an issue with the RabbitMQ cluster in shared prod. The cluster was reconnected and services are restored.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "none",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2026-03-30T12:49:47.464-04:00",
641
  "resolved_inferred": false,
642
  "started_at": "2026-03-30T12:04:31.000-04:00",
 
649
  "body": "This incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "none",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2026-03-19T07:32:24.970-04:00",
654
  "resolved_inferred": false,
655
  "started_at": "2026-03-19T03:18:50.406-04:00",
api/v/ashby.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "ashby",
4
  "platform": "statuspage",
5
  "status_url": "https://status.ashbyhq.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "Our upstream provider has resolved the issue.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-31T18:11:38.708Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-31T17:44:26.072Z",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-09T13:00:20.391Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-07T19:11:00.100Z",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-07-27T21:12:55.243Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-27T14:56:43.923Z",
@@ -51,7 +51,7 @@
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "major",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-16T11:00:55.444Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-16T08:40:00.000Z",
@@ -64,7 +64,7 @@
64
  "body": "For approximately 11 minutes from 10:19 AM PDT to 10:30 AM PDT, Ashby users experienced long-running loading screens and, in some cases, errors. This was the result of requests to our servers taking too long to respond. Candidates applying for jobs were unaffected.\n\nOur maintenance this weekend will address the root cause of this issue by increasing our database capacity.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-13T17:19:00.000Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-13T17:19:00.000Z",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved. Resumes that failed to parse during the incident have been backfilled.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-07-08T04:17:54.867Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-08T00:40:32.296Z",
@@ -90,7 +90,7 @@
90
  "body": "From 11:30am until 1:40pm PDT, candidate PDF exports failed with a generic message. The cause of this issue has already been identified and fixed.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-07-06T18:30:00.000Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-06T18:30:00.000Z",
@@ -103,7 +103,7 @@
103
  "body": "Our upstream provider, Cloudflare, has implemented a fix and our tests indicate they have resolved the issue.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-02T02:14:47.126Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-01T20:19:55.143Z",
@@ -116,7 +116,7 @@
116
  "body": "We've confirmed Ashby is available again in the Sydney region. We will work with our upstream provider to understand what happened.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-07-01T19:03:07.080Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-01T18:49:25.490Z",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-06-24T22:21:00.145Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-24T21:16:01.044Z",
@@ -142,7 +142,7 @@
142
  "body": "We're experiencing an issue sending Slack and email notifications for interview reminders between 4:00PM and 5:00PM (UTC)",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-06-24T16:00:00.000Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-06-24T16:00:00.000Z",
@@ -155,7 +155,7 @@
155
  "body": "We're experiencing an issue sending Slack and email notifications for interview reminders between 4:00PM and 7:00PM (UTC)",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-06-22T16:00:00.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-06-22T16:00:00.000Z",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-06-19T14:20:28.773Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-06-19T13:47:54.028Z",
@@ -181,7 +181,7 @@
181
  "body": "Integrations degraded due to an infrastructure issue. Affected services include Google Workspace integration (including sending via Gmail); ATS syncs; autocomplete for candidate resumes/locations; and some AI features.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-06-19T06:30:00.000Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-06-19T06:30:00.000Z",
@@ -194,7 +194,7 @@
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-06-16T09:22:02.333Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-06-16T08:21:44.130Z",
@@ -207,7 +207,7 @@
207
  "body": "## **Summary**\n\nOn Monday, June 15, from approximately 4:00 AM PDT to 10:26 AM PDT, Safari and iOS users encountered an error with embedded and Ashby-hosted job boards \\([jobs.ashbyhq.com](http://jobs.ashbyhq.com)\\) and could not view or apply to jobs.\u00a0\n\nWe became aware of the problem at 9:43 AM PDT and recovered at 10:26 AM PDT.\n\n## **Why did this happen?**\n\nAshby's internal code build process processes the code that powers your hosted and embedded job boards. As part of our security practices, each file is published with verification data that browsers use to confirm the file they download is exactly what we intend to serve. We shipped a change to this build process that modified the files after their verification data had been generated, so the files no longer matched the verification data and failed to load in Safari and iOS mobile browsers. The same files did not fail in the same way in other browsers, such as Chrome and Firefox, which is why the failure appeared inconsistent amongst visitors.\n\n## **How did we resolve this situation?**\n\nAfter confirming the failure was tied to a recent deploy, we rolled back to a known-good state to restore service. We confirmed that job boards loaded correctly in Safari, on mobile devices, and in other browsers before resuming normal deployments.\n\n## **How did we get to this point?**\n\nThe change altered our shipped code in a way we did not anticipate, and two gaps let it reach production undetected:\u00a0\n\n1. Our automated job board tests ran only against Chrome.\n2. We didn\u2019t have a check verifying file integrity at the point of publishing, where this particular failure surfaced.\n\n## **What have we put in place to prevent this from happening in the future?**\n\n1. We added an automated check that verifies file integrity immediately before publishing; any mismatch now blocks the deployment of updates to Ashby. We confirmed it catches this exact failure.\n2. We corrected how integrity verification is applied to our job board code, so that all browsers enforce it consistently.\n3. We expanded our automated job board tests to run against Safari and Firefox, not just Chrome.\n4. We have added additional monitoring, including on mobile browsers, to alert us directly when a job board fails to load in this way.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-06-15T19:15:43.381Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-06-15T16:59:16.420Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-06-02T21:57:01.078Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-06-02T14:55:08.350Z",
@@ -233,7 +233,7 @@
233
  "body": "## **Summary**\n\nOn Sunday, May 31st, at 10pm PST, Ashby was slow and had a high error rate for approximately 1 hour, from 10pm to 11:10pm \\(PST\\).\n\nDuring this time, the Ashby main application would have been slow, and approximately 50% of user actions would have resulted in Ashby displaying an error. Some candidates may have noticed a slower response to their job applications, but all applications were successful and none were lost.\n\n## **Why did this happen?**\n\nOn Sunday, May 31st, at 4pm PST, an account with one of our AI providers became unavailable. As a result, calls to that provider started to error. These calls are configured to automatically retry periodically until they succeed, but the retries caused a steady increase in the number of such calls per minute. In turn, this drained the capacity of a shared subsystem that manages many different processes at Ashby.\n\nIn particular, that shared subsystem is used for storing user session data. As the shared subsystem became overwhelmed, user sessions became slower to respond.\n\nThis caused requests to our web servers to take significantly longer to process. Which then caused our web servers to begin running out of capacity.\n\nAt 6am, capacity reached a critical low. At this point, our system began rejecting user actions. This is done to prevent complete system failure.\n\n## **How did we resolve the situation?**\n\nAt 10:04pm PST, our on-call engineers were notified. By 10:16pm PST, our on-call engineers were beginning an investigation.\n\nAt 11:03pm PST, we identified the subsystem that had reached capacity.\n\nAt 11:07pm PST, we stopped processing certain types of automated actions.\n\nAt 11:09pm PST, we identified the issue with the external provider and rectified it immediately.\n\nAt 11:10pm PST, error rates were down to 10%.\n\nAt 11:20pm PST, error rates were down to normal levels \\(~0%\\).\n\nAt 11:54pm PST, normal service was resumed, and no data was lost.\n\n## **What have we put in place to prevent it from happening in the future?**\n\nWe\u2019ve done an internal postmortem on this incident and have implemented or plan to implement a variety of changes that achieve three things:\n\n1. Reduced the likelihood of future failure\n2. Faster incident response times\n3. Lower impact on customers in the event of failure\n\nSpecifically, we have done the following:\n\n* We were already in the process of replacing the subsystem at the center of the outage. We have accelerated that work. The replacement is not vulnerable to this particular kind of failure.\n* We\u2019ve added additional monitoring around our AI providers to alert us to failures like this sooner.\n* We are prioritizing a fix for the retry mechanism that led to this incident.\n* We are migrating our user session storage to a new subsystem that is not vulnerable to this particular kind of failure.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-06-01T09:04:00.602Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-06-01T06:33:08.355Z",
@@ -246,7 +246,7 @@
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-05-29T15:55:09.399Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-05-29T13:41:51.731Z",
@@ -259,7 +259,7 @@
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-05-28T15:14:38.306Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-05-28T13:34:26.412Z",
@@ -272,7 +272,7 @@
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-05-15T21:59:10.226Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-05-15T21:10:11.507Z",
@@ -285,7 +285,7 @@
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-05-15T00:58:53.849Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-05-15T00:19:30.985Z",
@@ -298,7 +298,7 @@
298
  "body": "The issue has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-04-01T00:13:02.842Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-03-31T22:43:10.120Z",
@@ -311,7 +311,7 @@
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-03-24T18:51:04.355Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-03-24T15:43:13.025Z",
@@ -324,7 +324,7 @@
324
  "body": "### **Summary**\n\nFor a brief period on Monday, March 24, and from Tuesday, March 25 to Thursday, March 27, 2026, Ashby's scheduling features displayed incorrect interviewer availability for a subset of organizations with the\u00a0 Google Workspace integration. This allowed candidates to be scheduled even when an interviewer may already have a meeting. This bug affected the following scheduling features:\n\n* Manual scheduling\n* Direct booking links\n* Advanced scheduling\n\nThe issue only impacted organizations using Google Calendar sync without domain-wide delegation.\n\n### **Why did this happen?**\n\nAshby integrates with Google Calendar to display interviewer availability and power our scheduling features. Because some interviewers aren\u2019t authenticated Ashby users, we occasionally read their calendar data on behalf of a user who is. A code change deployed on March 24 updated the calendar synchronization logic as part of an improvement to our Google Calendar authorization process. A bug in this logic incorrectly conflated the interviewer\u2019s calendar with the authenticated user's, resulting in inaccurate availability being displayed during scheduling.\n\nThe code change was initially deployed on March 24, then briefly reverted, and redeployed on March 25, which is why there were separate windows of impact.\n\n### **How did we resolve the situation?**\n\nThe bug was active during three separate windows:\n\n* Monday, March 24, 8:21 AM - 9:52 AM PDT \\(approximately 1.5 hours\\)\u00a0\n* Tuesday, March 25, 7:05 AM - 7:52 AM PDT \\(approximately 47 minutes\\)\u00a0\n* Tuesday, March 25, 9:52 AM - Thursday, March 27, 5:34 AM PDT \\(approximately 44 hours\\)\u00a0\n\nOn Thursday, March 27, 2026, at 4:31 AM PDT, a customer reported that an interviewer\u2019s availability appeared incorrect. At 5:10 AM PDT, we identified the root cause, and at 5:34 AM PDT, we deployed a fix and triggered calendar resyncs for affected organizations to restore accurate availability data.\n\n### **What have we put in place to prevent it from happening in the future?**\n\n1. **Improved static analysis checks.** We improved static analysis checks to ensure similar code changes are analyzed for correctness before they reach production.\u00a0\n2. **Improved testing for calendar authorization scenarios.** The bug affected a specific authorization configuration that is difficult to replicate in our test environments. We are building improved test tooling to enable automated tests across even more permutations of integration configurations.\n3. **Better monitoring for calendar sync accuracy.** We are adding monitoring that will alert us when calendar data retrieved through this particular authorization path does not match the intended user.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-03-24T15:00:00.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-03-24T15:00:00.000Z",
@@ -337,7 +337,7 @@
337
  "body": "The incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-03-12T16:15:13.262Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-03-12T15:47:36.617Z",
@@ -350,7 +350,7 @@
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-03-12T13:07:44.681Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-03-12T12:56:30.491Z",
@@ -363,7 +363,7 @@
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-03-04T20:44:31.122Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-03-04T19:59:54.223Z",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-02-24T17:36:46.223Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-02-24T16:35:58.809Z",
@@ -389,7 +389,7 @@
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-02-20T19:45:52.776Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-02-20T18:59:07.761Z",
@@ -402,7 +402,7 @@
402
  "body": "The issue has been resolved by the upstream provider.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-02-13T10:15:33.592Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-02-13T05:10:17.969Z",
@@ -415,7 +415,7 @@
415
  "body": "Resolved: Reporting data is now up to date. Thank you for your patience.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-02-12T18:46:13.008Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-02-12T16:30:50.651Z",
@@ -428,7 +428,7 @@
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2026-02-04T17:46:31.992Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-02-04T16:46:56.128Z",
@@ -441,7 +441,7 @@
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2026-01-23T13:16:05.295Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-01-22T22:00:22.000Z",
@@ -454,7 +454,7 @@
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2026-01-20T22:49:52.884Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-01-20T16:30:37.000Z",
@@ -467,7 +467,7 @@
467
  "body": "We've implemented a fix and verified offer templates and workflows are working.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2026-01-06T18:21:12.059Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-01-06T17:52:38.000Z",
@@ -480,7 +480,7 @@
480
  "body": "Dropbox Sign has resolved their downtime, and we've verified e-signature works in Ashby.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2026-01-02T23:36:38.725Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-01-02T21:12:50.120Z",
@@ -493,7 +493,7 @@
493
  "body": "We saw elevated errors loading candidate profiles and sending emails starting at 12:08 UTC.\n\nWe resolved this at 12:56 UTC.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-12-16T12:08:00.000Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-12-16T12:08:00.000Z",
@@ -506,7 +506,7 @@
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "critical",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-12-05T09:46:46.687Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-12-05T09:07:15.618Z",
@@ -519,7 +519,7 @@
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "major",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2025-12-04T21:18:09.760Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-12-04T19:25:56.850Z",
@@ -532,7 +532,7 @@
532
  "body": "Cloudflare's scheduled maintenance is finished, and we're no longer seeing any service degradation.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "minor",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2025-12-03T19:03:07.010Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-12-03T15:58:33.000Z",
@@ -545,7 +545,7 @@
545
  "body": "Ashby-hosted job boards are operational again. We have identified the root cause and are addressing it.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2025-12-02T13:44:53.944Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-12-02T13:37:41.005Z",
@@ -558,7 +558,7 @@
558
  "body": "We have noticed increased errors loading https://app.ashbyhq.com.\nThe issue has been resolved and the app is responsive again.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2025-11-20T12:14:35.986Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-11-20T12:14:35.939Z",
@@ -571,7 +571,7 @@
571
  "body": "We have resolved an issue that caused errors with manually rescheduling candidates between 9:10 AM and 10:30 AM UTC.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2025-11-17T10:42:59.642Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-11-17T10:42:59.583Z",
@@ -584,7 +584,7 @@
584
  "body": "We have deployed changes that mitigate this issue.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2025-11-08T02:11:07.655Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-11-07T19:42:59.404Z",
@@ -597,7 +597,7 @@
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "major",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2025-10-29T23:08:49.315Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-10-29T22:45:34.890Z",
@@ -610,7 +610,7 @@
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "none",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2025-10-25T07:08:42.798Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-10-24T20:14:16.658Z",
@@ -623,7 +623,7 @@
623
  "body": "## **Summary**\n\nOn October 22, 2025, Ashby was unavailable for approximately 20 minutes \\(4:00 PM to 4:19 PM UTC\\). Due to a bug introduced five hours earlier, a critical service in Ashby\u2019s infrastructure began to fail, causing our application to become unavailable. Customer job boards remained functional during this period.\n\nOnce we resolved the availability issue, we disabled the Workday and Analytics syncs and gradually increased their frequency over approximately 1 hour and 45 minutes, from 5:29 PM UTC to 7:15 PM UTC.\n\n## **Why did this happen?**\n\nBefore the incident, a bug was introduced to our application code that ran on an automated schedule. Over the course of five hours, the bug caused an increasing amount of network traffic to a critical service that the application code communicated with. Approximately 10 minutes before the incident, the increased network traffic caused a sudden spike in memory usage on the virtual machine hosting the critical service, resulting in the virtual machine running out of memory and the service failing.\u00a0\n\n## **How did we resolve the situation?**\n\nOn Thursday, October 22, 2025, at 10:48AM UTC, we deployed the application code change containing the bug.\n\nAt 4:00 PM UTC, various automated monitors alerted our team that Ashby was unavailable, and an incident was initiated by our On-call Engineer.\n\nAt 4:09 PM UTC, we determined the service failed due to the virtual machine running out of memory and began the process of failing over the service to a backup virtual machine.\n\nAt 4:19PM UTC, the service was restored, and we confirmed Ashby was available.\n\nAt 4:33PM UTC, we identified the probable cause and began reverting the change that introduced the bug.\n\nAt 6:09PM UTC, we verified the bug we suspected was the root cause. At 6:15PM UTC, the revert was shipped to production.\n\nAt 6:16PM UTC, out of an abundance of caution, we slowly increased the frequency the application code was run while monitoring the critical service it communicated with.\n\nAt 7:15 PM UTC, we felt confident that we had removed any effects introduced by the identified bug and restored the application code to its normal schedule. Because we hadn\u2019t run the normal schedule for several hours, it would take time for the application code to go through the backlog of tasks it needed to perform.\n\nAt 8:07PM UTC, the backlog of tasks was completed, and we resolved the incident.\n\n## **What have we put in place to prevent it from happening in the future?**\n\nOnce we identified the root cause and resolved the incident, we immediately implemented two changes to detect or prevent this issue from recurring:\n\n* **Monitors that detect and alert our team to outliers in network traffic to our critical service.**\n* **We deployed a change that removed the network traffic side effect that caused the incident.** The bug uncovered this side effect.\n\n**Our team has also committed to moving the critical service that failed to virtual machines that auto-scale.** One of the reasons the critical service failed was that we had explicitly allocated a specific amount of memory for the virtual machine, and when that limit was reached, the machine failed. We will be transitioning this service to one that enables our cloud service provider to automatically scale both the size \\(including available memory\\) and the number of machines on which the service runs.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2025-10-22T20:07:00.952Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-10-22T16:06:36.330Z",
@@ -636,7 +636,7 @@
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2025-10-22T17:36:30.745Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-10-22T13:53:49.563Z",
@@ -649,7 +649,7 @@
649
  "body": "This incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2025-10-21T21:37:30.789Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-10-21T18:30:46.000Z",
 
3
  "slug": "ashby",
4
  "platform": "statuspage",
5
  "status_url": "https://status.ashbyhq.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "Our upstream provider has resolved the issue.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "major",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-31T18:11:38.708Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-31T17:44:26.072Z",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-09T13:00:20.391Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-07T19:11:00.100Z",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-07-27T21:12:55.243Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-27T14:56:43.923Z",
 
51
  "body": "This incident has been resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "major",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-16T11:00:55.444Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-16T08:40:00.000Z",
 
64
  "body": "For approximately 11 minutes from 10:19 AM PDT to 10:30 AM PDT, Ashby users experienced long-running loading screens and, in some cases, errors. This was the result of requests to our servers taking too long to respond. Candidates applying for jobs were unaffected.\n\nOur maintenance this weekend will address the root cause of this issue by increasing our database capacity.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "none",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-13T17:19:00.000Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-13T17:19:00.000Z",
 
77
  "body": "This incident has been resolved. Resumes that failed to parse during the incident have been backfilled.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-07-08T04:17:54.867Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-08T00:40:32.296Z",
 
90
  "body": "From 11:30am until 1:40pm PDT, candidate PDF exports failed with a generic message. The cause of this issue has already been identified and fixed.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "none",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-07-06T18:30:00.000Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-06T18:30:00.000Z",
 
103
  "body": "Our upstream provider, Cloudflare, has implemented a fix and our tests indicate they have resolved the issue.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-02T02:14:47.126Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-01T20:19:55.143Z",
 
116
  "body": "We've confirmed Ashby is available again in the Sydney region. We will work with our upstream provider to understand what happened.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-07-01T19:03:07.080Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-07-01T18:49:25.490Z",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-06-24T22:21:00.145Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-24T21:16:01.044Z",
 
142
  "body": "We're experiencing an issue sending Slack and email notifications for interview reminders between 4:00PM and 5:00PM (UTC)",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-06-24T16:00:00.000Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-06-24T16:00:00.000Z",
 
155
  "body": "We're experiencing an issue sending Slack and email notifications for interview reminders between 4:00PM and 7:00PM (UTC)",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-06-22T16:00:00.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-06-22T16:00:00.000Z",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-06-19T14:20:28.773Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-06-19T13:47:54.028Z",
 
181
  "body": "Integrations degraded due to an infrastructure issue. Affected services include Google Workspace integration (including sending via Gmail); ATS syncs; autocomplete for candidate resumes/locations; and some AI features.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "major",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-06-19T06:30:00.000Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-06-19T06:30:00.000Z",
 
194
  "body": "This incident has been resolved.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-06-16T09:22:02.333Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-06-16T08:21:44.130Z",
 
207
  "body": "## **Summary**\n\nOn Monday, June 15, from approximately 4:00 AM PDT to 10:26 AM PDT, Safari and iOS users encountered an error with embedded and Ashby-hosted job boards \\([jobs.ashbyhq.com](http://jobs.ashbyhq.com)\\) and could not view or apply to jobs.\u00a0\n\nWe became aware of the problem at 9:43 AM PDT and recovered at 10:26 AM PDT.\n\n## **Why did this happen?**\n\nAshby's internal code build process processes the code that powers your hosted and embedded job boards. As part of our security practices, each file is published with verification data that browsers use to confirm the file they download is exactly what we intend to serve. We shipped a change to this build process that modified the files after their verification data had been generated, so the files no longer matched the verification data and failed to load in Safari and iOS mobile browsers. The same files did not fail in the same way in other browsers, such as Chrome and Firefox, which is why the failure appeared inconsistent amongst visitors.\n\n## **How did we resolve this situation?**\n\nAfter confirming the failure was tied to a recent deploy, we rolled back to a known-good state to restore service. We confirmed that job boards loaded correctly in Safari, on mobile devices, and in other browsers before resuming normal deployments.\n\n## **How did we get to this point?**\n\nThe change altered our shipped code in a way we did not anticipate, and two gaps let it reach production undetected:\u00a0\n\n1. Our automated job board tests ran only against Chrome.\n2. We didn\u2019t have a check verifying file integrity at the point of publishing, where this particular failure surfaced.\n\n## **What have we put in place to prevent this from happening in the future?**\n\n1. We added an automated check that verifies file integrity immediately before publishing; any mismatch now blocks the deployment of updates to Ashby. We confirmed it catches this exact failure.\n2. We corrected how integrity verification is applied to our job board code, so that all browsers enforce it consistently.\n3. We expanded our automated job board tests to run against Safari and Firefox, not just Chrome.\n4. We have added additional monitoring, including on mobile browsers, to alert us directly when a job board fails to load in this way.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "major",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-06-15T19:15:43.381Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-06-15T16:59:16.420Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-06-02T21:57:01.078Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-06-02T14:55:08.350Z",
 
233
  "body": "## **Summary**\n\nOn Sunday, May 31st, at 10pm PST, Ashby was slow and had a high error rate for approximately 1 hour, from 10pm to 11:10pm \\(PST\\).\n\nDuring this time, the Ashby main application would have been slow, and approximately 50% of user actions would have resulted in Ashby displaying an error. Some candidates may have noticed a slower response to their job applications, but all applications were successful and none were lost.\n\n## **Why did this happen?**\n\nOn Sunday, May 31st, at 4pm PST, an account with one of our AI providers became unavailable. As a result, calls to that provider started to error. These calls are configured to automatically retry periodically until they succeed, but the retries caused a steady increase in the number of such calls per minute. In turn, this drained the capacity of a shared subsystem that manages many different processes at Ashby.\n\nIn particular, that shared subsystem is used for storing user session data. As the shared subsystem became overwhelmed, user sessions became slower to respond.\n\nThis caused requests to our web servers to take significantly longer to process. Which then caused our web servers to begin running out of capacity.\n\nAt 6am, capacity reached a critical low. At this point, our system began rejecting user actions. This is done to prevent complete system failure.\n\n## **How did we resolve the situation?**\n\nAt 10:04pm PST, our on-call engineers were notified. By 10:16pm PST, our on-call engineers were beginning an investigation.\n\nAt 11:03pm PST, we identified the subsystem that had reached capacity.\n\nAt 11:07pm PST, we stopped processing certain types of automated actions.\n\nAt 11:09pm PST, we identified the issue with the external provider and rectified it immediately.\n\nAt 11:10pm PST, error rates were down to 10%.\n\nAt 11:20pm PST, error rates were down to normal levels \\(~0%\\).\n\nAt 11:54pm PST, normal service was resumed, and no data was lost.\n\n## **What have we put in place to prevent it from happening in the future?**\n\nWe\u2019ve done an internal postmortem on this incident and have implemented or plan to implement a variety of changes that achieve three things:\n\n1. Reduced the likelihood of future failure\n2. Faster incident response times\n3. Lower impact on customers in the event of failure\n\nSpecifically, we have done the following:\n\n* We were already in the process of replacing the subsystem at the center of the outage. We have accelerated that work. The replacement is not vulnerable to this particular kind of failure.\n* We\u2019ve added additional monitoring around our AI providers to alert us to failures like this sooner.\n* We are prioritizing a fix for the retry mechanism that led to this incident.\n* We are migrating our user session storage to a new subsystem that is not vulnerable to this particular kind of failure.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-06-01T09:04:00.602Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-06-01T06:33:08.355Z",
 
246
  "body": "This incident has been resolved.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-05-29T15:55:09.399Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-05-29T13:41:51.731Z",
 
259
  "body": "This incident has been resolved.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "minor",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-05-28T15:14:38.306Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-05-28T13:34:26.412Z",
 
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-05-15T21:59:10.226Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-05-15T21:10:11.507Z",
 
285
  "body": "This incident has been resolved.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-05-15T00:58:53.849Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-05-15T00:19:30.985Z",
 
298
  "body": "The issue has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-04-01T00:13:02.842Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-03-31T22:43:10.120Z",
 
311
  "body": "This incident has been resolved.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-03-24T18:51:04.355Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-03-24T15:43:13.025Z",
 
324
  "body": "### **Summary**\n\nFor a brief period on Monday, March 24, and from Tuesday, March 25 to Thursday, March 27, 2026, Ashby's scheduling features displayed incorrect interviewer availability for a subset of organizations with the\u00a0 Google Workspace integration. This allowed candidates to be scheduled even when an interviewer may already have a meeting. This bug affected the following scheduling features:\n\n* Manual scheduling\n* Direct booking links\n* Advanced scheduling\n\nThe issue only impacted organizations using Google Calendar sync without domain-wide delegation.\n\n### **Why did this happen?**\n\nAshby integrates with Google Calendar to display interviewer availability and power our scheduling features. Because some interviewers aren\u2019t authenticated Ashby users, we occasionally read their calendar data on behalf of a user who is. A code change deployed on March 24 updated the calendar synchronization logic as part of an improvement to our Google Calendar authorization process. A bug in this logic incorrectly conflated the interviewer\u2019s calendar with the authenticated user's, resulting in inaccurate availability being displayed during scheduling.\n\nThe code change was initially deployed on March 24, then briefly reverted, and redeployed on March 25, which is why there were separate windows of impact.\n\n### **How did we resolve the situation?**\n\nThe bug was active during three separate windows:\n\n* Monday, March 24, 8:21 AM - 9:52 AM PDT \\(approximately 1.5 hours\\)\u00a0\n* Tuesday, March 25, 7:05 AM - 7:52 AM PDT \\(approximately 47 minutes\\)\u00a0\n* Tuesday, March 25, 9:52 AM - Thursday, March 27, 5:34 AM PDT \\(approximately 44 hours\\)\u00a0\n\nOn Thursday, March 27, 2026, at 4:31 AM PDT, a customer reported that an interviewer\u2019s availability appeared incorrect. At 5:10 AM PDT, we identified the root cause, and at 5:34 AM PDT, we deployed a fix and triggered calendar resyncs for affected organizations to restore accurate availability data.\n\n### **What have we put in place to prevent it from happening in the future?**\n\n1. **Improved static analysis checks.** We improved static analysis checks to ensure similar code changes are analyzed for correctness before they reach production.\u00a0\n2. **Improved testing for calendar authorization scenarios.** The bug affected a specific authorization configuration that is difficult to replicate in our test environments. We are building improved test tooling to enable automated tests across even more permutations of integration configurations.\n3. **Better monitoring for calendar sync accuracy.** We are adding monitoring that will alert us when calendar data retrieved through this particular authorization path does not match the intended user.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-03-24T15:00:00.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-03-24T15:00:00.000Z",
 
337
  "body": "The incident has been resolved.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "minor",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-03-12T16:15:13.262Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-03-12T15:47:36.617Z",
 
350
  "body": "This incident has been resolved.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-03-12T13:07:44.681Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-03-12T12:56:30.491Z",
 
363
  "body": "This incident has been resolved.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-03-04T20:44:31.122Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-03-04T19:59:54.223Z",
 
376
  "body": "This incident has been resolved.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-02-24T17:36:46.223Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-02-24T16:35:58.809Z",
 
389
  "body": "This incident has been resolved.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "minor",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-02-20T19:45:52.776Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-02-20T18:59:07.761Z",
 
402
  "body": "The issue has been resolved by the upstream provider.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-02-13T10:15:33.592Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-02-13T05:10:17.969Z",
 
415
  "body": "Resolved: Reporting data is now up to date. Thank you for your patience.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "minor",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-02-12T18:46:13.008Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-02-12T16:30:50.651Z",
 
428
  "body": "This incident has been resolved.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2026-02-04T17:46:31.992Z",
433
  "resolved_inferred": false,
434
  "started_at": "2026-02-04T16:46:56.128Z",
 
441
  "body": "This incident has been resolved.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "minor",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2026-01-23T13:16:05.295Z",
446
  "resolved_inferred": false,
447
  "started_at": "2026-01-22T22:00:22.000Z",
 
454
  "body": "This incident has been resolved.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "minor",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2026-01-20T22:49:52.884Z",
459
  "resolved_inferred": false,
460
  "started_at": "2026-01-20T16:30:37.000Z",
 
467
  "body": "We've implemented a fix and verified offer templates and workflows are working.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2026-01-06T18:21:12.059Z",
472
  "resolved_inferred": false,
473
  "started_at": "2026-01-06T17:52:38.000Z",
 
480
  "body": "Dropbox Sign has resolved their downtime, and we've verified e-signature works in Ashby.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "critical",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2026-01-02T23:36:38.725Z",
485
  "resolved_inferred": false,
486
  "started_at": "2026-01-02T21:12:50.120Z",
 
493
  "body": "We saw elevated errors loading candidate profiles and sending emails starting at 12:08 UTC.\n\nWe resolved this at 12:56 UTC.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "none",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-12-16T12:08:00.000Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-12-16T12:08:00.000Z",
 
506
  "body": "This incident has been resolved.",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "critical",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-12-05T09:46:46.687Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-12-05T09:07:15.618Z",
 
519
  "body": "This incident has been resolved.",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "major",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-12-04T21:18:09.760Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-12-04T19:25:56.850Z",
 
532
  "body": "Cloudflare's scheduled maintenance is finished, and we're no longer seeing any service degradation.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "minor",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-12-03T19:03:07.010Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-12-03T15:58:33.000Z",
 
545
  "body": "Ashby-hosted job boards are operational again. We have identified the root cause and are addressing it.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "major",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-12-02T13:44:53.944Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-12-02T13:37:41.005Z",
 
558
  "body": "We have noticed increased errors loading https://app.ashbyhq.com.\nThe issue has been resolved and the app is responsive again.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "none",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2025-11-20T12:14:35.986Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-11-20T12:14:35.939Z",
 
571
  "body": "We have resolved an issue that caused errors with manually rescheduling candidates between 9:10 AM and 10:30 AM UTC.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "none",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-11-17T10:42:59.642Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-11-17T10:42:59.583Z",
 
584
  "body": "We have deployed changes that mitigate this issue.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "minor",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2025-11-08T02:11:07.655Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-11-07T19:42:59.404Z",
 
597
  "body": "This incident has been resolved.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "major",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2025-10-29T23:08:49.315Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-10-29T22:45:34.890Z",
 
610
  "body": "This incident has been resolved.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "none",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2025-10-25T07:08:42.798Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-10-24T20:14:16.658Z",
 
623
  "body": "## **Summary**\n\nOn October 22, 2025, Ashby was unavailable for approximately 20 minutes \\(4:00 PM to 4:19 PM UTC\\). Due to a bug introduced five hours earlier, a critical service in Ashby\u2019s infrastructure began to fail, causing our application to become unavailable. Customer job boards remained functional during this period.\n\nOnce we resolved the availability issue, we disabled the Workday and Analytics syncs and gradually increased their frequency over approximately 1 hour and 45 minutes, from 5:29 PM UTC to 7:15 PM UTC.\n\n## **Why did this happen?**\n\nBefore the incident, a bug was introduced to our application code that ran on an automated schedule. Over the course of five hours, the bug caused an increasing amount of network traffic to a critical service that the application code communicated with. Approximately 10 minutes before the incident, the increased network traffic caused a sudden spike in memory usage on the virtual machine hosting the critical service, resulting in the virtual machine running out of memory and the service failing.\u00a0\n\n## **How did we resolve the situation?**\n\nOn Thursday, October 22, 2025, at 10:48AM UTC, we deployed the application code change containing the bug.\n\nAt 4:00 PM UTC, various automated monitors alerted our team that Ashby was unavailable, and an incident was initiated by our On-call Engineer.\n\nAt 4:09 PM UTC, we determined the service failed due to the virtual machine running out of memory and began the process of failing over the service to a backup virtual machine.\n\nAt 4:19PM UTC, the service was restored, and we confirmed Ashby was available.\n\nAt 4:33PM UTC, we identified the probable cause and began reverting the change that introduced the bug.\n\nAt 6:09PM UTC, we verified the bug we suspected was the root cause. At 6:15PM UTC, the revert was shipped to production.\n\nAt 6:16PM UTC, out of an abundance of caution, we slowly increased the frequency the application code was run while monitoring the critical service it communicated with.\n\nAt 7:15 PM UTC, we felt confident that we had removed any effects introduced by the identified bug and restored the application code to its normal schedule. Because we hadn\u2019t run the normal schedule for several hours, it would take time for the application code to go through the backlog of tasks it needed to perform.\n\nAt 8:07PM UTC, the backlog of tasks was completed, and we resolved the incident.\n\n## **What have we put in place to prevent it from happening in the future?**\n\nOnce we identified the root cause and resolved the incident, we immediately implemented two changes to detect or prevent this issue from recurring:\n\n* **Monitors that detect and alert our team to outliers in network traffic to our critical service.**\n* **We deployed a change that removed the network traffic side effect that caused the incident.** The bug uncovered this side effect.\n\n**Our team has also committed to moving the critical service that failed to virtual machines that auto-scale.** One of the reasons the critical service failed was that we had explicitly allocated a specific amount of memory for the virtual machine, and when that limit was reached, the machine failed. We will be transitioning this service to one that enables our cloud service provider to automatically scale both the size \\(including available memory\\) and the number of machines on which the service runs.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2025-10-22T20:07:00.952Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-10-22T16:06:36.330Z",
 
636
  "body": "This incident has been resolved.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "minor",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2025-10-22T17:36:30.745Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-10-22T13:53:49.563Z",
 
649
  "body": "This incident has been resolved.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "minor",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2025-10-21T21:37:30.789Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-10-21T18:30:46.000Z",
api/v/assembled.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "assembled",
4
  "platform": "statuspage",
5
  "status_url": "https://status.assembled.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-31T19:14:41.481Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-31T17:30:32.201Z",
@@ -25,7 +25,7 @@
25
  "body": "The underlying issue has been resolved. \n\n**Action from your team is required.** A Salesforce admin will need to reauthenticate the connection to restore syncing. In Assembled, go to Configure \u2192 Third-Party Integrations \u2192 Integrations, find Salesforce, disable the connection, then reconnect using an active admin account. Once reauthenticated, our team will help ensure your data syncs properly again. \n\nPlease contact support@assembled.com once you've reauthenticated your Salesforce integration in Assembled.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-21T04:53:03.823Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-21T01:54:20.002Z",
@@ -38,7 +38,7 @@
38
  "body": "We've identified and address the root cause and are now operating normally again.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-07-22T23:50:45.518Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-22T23:11:14.000Z",
@@ -51,7 +51,7 @@
51
  "body": "Increased load in API requests affected our APIs and Voice services, leading to increased latency. For voice, we temporarily diverted traffic to live agents as we investigated and resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-20T15:00:00.000Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-20T15:00:00.000Z",
@@ -64,7 +64,7 @@
64
  "body": "We've returned to normal levels of latency and error rates across all services.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-15T17:24:12.504Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-15T00:40:22.912Z",
@@ -77,7 +77,7 @@
77
  "body": "All APIs and the Assembled web application are fully functional.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-07-13T18:53:40.706Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-13T15:30:47.000Z",
@@ -90,7 +90,7 @@
90
  "body": "Data affected during the period has been successfully retried.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-07-10T17:56:07.389Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-10T16:52:55.000Z",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-07-09T21:24:53.204Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-09T21:13:08.362Z",
@@ -116,7 +116,7 @@
116
  "body": "Between 2:07pm ET to 2:25pm ET, our retrieval of agent states and tickets was delayed and we were not receiving data during this time. Our engineering team has resolved the issue and is applying agent state exclusions for any affected customers during this time period.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-06-10T18:07:00.000Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-10T18:07:00.000Z",
@@ -129,7 +129,7 @@
129
  "body": "After continued monitoring, we have confirmed that all systems remain fully restored and reporting data is displaying as expected. This incident is now resolved. Thank you for your patience throughout this process.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-06-04T15:01:03.370Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-01T00:02:57.369Z",
@@ -142,7 +142,7 @@
142
  "body": "Reporting data is now fully up to date.\n\nAll operations related to the database upgrade are now complete.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-05-30T08:05:07.310Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-30T05:38:39.580Z",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved. A database operation degraded performance, which caused pages across the product to become unresponsive. We\u2019re reviewing our database operation safeguards and monitoring to reduce the likelihood of similar issues in the future.\n\n[6:53 AM PT ] Our voice agent is still unavailable as the system recovers, but we are successfully able to transfer callers to a live agent upon error.\n\n[7:08 AM PT] The voice agent is healthy and available.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-05-15T13:53:41.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-15T13:44:57.000Z",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved. A database operation degraded performance, which caused pages across the product to become unresponsive. We\u2019re reviewing our database operation safeguards and monitoring to reduce the likelihood of similar issues in the future.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-05-12T18:23:17.000Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-12T18:03:02.000Z",
@@ -181,7 +181,7 @@
181
  "body": "Between 6:30pm ET on May 6th and 7am ET on May 7th, some customers saw missing or zero values in reporting surfaces (including support volume and queue/exclusion views) for data values that appeared after 6:30pm ET on 5/6/2026 due to delayed replication in one of our data-processing tasks. \n\nData ingestion itself continued normally and no conversation data was lost, the issue was isolated to metric freshness/display. \n\nWe restored the task, backfilled dependent metrics, and service is now operating normally, with additional monitoring improvements underway to prevent recurrence.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-05-07T11:15:47.000Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-07T11:15:47.000Z",
@@ -194,7 +194,7 @@
194
  "body": "The issue with proxied APIs in workflows has now been resolved and they work as expected.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "none",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-04-29T00:01:40.927Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-28T23:46:59.488Z",
@@ -207,7 +207,7 @@
207
  "body": "Between 10:56 AM and 11:09 AM PT, a subset of sync jobs responsible for retrieving agent states and ticket updates experienced intermittent failures. The underlying issue has been identified and resolved, and we have verified that all affected ticket updates are now backfilling any data.\n\nWe've also added a system-level agent state exclusion to ensure that these failures do not affect adherence and are conducting a postmortem to identify any system improvements that can be made.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-04-24T18:21:05.027Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-24T18:21:04.973Z",
@@ -220,7 +220,7 @@
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-03-30T17:40:28.441Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-30T17:18:56.700Z",
@@ -233,7 +233,7 @@
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-03-06T19:27:21.572Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-06T16:17:59.402Z",
@@ -246,7 +246,7 @@
246
  "body": "Upstream provider service outage caused the Assembled voice agent to experience elevated latency and error rates. Once root cause was confirmed, we proactively diverted all traffic to human agents.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-03-05T00:51:56.000Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-05T00:51:56.000Z",
@@ -259,7 +259,7 @@
259
  "body": "This incident has been resolved, and we will continue to recover past data into Assembled",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "major",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-03-03T17:16:05.080Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-03T12:57:27.195Z",
@@ -272,7 +272,7 @@
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-02-26T22:58:52.338Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-02-26T22:31:44.735Z",
@@ -285,7 +285,7 @@
285
  "body": "We have identified and resolved the issue with Copilot\u2019s Draft reply. The root cause was an upstream model provider intermittently returning responses in an unexpected format that bypassed our existing fallback logic. We're identifying improvements to prevent future impact on customers.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "major",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-02-24T21:35:52.000Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-02-24T21:05:15.000Z",
@@ -298,7 +298,7 @@
298
  "body": "All forecasts have been regenerated and the incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2025-12-21T00:00:56.000Z",
303
  "resolved_inferred": false,
304
  "started_at": "2025-12-19T19:35:10.553Z",
@@ -311,7 +311,7 @@
311
  "body": "We've fixed the bug causing errors on the staffing timeline. We apologize for the inconvenience!",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2025-12-17T21:37:47.921Z",
316
  "resolved_inferred": false,
317
  "started_at": "2025-12-17T21:04:11.332Z",
@@ -324,7 +324,7 @@
324
  "body": "Voice agent experiencing increased latency",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "none",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2025-11-14T11:00:00.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2025-11-14T11:00:00.000Z",
@@ -337,7 +337,7 @@
337
  "body": "All services are now operational.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "major",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2025-10-20T22:30:52.588Z",
342
  "resolved_inferred": false,
343
  "started_at": "2025-10-20T14:57:01.000Z",
@@ -350,7 +350,7 @@
350
  "body": "A fix has been implemented from our provider and we've seen almost all of our underlying services recover. We'll be adding agent state exclusions for the affected time period and will continue to monitor other services as they come back online.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2025-10-20T10:44:33.876Z",
355
  "resolved_inferred": false,
356
  "started_at": "2025-10-20T10:23:00.563Z",
@@ -363,7 +363,7 @@
363
  "body": "Activities should now be syncing successfully into Google Calendar from Assembled.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2025-09-23T07:45:26.000Z",
368
  "resolved_inferred": false,
369
  "started_at": "2025-09-23T03:00:45.855Z",
@@ -376,7 +376,7 @@
376
  "body": "This incident has been resolved. Google has published a report regarding this issue: https://www.google.com/appsstatus/dashboard/incidents/oFcAZTr4EVieF5Fr6Ee9",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2025-09-18T16:33:29.746Z",
381
  "resolved_inferred": false,
382
  "started_at": "2025-09-18T15:13:07.683Z",
@@ -389,7 +389,7 @@
389
  "body": "From 12:23 PM PT to 3:02 PM PT, chat handoffs were not functioning correctly. Conversations were not actually being handed off to human agents, and on the QA review page only the first message was visible even though conversations continued.\n\nThe issue has been fully resolved going forward. We are also investigating options for retrieving the missing conversation data from the affected time window.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2025-09-10T19:23:00.000Z",
394
  "resolved_inferred": false,
395
  "started_at": "2025-09-10T19:23:00.000Z",
@@ -402,7 +402,7 @@
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2025-08-21T19:37:07.971Z",
407
  "resolved_inferred": false,
408
  "started_at": "2025-08-21T19:24:31.756Z",
@@ -415,7 +415,7 @@
415
  "body": "Our upstream provider has resolved the incident, so our system is once again back in a healthy state to receive calls.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "critical",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2025-08-06T04:30:03.816Z",
420
  "resolved_inferred": false,
421
  "started_at": "2025-08-06T02:50:31.970Z",
@@ -428,7 +428,7 @@
428
  "body": "From 10:15am PT to 12:32 PT, agent messages sent from CRM platforms (Zendesk, Kustomer, etc.) were not appearing in the chat widget to end customers. This would occur for any messages escalated to live chat, but did not affect email handoff messages.\n\nWe've identified and resolved the issue and the full functionality for live chat is restored. We'll be conducting a full postmortem of this incident.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "none",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-08-04T19:46:08.740Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-08-04T19:46:08.675Z",
 
3
  "slug": "assembled",
4
  "platform": "statuspage",
5
  "status_url": "https://status.assembled.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-31T19:14:41.481Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-31T17:30:32.201Z",
 
25
  "body": "The underlying issue has been resolved. \n\n**Action from your team is required.** A Salesforce admin will need to reauthenticate the connection to restore syncing. In Assembled, go to Configure \u2192 Third-Party Integrations \u2192 Integrations, find Salesforce, disable the connection, then reconnect using an active admin account. Once reauthenticated, our team will help ensure your data syncs properly again. \n\nPlease contact support@assembled.com once you've reauthenticated your Salesforce integration in Assembled.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-21T04:53:03.823Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-21T01:54:20.002Z",
 
38
  "body": "We've identified and address the root cause and are now operating normally again.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-07-22T23:50:45.518Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-07-22T23:11:14.000Z",
 
51
  "body": "Increased load in API requests affected our APIs and Voice services, leading to increased latency. For voice, we temporarily diverted traffic to live agents as we investigated and resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "none",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-20T15:00:00.000Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-20T15:00:00.000Z",
 
64
  "body": "We've returned to normal levels of latency and error rates across all services.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-15T17:24:12.504Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-07-15T00:40:22.912Z",
 
77
  "body": "All APIs and the Assembled web application are fully functional.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-07-13T18:53:40.706Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-07-13T15:30:47.000Z",
 
90
  "body": "Data affected during the period has been successfully retried.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-07-10T17:56:07.389Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-07-10T16:52:55.000Z",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-07-09T21:24:53.204Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-07-09T21:13:08.362Z",
 
116
  "body": "Between 2:07pm ET to 2:25pm ET, our retrieval of agent states and tickets was delayed and we were not receiving data during this time. Our engineering team has resolved the issue and is applying agent state exclusions for any affected customers during this time period.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-06-10T18:07:00.000Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-06-10T18:07:00.000Z",
 
129
  "body": "After continued monitoring, we have confirmed that all systems remain fully restored and reporting data is displaying as expected. This incident is now resolved. Thank you for your patience throughout this process.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-06-04T15:01:03.370Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-06-01T00:02:57.369Z",
 
142
  "body": "Reporting data is now fully up to date.\n\nAll operations related to the database upgrade are now complete.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-05-30T08:05:07.310Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-30T05:38:39.580Z",
 
155
  "body": "This incident has been resolved. A database operation degraded performance, which caused pages across the product to become unresponsive. We\u2019re reviewing our database operation safeguards and monitoring to reduce the likelihood of similar issues in the future.\n\n[6:53 AM PT ] Our voice agent is still unavailable as the system recovers, but we are successfully able to transfer callers to a live agent upon error.\n\n[7:08 AM PT] The voice agent is healthy and available.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-05-15T13:53:41.000Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-15T13:44:57.000Z",
 
168
  "body": "This incident has been resolved. A database operation degraded performance, which caused pages across the product to become unresponsive. We\u2019re reviewing our database operation safeguards and monitoring to reduce the likelihood of similar issues in the future.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "critical",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-05-12T18:23:17.000Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-12T18:03:02.000Z",
 
181
  "body": "Between 6:30pm ET on May 6th and 7am ET on May 7th, some customers saw missing or zero values in reporting surfaces (including support volume and queue/exclusion views) for data values that appeared after 6:30pm ET on 5/6/2026 due to delayed replication in one of our data-processing tasks. \n\nData ingestion itself continued normally and no conversation data was lost, the issue was isolated to metric freshness/display. \n\nWe restored the task, backfilled dependent metrics, and service is now operating normally, with additional monitoring improvements underway to prevent recurrence.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "none",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-05-07T11:15:47.000Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-07T11:15:47.000Z",
 
194
  "body": "The issue with proxied APIs in workflows has now been resolved and they work as expected.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "none",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-04-29T00:01:40.927Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-04-28T23:46:59.488Z",
 
207
  "body": "Between 10:56 AM and 11:09 AM PT, a subset of sync jobs responsible for retrieving agent states and ticket updates experienced intermittent failures. The underlying issue has been identified and resolved, and we have verified that all affected ticket updates are now backfilling any data.\n\nWe've also added a system-level agent state exclusion to ensure that these failures do not affect adherence and are conducting a postmortem to identify any system improvements that can be made.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "none",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-04-24T18:21:05.027Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-04-24T18:21:04.973Z",
 
220
  "body": "This incident has been resolved.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-03-30T17:40:28.441Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-03-30T17:18:56.700Z",
 
233
  "body": "This incident has been resolved.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-03-06T19:27:21.572Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-03-06T16:17:59.402Z",
 
246
  "body": "Upstream provider service outage caused the Assembled voice agent to experience elevated latency and error rates. Once root cause was confirmed, we proactively diverted all traffic to human agents.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-03-05T00:51:56.000Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-03-05T00:51:56.000Z",
 
259
  "body": "This incident has been resolved, and we will continue to recover past data into Assembled",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "major",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-03-03T17:16:05.080Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-03-03T12:57:27.195Z",
 
272
  "body": "This incident has been resolved.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-02-26T22:58:52.338Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-02-26T22:31:44.735Z",
 
285
  "body": "We have identified and resolved the issue with Copilot\u2019s Draft reply. The root cause was an upstream model provider intermittently returning responses in an unexpected format that bypassed our existing fallback logic. We're identifying improvements to prevent future impact on customers.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "major",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-02-24T21:35:52.000Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-02-24T21:05:15.000Z",
 
298
  "body": "All forecasts have been regenerated and the incident has been resolved.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "minor",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2025-12-21T00:00:56.000Z",
303
  "resolved_inferred": false,
304
  "started_at": "2025-12-19T19:35:10.553Z",
 
311
  "body": "We've fixed the bug causing errors on the staffing timeline. We apologize for the inconvenience!",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "minor",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2025-12-17T21:37:47.921Z",
316
  "resolved_inferred": false,
317
  "started_at": "2025-12-17T21:04:11.332Z",
 
324
  "body": "Voice agent experiencing increased latency",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "none",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2025-11-14T11:00:00.000Z",
329
  "resolved_inferred": false,
330
  "started_at": "2025-11-14T11:00:00.000Z",
 
337
  "body": "All services are now operational.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "major",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2025-10-20T22:30:52.588Z",
342
  "resolved_inferred": false,
343
  "started_at": "2025-10-20T14:57:01.000Z",
 
350
  "body": "A fix has been implemented from our provider and we've seen almost all of our underlying services recover. We'll be adding agent state exclusions for the affected time period and will continue to monitor other services as they come back online.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "major",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2025-10-20T10:44:33.876Z",
355
  "resolved_inferred": false,
356
  "started_at": "2025-10-20T10:23:00.563Z",
 
363
  "body": "Activities should now be syncing successfully into Google Calendar from Assembled.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "minor",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2025-09-23T07:45:26.000Z",
368
  "resolved_inferred": false,
369
  "started_at": "2025-09-23T03:00:45.855Z",
 
376
  "body": "This incident has been resolved. Google has published a report regarding this issue: https://www.google.com/appsstatus/dashboard/incidents/oFcAZTr4EVieF5Fr6Ee9",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "minor",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2025-09-18T16:33:29.746Z",
381
  "resolved_inferred": false,
382
  "started_at": "2025-09-18T15:13:07.683Z",
 
389
  "body": "From 12:23 PM PT to 3:02 PM PT, chat handoffs were not functioning correctly. Conversations were not actually being handed off to human agents, and on the QA review page only the first message was visible even though conversations continued.\n\nThe issue has been fully resolved going forward. We are also investigating options for retrieving the missing conversation data from the affected time window.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2025-09-10T19:23:00.000Z",
394
  "resolved_inferred": false,
395
  "started_at": "2025-09-10T19:23:00.000Z",
 
402
  "body": "This incident has been resolved.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "minor",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2025-08-21T19:37:07.971Z",
407
  "resolved_inferred": false,
408
  "started_at": "2025-08-21T19:24:31.756Z",
 
415
  "body": "Our upstream provider has resolved the incident, so our system is once again back in a healthy state to receive calls.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "critical",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2025-08-06T04:30:03.816Z",
420
  "resolved_inferred": false,
421
  "started_at": "2025-08-06T02:50:31.970Z",
 
428
  "body": "From 10:15am PT to 12:32 PT, agent messages sent from CRM platforms (Zendesk, Kustomer, etc.) were not appearing in the chat widget to end customers. This would occur for any messages escalated to live chat, but did not affect email handoff messages.\n\nWe've identified and resolved the issue and the full functionality for live chat is restored. We'll be conducting a full postmortem of this incident.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "none",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-08-04T19:46:08.740Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-08-04T19:46:08.675Z",
api/v/atera.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atera",
4
  "platform": "statuspage",
5
  "status_url": "https://status.atera.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-06-22T03:21:38.197-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-06-22T00:10:15.920-04:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-06-23T09:52:47.148-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-06-11T15:15:32.000-04:00",
@@ -38,7 +38,7 @@
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-06-09T08:31:19.381-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-06-09T03:31:52.790-04:00",
@@ -51,7 +51,7 @@
51
  "body": "The issue has been identified and resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-04-02T18:50:20.591-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-02T15:26:29.475-04:00",
@@ -64,7 +64,7 @@
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-03-09T13:11:34.294-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-03-09T11:14:12.039-04:00",
@@ -77,7 +77,7 @@
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-03-09T11:24:52.342-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-03-09T10:01:57.047-04:00",
@@ -90,7 +90,7 @@
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-02-22T14:08:49.676-05:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-02-22T11:43:39.540-05:00",
@@ -103,7 +103,7 @@
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-02-11T20:30:04.721-05:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-02-11T18:47:59.356-05:00",
@@ -116,7 +116,7 @@
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-01-12T10:08:23.557-05:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-01-12T06:48:51.009-05:00",
@@ -129,7 +129,7 @@
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-01-12T06:38:53.881-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-01-12T05:28:29.564-05:00",
@@ -142,7 +142,7 @@
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-01-05T02:47:08.128-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-01-05T02:22:16.905-05:00",
@@ -155,7 +155,7 @@
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-12-05T05:18:41.637-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-05T04:11:54.789-05:00",
@@ -168,7 +168,7 @@
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-11-18T11:12:57.623-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-18T07:15:58.000-05:00",
@@ -181,7 +181,7 @@
181
  "body": "Fix: This issue has been fully resolved in collaboration with Microsoft.\nAction Required: You can now safely download and install the latest MSI installer",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2025-09-11T09:04:40.116-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-09-11T03:40:15.000-04:00",
 
3
  "slug": "atera",
4
  "platform": "statuspage",
5
  "status_url": "https://status.atera.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-06-22T03:21:38.197-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-06-22T00:10:15.920-04:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "none",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-06-23T09:52:47.148-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-06-11T15:15:32.000-04:00",
 
38
  "body": "This incident has been resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "none",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-06-09T08:31:19.381-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-06-09T03:31:52.790-04:00",
 
51
  "body": "The issue has been identified and resolved.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-04-02T18:50:20.591-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-02T15:26:29.475-04:00",
 
64
  "body": "This incident has been resolved.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "major",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-03-09T13:11:34.294-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-03-09T11:14:12.039-04:00",
 
77
  "body": "This incident has been resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-03-09T11:24:52.342-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-03-09T10:01:57.047-04:00",
 
90
  "body": "This incident has been resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-02-22T14:08:49.676-05:00",
95
  "resolved_inferred": false,
96
  "started_at": "2026-02-22T11:43:39.540-05:00",
 
103
  "body": "This incident has been resolved.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-02-11T20:30:04.721-05:00",
108
  "resolved_inferred": false,
109
  "started_at": "2026-02-11T18:47:59.356-05:00",
 
116
  "body": "This incident has been resolved.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "major",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-01-12T10:08:23.557-05:00",
121
  "resolved_inferred": false,
122
  "started_at": "2026-01-12T06:48:51.009-05:00",
 
129
  "body": "This incident has been resolved.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-01-12T06:38:53.881-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2026-01-12T05:28:29.564-05:00",
 
142
  "body": "This incident has been resolved.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-01-05T02:47:08.128-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2026-01-05T02:22:16.905-05:00",
 
155
  "body": "This incident has been resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "major",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-12-05T05:18:41.637-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-12-05T04:11:54.789-05:00",
 
168
  "body": "This incident has been resolved.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "major",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-11-18T11:12:57.623-05:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-11-18T07:15:58.000-05:00",
 
181
  "body": "Fix: This issue has been fully resolved in collaboration with Microsoft.\nAction Required: You can now safely download and install the latest MSI installer",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2025-09-11T09:04:40.116-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-09-11T03:40:15.000-04:00",
api/v/athennian.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "athennian",
4
  "platform": "statuspage",
5
  "status_url": "https://athennian.statuspage.io",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "degraded",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "This incident has been resolved. The issue causing documents and folders to appear missing in Minute Books for a subset of entities has been fixed, and we've confirmed normal behavior is restored. If you continue to experience any issues, please contact support.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-08-28T21:51:04.540-06:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T11:30:20.000-06:00",
@@ -25,7 +25,7 @@
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-03-06T16:47:10.853-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-03-06T14:30:01.313-07:00",
@@ -38,7 +38,7 @@
38
  "body": "The site is currently back online, though some components may still experience intermittent degradation or elevated latency.\n\nAWS continues to work on restoring the affected infrastructure and services within the Middle East region. While our primary services are recovering, we are keeping the incident open as we monitor system stability and wait for final confirmation of full resolution from AWS.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "started_at": "2026-03-02T10:27:22.000-07:00",
43
  "state": "monitoring",
44
  "title": "AWS Middle East Region Disruption",
@@ -49,7 +49,7 @@
49
  "body": "This incident has been resolved.",
50
  "first_seen": "2026-09-04T07:06:16Z",
51
  "impact": "major",
52
- "last_seen": "2026-09-04T09:06:33Z",
53
  "resolved_at": "2025-11-18T13:51:25.319-07:00",
54
  "resolved_inferred": false,
55
  "started_at": "2025-11-18T07:42:48.315-07:00",
 
3
  "slug": "athennian",
4
  "platform": "statuspage",
5
  "status_url": "https://athennian.statuspage.io",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "degraded",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "This incident has been resolved. The issue causing documents and folders to appear missing in Minute Books for a subset of entities has been fixed, and we've confirmed normal behavior is restored. If you continue to experience any issues, please contact support.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-08-28T21:51:04.540-06:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-08-28T11:30:20.000-06:00",
 
25
  "body": "This incident has been resolved.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-03-06T16:47:10.853-07:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-03-06T14:30:01.313-07:00",
 
38
  "body": "The site is currently back online, though some components may still experience intermittent degradation or elevated latency.\n\nAWS continues to work on restoring the affected infrastructure and services within the Middle East region. While our primary services are recovering, we are keeping the incident open as we monitor system stability and wait for final confirmation of full resolution from AWS.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "started_at": "2026-03-02T10:27:22.000-07:00",
43
  "state": "monitoring",
44
  "title": "AWS Middle East Region Disruption",
 
49
  "body": "This incident has been resolved.",
50
  "first_seen": "2026-09-04T07:06:16Z",
51
  "impact": "major",
52
+ "last_seen": "2026-09-04T10:17:20Z",
53
  "resolved_at": "2025-11-18T13:51:25.319-07:00",
54
  "resolved_inferred": false,
55
  "started_at": "2025-11-18T07:42:48.315-07:00",
api/v/atlassian-access.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atlassian-access",
4
  "platform": "statuspage",
5
  "status_url": "https://access.status.atlassian.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-05-14T06:48:27.867Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:11:19.141Z",
@@ -25,7 +25,7 @@
25
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-05-08T19:45:31.250Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-08T01:31:38.240Z",
@@ -38,7 +38,7 @@
38
  "body": "### Summary\n\nOn April 13, 2026, between 05:49 and 06:29 UTC, customers experienced failures when attempting to log in, sign up, reset passwords, and complete multi-factor authentication flows across Atlassian cloud products. Approximately 90% of authentication requests failed during the peak impact window, affecting users in the US East and EU regions. The incident was mitigated within 40 minutes through manual intervention, and full service was restored by 06:29 UTC.\n\n### **IMPACT**\n\n* **Duration**: ~40 minutes \\(05:49\u201306:29 UTC, April 13, 2026\\)\n* **Affected regions**: US East and EU \\(authentication infrastructure serves EU traffic from US East, with traffic primarily from EU at this time of day\\).\n* **Affected products**: All Atlassian cloud products requiring authentication, including Jira, Confluence, Jira Service Management, and Trello.\n* **Customer experience**: Users attempting to log in, sign up, reset passwords, or complete MFA flows received errors. Users already logged in with active sessions were unaffected.\n\n### **ROOT CAUSE**\n\nThis incident had several contributing factors that combined to produce a failure that the system could not recover from without manual intervention.\n\n**The primary cause** was a recently enabled change that caused our authentication infrastructure to retry requests to a downstream identity service when those requests were slow to respond. This retry behaviour was rolled out to 100% of traffic earlier the same day. Under normal conditions this would be benign, but it meant that any slowness in the downstream service was amplified. Since multiple upstream services were also independently retrying their own failed requests, the amplification compounded further into a retry storm.\n\n**The trigger** was a burst of legitimate user traffic. A pattern of many parallel link preview requests for a single user caused a concentrated load spike on a downstream identity service, pushing its response times above the retry threshold. On its own, this kind of spike had occurred many times before and always recovered. With the retry amplification now in effect, the spike instead created a runaway feedback loop: slow responses caused retries, retries increased load, increased load caused slower responses, preventing recovery.\n\nThe incident was mitigated by manually scaling up the downstream identity service to provide sufficient capacity to absorb the amplified load. Once scaled, the service recovered immediately, bringing authentication error rates to zero within one minute.\n\n**REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe are taking the following actions designed to prevent recurrence and improve our resilience:\n\n1. **Immediate**: The retry-on-timeout change has been disabled.\n2. **Load shedding and self-healing**: We are adding load shedding capabilities to our authentication services so that they can automatically shed excess load and self-recover during traffic spikes, without requiring action before automatic scaling starts.\n3. **Reducing request fan-out**: We are reviewing patterns where a single user action can generate many parallel downstream requests, and will introduce methods where possible to reduce the amplification potential.\n\nWe apologize to customers whose services were interrupted by this incident and we are taking immediate steps to improve the platform\u2019s reliability.\n\nThanks,\n\nAtlassian Customer Support",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-04-13T10:17:20.783Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-04-13T07:29:46.094Z",
@@ -51,7 +51,7 @@
51
  "body": "### Summary\n\nOn April 8, 2026, between 04:46 UTC and 12:09 UTC, search functionality was unavailable or degraded across several Atlassian Cloud products, including Jira, Confluence, Jira Service Management, Rovo, Rovo Dev, Loom, Guard Standard, Customer Service Management and Atlassian Administration. \n\nA configuration change increased the resources reserved for a core system component that runs on nodes in our compute platform. On a subset of clusters configured for high\u2011density workloads, the increased reservations exceeded available node capacity interrupting search and related experiences for affected customers.\n\nThe root cause was identified and a rollback was merged at 05:42 UTC with some systems seeing recovery by 07:33 UTC**.** Core search functionality was restored approximately by 08:55 UTC, and full downstream recovery completed by 12:09 UTC.\n\n### **IMPACT**\n\nDuring the impact period, some customers experienced outages or degradation in search across Jira, Confluence, Jira Service Management, Rovo, Rovo Dev, Loom, Guard Standard, Customer Service Management and Atlassian Administration. Other experiences that rely on search such as quick find, navigation, AI assistants, dashboards, were also intermittently affected during this period.\n\nImpacted customers may have been unable to find pages or recordings and experienced degraded performance in finding issues; received empty or delayed search results; or experienced AI assistants and dashboards that could not retrieve relevant context.\n\n**Jira, Jira Service Management and Customer Service Management:** Search and experiences that depend on search like finding issues and agent responses in CSM remained available but with degraded performance in fallback mode. By 12:09 UTC, search indexes and search performance was fully restored from fallback to full capacity across all regions.\n\n**Guard Standard and Atlassian Administration:** Search functionality was unavailable for parts of the incident window. As a result, Domain Claims, usage tracking, and managed accounts were degraded for portions of the window. These services were restored to operational status by 07:33 UTC. Guard Premium was not impacted by this issue.\n\n**Confluence:** Search functionality was unavailable for parts of the incident window. Recovery began at 07:30 UTC as backend search clusters were restored. Full recovery, including search index replay, completed at 11:37 UTC.\n\n**Loom:** Search functionality and some experiences that rely on Confluence Search, such as sharing to spaces\\) was unavailable for portions of the window and fully restored at 11:37 UTC.\n\n**Rovo and Rovo Dev:** Rovo agents remained responsive but experienced degraded functionality due to loss of search capabilities in underlying services. They were unable to reliably return context about work items or pages. Functionality was fully restored at 11:37 UTC.\n\n### **ROOT CAUSE**\n\nAtlassian products rely on OpenSearch clusters to power their search capabilities including issue search, content search, and AI-powered search features. \n\nAn infrastructure configuration change increased resource reservations \\(CPU & Memory\\) for a system component that runs across our compute platform. On a subset of clusters configured for high-density workloads, the increased reservations exceeded available node capacity. This caused search workloads to be evicted and, in some clusters, could not reschedule onto any available nodes impacting search functionality across affected products.\n\nThe change was deployed across multiple production clusters in a short time frame, limiting the opportunity to detect the capacity conflict in a smaller subset of clusters before it reached the wider fleet. Automated scaling systems attempted to recover by provisioning additional capacity but in the worst\u2011affected clusters this led to runaway node scaling and exhaustion of available network resources, prolonging recovery time.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe understand that service disruptions impact your productivity. In addition to our existing testing and preventative processes, Atlassian is prioritizing the following actions to help reduce the likelihood and impact of similar incidents in the future and to speed up recovery when issues occur:\n\n* **Enforce smaller deployment cohorts and larger soak for critical platform changes for these cluster types** \n Implement smaller deployment cohorts, mandatory soak periods between environments, and automated health gates so that changes are validated on a limited set of clusters before being promoted more broadly.\n* **Strengthen automated pre\u2011deploy validation for resource changes** \n Add validation checks to ensure resource changes for system components are compatible with node capacity and reserved headroom, preventing system workloads from crowding out customer workloads.\n* **Improve post\u2011deploy verification and alerting** \n Enhance monitoring and post\u2011deployment verification to detect patterns such as spikes in pending pods, runaway node scaling, and low pod\u2011IP headroom closely correlated with new configuration being rolled out.\n* **Align autoscaling behavior with capacity and safety limits** \n Align autoscaling capacity calculations with node reservations and introduce safeguards and circuit breakers to prevent runaway scaling and to enforce safe limits on node and pod IP counts.\n* **Enhance recovery automation** \n Improve automation and runbooks so we can safely disable autoscaling, remove empty nodes in bulk, and restore normal operations faster across multiple clusters in parallel.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability and to reduce the risk and impact of similar issues in future.\n\nThanks,\n\nAtlassian Customer Support",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-04-08T11:43:29.733Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-08T06:01:35.680Z",
@@ -64,7 +64,7 @@
64
  "body": "We have implemented the fix and the group page in the Admin Hub is now functioning as expected.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-02-18T11:30:29.120Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-02-18T11:28:09.872Z",
@@ -77,7 +77,7 @@
77
  "body": "### Summary\n\nOn **December 27, 2025**, between **02:48 UTC and 05:20 UTC**, some Atlassian cloud customers experienced failures in sending and receiving emails and mobile notifications. Core Jira and Confluence functionality remained available.\n\nThe issue was triggered when **TLS certificates used by Atlassian\u2019s monitoring infrastructure expired**, causing parts of our metrics pipeline to stop accepting traffic. Services responsible for email and mobile notifications had a critical path dependency on monitoring path leading to service disruptions.\n\nAll impacted services were fully restored by **05:20 UTC**, around **2.5 hours** after customer impact began.\n\n### IMPACT\n\nDuring the impact window, customers experienced:\n\n* **Outbound product email failures** \\(notifications and other product emails did not send\\).\n* **Identity and account flow failures** where emails were required \\(e.g. sign\u2011ups, password resets, one\u2011time\u2011password / step\u2011up challenges\\).\n* **Jira and Confluence mobile push notifications**\n* **Customer site activations and some admin policy changes** failing and requiring later reprocessing.\n\n### ROOT CAUSE\n\nThe incident was caused by:\n\n1. **Expired TLS certificates** on domains used by our monitoring and metrics infrastructure caused by **misconfigured DNS authorization record** which prevented automatic renewal.\n2. **Tight coupling of services to metrics publishing**, which caused them to fail when monitoring endpoints became unavailable, instead of degrading gracefully.\n\n### REMEDIAL ACTIONS PLAN & NEXT STEPS\n\nWe recognize that outages like this have a direct impact on customers\u2019 ability to receive important notifications, complete account tasks, and operate their sites.\n\nWe are prioritizing the following actions to improve our existing testing, monitoring and certificate management processes:\n\n* **Hardening monitoring and certificate infrastructure**\n\n * We are refining DNS and certificate configuration across our monitoring domains and strengthening proactive checks to detect and address failed renewals and certificate issues well before expiry.\n * We are also improving alerting on our monitoring and metrics pipeline.\n \n* **Decoupling monitoring from critical customer flows** \n We are updating services such as outbound email, identity, mobile push, provisioning, and admin policy changes so they no longer depend on metrics publishing to operate. If monitoring becomes unavailable, these services will continue to run and degrade gracefully by dropping or buffering metrics instead of failing customer operations.\n\nWe apologize to customers impacted during this incident. We are implementing the improvements above to help ensure that similar issues are avoided.\n\nThanks, \nAtlassian Customer Support",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "critical",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-12-27T05:20:20.550Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-12-27T04:42:32.884Z",
@@ -90,7 +90,7 @@
90
  "body": "On December 15th, 2025, affected Guard users in US Prod East region may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.\n\nNote: All previously failed Guard provisioning and open workflows have been replayed by Atlassian. No actions are needed from customers for these events.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-12-15T22:07:53.438Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-15T20:23:41.417Z",
@@ -103,7 +103,7 @@
103
  "body": "On December 15th, 2025, Admin Hub, Atlassian Analytics, Confluence Cloud, Ecosystem, Focus, Jira, Jira Product Discovery, Jira Service Management, and Rovo users in the prod-us-east region may have experienced performance degradations and errors on the web page and mobile apps. The issue has now been resolved, and the service is operating normally for all affected customers.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2025-12-15T19:02:03.786Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-12-15T16:16:25.657Z",
@@ -116,7 +116,7 @@
116
  "body": "Impacted customers have now confirmed that they are receiving their emails as expected.\n\nIf you do continue to see these emails being missing or delayed, please check in with your organizations email admin to review and release them.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2025-11-17T00:11:36.845Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-11-13T18:56:12.844Z",
@@ -129,7 +129,7 @@
129
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-10-21T05:24:26.990Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-10-20T07:56:12.795Z",
@@ -142,7 +142,7 @@
142
  "body": "### **SUMMARY**\n\nOn September 22, 2025, between 04:38 and 04:48 UTC, Atlassian customers experienced connection errors preventing access to their [atlassian.net](http://atlassian.net/) sites. Some customers observed intermittent errors as services gradually recovered until 06:17 UTC.\n\nThe event was triggered by a faulty configuration change to our Content Delivery Network \\(CDN\\). The change included an invalid hostname which prevented customers from successfully connecting to [atlassian.net](http://atlassian.net/) domains.\n\nThe incident was detected within 1 minute by our monitoring systems and mitigated by rolling back the change, which put Atlassian systems into a known good state. The acute impact was resolved in 10 minutes and all lingering errors resolved in 1 hour 38 minutes.\n\n### **IMPACT**\n\nThe acute impact occurred on\u00a0September 22, 2025, between 04:38 UTC and 04:48 UTC to Confluence, Compass and Jira, including Jira Service Management. The incident caused service disruption to customers when they attempted to load those products in their browser or interact with APIs. Between 04:48 UTC and 06:17 UTC some customers continued to observe intermittent errors as services gradually recovered.\n\n### **ROOT CAUSE**\n\nThe issue was caused by a change to the hostname configuration of our Content Delivery Network \\(CDN\\). As a result, the products mentioned could not receive connections, and the users received TLS handshake errors, followed by HTTP 503 and 403 errors.\n\nMore specifically a new CDN configuration contained a resource name which conflicted with the existing customer-serving CDN resource, and was able to be deployed, overwriting it. The root cause of the incident was the failure in the detection of the bug by our pre-deployment validations and tests.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that you rely on our products for your daily operations and productivity, and we sincerely apologize for any impact this disruption has had on you, your team or your organisation.\n\nWe are prioritizing the following improvement actions to help avoid repeating this type of incident:\n\n* Improved pre-deployment change controls and testing.\n* Improved validation of target configurations before deployment to ensure customer-serving CDN resources cannot their hostnames changed.\n* Sharding of our CDN configuration to enable progressive changes.\n\nWe sincerely appreciate your understanding and patience as we improve our processes to provide a better customer experience.\n\nThank you,\n\nAtlassian Customer Support",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-09-22T07:17:23.797Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-09-22T05:59:59.234Z",
@@ -155,7 +155,7 @@
155
  "body": "Between 2025-08-03T21:34 and 2025-08-05T03:43 UTC some users would not have received the emails for product invitations.\nThe change that caused these emails to stop being sent has been rolled back.\nNew invitation emails should now be sent correctly for all products.\nFor users that were impacted by this issue, re-submitting their invitation will also re-send the email to them if required.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-08-05T04:19:02.903Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-08-04T23:44:47.052Z",
 
3
  "slug": "atlassian-access",
4
  "platform": "statuspage",
5
  "status_url": "https://access.status.atlassian.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-05-14T06:48:27.867Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:11:19.141Z",
 
25
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-05-08T19:45:31.250Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-08T01:31:38.240Z",
 
38
  "body": "### Summary\n\nOn April 13, 2026, between 05:49 and 06:29 UTC, customers experienced failures when attempting to log in, sign up, reset passwords, and complete multi-factor authentication flows across Atlassian cloud products. Approximately 90% of authentication requests failed during the peak impact window, affecting users in the US East and EU regions. The incident was mitigated within 40 minutes through manual intervention, and full service was restored by 06:29 UTC.\n\n### **IMPACT**\n\n* **Duration**: ~40 minutes \\(05:49\u201306:29 UTC, April 13, 2026\\)\n* **Affected regions**: US East and EU \\(authentication infrastructure serves EU traffic from US East, with traffic primarily from EU at this time of day\\).\n* **Affected products**: All Atlassian cloud products requiring authentication, including Jira, Confluence, Jira Service Management, and Trello.\n* **Customer experience**: Users attempting to log in, sign up, reset passwords, or complete MFA flows received errors. Users already logged in with active sessions were unaffected.\n\n### **ROOT CAUSE**\n\nThis incident had several contributing factors that combined to produce a failure that the system could not recover from without manual intervention.\n\n**The primary cause** was a recently enabled change that caused our authentication infrastructure to retry requests to a downstream identity service when those requests were slow to respond. This retry behaviour was rolled out to 100% of traffic earlier the same day. Under normal conditions this would be benign, but it meant that any slowness in the downstream service was amplified. Since multiple upstream services were also independently retrying their own failed requests, the amplification compounded further into a retry storm.\n\n**The trigger** was a burst of legitimate user traffic. A pattern of many parallel link preview requests for a single user caused a concentrated load spike on a downstream identity service, pushing its response times above the retry threshold. On its own, this kind of spike had occurred many times before and always recovered. With the retry amplification now in effect, the spike instead created a runaway feedback loop: slow responses caused retries, retries increased load, increased load caused slower responses, preventing recovery.\n\nThe incident was mitigated by manually scaling up the downstream identity service to provide sufficient capacity to absorb the amplified load. Once scaled, the service recovered immediately, bringing authentication error rates to zero within one minute.\n\n**REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe are taking the following actions designed to prevent recurrence and improve our resilience:\n\n1. **Immediate**: The retry-on-timeout change has been disabled.\n2. **Load shedding and self-healing**: We are adding load shedding capabilities to our authentication services so that they can automatically shed excess load and self-recover during traffic spikes, without requiring action before automatic scaling starts.\n3. **Reducing request fan-out**: We are reviewing patterns where a single user action can generate many parallel downstream requests, and will introduce methods where possible to reduce the amplification potential.\n\nWe apologize to customers whose services were interrupted by this incident and we are taking immediate steps to improve the platform\u2019s reliability.\n\nThanks,\n\nAtlassian Customer Support",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-04-13T10:17:20.783Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-04-13T07:29:46.094Z",
 
51
  "body": "### Summary\n\nOn April 8, 2026, between 04:46 UTC and 12:09 UTC, search functionality was unavailable or degraded across several Atlassian Cloud products, including Jira, Confluence, Jira Service Management, Rovo, Rovo Dev, Loom, Guard Standard, Customer Service Management and Atlassian Administration. \n\nA configuration change increased the resources reserved for a core system component that runs on nodes in our compute platform. On a subset of clusters configured for high\u2011density workloads, the increased reservations exceeded available node capacity interrupting search and related experiences for affected customers.\n\nThe root cause was identified and a rollback was merged at 05:42 UTC with some systems seeing recovery by 07:33 UTC**.** Core search functionality was restored approximately by 08:55 UTC, and full downstream recovery completed by 12:09 UTC.\n\n### **IMPACT**\n\nDuring the impact period, some customers experienced outages or degradation in search across Jira, Confluence, Jira Service Management, Rovo, Rovo Dev, Loom, Guard Standard, Customer Service Management and Atlassian Administration. Other experiences that rely on search such as quick find, navigation, AI assistants, dashboards, were also intermittently affected during this period.\n\nImpacted customers may have been unable to find pages or recordings and experienced degraded performance in finding issues; received empty or delayed search results; or experienced AI assistants and dashboards that could not retrieve relevant context.\n\n**Jira, Jira Service Management and Customer Service Management:** Search and experiences that depend on search like finding issues and agent responses in CSM remained available but with degraded performance in fallback mode. By 12:09 UTC, search indexes and search performance was fully restored from fallback to full capacity across all regions.\n\n**Guard Standard and Atlassian Administration:** Search functionality was unavailable for parts of the incident window. As a result, Domain Claims, usage tracking, and managed accounts were degraded for portions of the window. These services were restored to operational status by 07:33 UTC. Guard Premium was not impacted by this issue.\n\n**Confluence:** Search functionality was unavailable for parts of the incident window. Recovery began at 07:30 UTC as backend search clusters were restored. Full recovery, including search index replay, completed at 11:37 UTC.\n\n**Loom:** Search functionality and some experiences that rely on Confluence Search, such as sharing to spaces\\) was unavailable for portions of the window and fully restored at 11:37 UTC.\n\n**Rovo and Rovo Dev:** Rovo agents remained responsive but experienced degraded functionality due to loss of search capabilities in underlying services. They were unable to reliably return context about work items or pages. Functionality was fully restored at 11:37 UTC.\n\n### **ROOT CAUSE**\n\nAtlassian products rely on OpenSearch clusters to power their search capabilities including issue search, content search, and AI-powered search features. \n\nAn infrastructure configuration change increased resource reservations \\(CPU & Memory\\) for a system component that runs across our compute platform. On a subset of clusters configured for high-density workloads, the increased reservations exceeded available node capacity. This caused search workloads to be evicted and, in some clusters, could not reschedule onto any available nodes impacting search functionality across affected products.\n\nThe change was deployed across multiple production clusters in a short time frame, limiting the opportunity to detect the capacity conflict in a smaller subset of clusters before it reached the wider fleet. Automated scaling systems attempted to recover by provisioning additional capacity but in the worst\u2011affected clusters this led to runaway node scaling and exhaustion of available network resources, prolonging recovery time.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe understand that service disruptions impact your productivity. In addition to our existing testing and preventative processes, Atlassian is prioritizing the following actions to help reduce the likelihood and impact of similar incidents in the future and to speed up recovery when issues occur:\n\n* **Enforce smaller deployment cohorts and larger soak for critical platform changes for these cluster types** \n Implement smaller deployment cohorts, mandatory soak periods between environments, and automated health gates so that changes are validated on a limited set of clusters before being promoted more broadly.\n* **Strengthen automated pre\u2011deploy validation for resource changes** \n Add validation checks to ensure resource changes for system components are compatible with node capacity and reserved headroom, preventing system workloads from crowding out customer workloads.\n* **Improve post\u2011deploy verification and alerting** \n Enhance monitoring and post\u2011deployment verification to detect patterns such as spikes in pending pods, runaway node scaling, and low pod\u2011IP headroom closely correlated with new configuration being rolled out.\n* **Align autoscaling behavior with capacity and safety limits** \n Align autoscaling capacity calculations with node reservations and introduce safeguards and circuit breakers to prevent runaway scaling and to enforce safe limits on node and pod IP counts.\n* **Enhance recovery automation** \n Improve automation and runbooks so we can safely disable autoscaling, remove empty nodes in bulk, and restore normal operations faster across multiple clusters in parallel.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability and to reduce the risk and impact of similar issues in future.\n\nThanks,\n\nAtlassian Customer Support",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "critical",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-04-08T11:43:29.733Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-08T06:01:35.680Z",
 
64
  "body": "We have implemented the fix and the group page in the Admin Hub is now functioning as expected.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-02-18T11:30:29.120Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-02-18T11:28:09.872Z",
 
77
  "body": "### Summary\n\nOn **December 27, 2025**, between **02:48 UTC and 05:20 UTC**, some Atlassian cloud customers experienced failures in sending and receiving emails and mobile notifications. Core Jira and Confluence functionality remained available.\n\nThe issue was triggered when **TLS certificates used by Atlassian\u2019s monitoring infrastructure expired**, causing parts of our metrics pipeline to stop accepting traffic. Services responsible for email and mobile notifications had a critical path dependency on monitoring path leading to service disruptions.\n\nAll impacted services were fully restored by **05:20 UTC**, around **2.5 hours** after customer impact began.\n\n### IMPACT\n\nDuring the impact window, customers experienced:\n\n* **Outbound product email failures** \\(notifications and other product emails did not send\\).\n* **Identity and account flow failures** where emails were required \\(e.g. sign\u2011ups, password resets, one\u2011time\u2011password / step\u2011up challenges\\).\n* **Jira and Confluence mobile push notifications**\n* **Customer site activations and some admin policy changes** failing and requiring later reprocessing.\n\n### ROOT CAUSE\n\nThe incident was caused by:\n\n1. **Expired TLS certificates** on domains used by our monitoring and metrics infrastructure caused by **misconfigured DNS authorization record** which prevented automatic renewal.\n2. **Tight coupling of services to metrics publishing**, which caused them to fail when monitoring endpoints became unavailable, instead of degrading gracefully.\n\n### REMEDIAL ACTIONS PLAN & NEXT STEPS\n\nWe recognize that outages like this have a direct impact on customers\u2019 ability to receive important notifications, complete account tasks, and operate their sites.\n\nWe are prioritizing the following actions to improve our existing testing, monitoring and certificate management processes:\n\n* **Hardening monitoring and certificate infrastructure**\n\n * We are refining DNS and certificate configuration across our monitoring domains and strengthening proactive checks to detect and address failed renewals and certificate issues well before expiry.\n * We are also improving alerting on our monitoring and metrics pipeline.\n \n* **Decoupling monitoring from critical customer flows** \n We are updating services such as outbound email, identity, mobile push, provisioning, and admin policy changes so they no longer depend on metrics publishing to operate. If monitoring becomes unavailable, these services will continue to run and degrade gracefully by dropping or buffering metrics instead of failing customer operations.\n\nWe apologize to customers impacted during this incident. We are implementing the improvements above to help ensure that similar issues are avoided.\n\nThanks, \nAtlassian Customer Support",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "critical",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-12-27T05:20:20.550Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-12-27T04:42:32.884Z",
 
90
  "body": "On December 15th, 2025, affected Guard users in US Prod East region may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.\n\nNote: All previously failed Guard provisioning and open workflows have been replayed by Atlassian. No actions are needed from customers for these events.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "critical",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-12-15T22:07:53.438Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-15T20:23:41.417Z",
 
103
  "body": "On December 15th, 2025, Admin Hub, Atlassian Analytics, Confluence Cloud, Ecosystem, Focus, Jira, Jira Product Discovery, Jira Service Management, and Rovo users in the prod-us-east region may have experienced performance degradations and errors on the web page and mobile apps. The issue has now been resolved, and the service is operating normally for all affected customers.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2025-12-15T19:02:03.786Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-12-15T16:16:25.657Z",
 
116
  "body": "Impacted customers have now confirmed that they are receiving their emails as expected.\n\nIf you do continue to see these emails being missing or delayed, please check in with your organizations email admin to review and release them.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2025-11-17T00:11:36.845Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-11-13T18:56:12.844Z",
 
129
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "major",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-10-21T05:24:26.990Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-10-20T07:56:12.795Z",
 
142
  "body": "### **SUMMARY**\n\nOn September 22, 2025, between 04:38 and 04:48 UTC, Atlassian customers experienced connection errors preventing access to their [atlassian.net](http://atlassian.net/) sites. Some customers observed intermittent errors as services gradually recovered until 06:17 UTC.\n\nThe event was triggered by a faulty configuration change to our Content Delivery Network \\(CDN\\). The change included an invalid hostname which prevented customers from successfully connecting to [atlassian.net](http://atlassian.net/) domains.\n\nThe incident was detected within 1 minute by our monitoring systems and mitigated by rolling back the change, which put Atlassian systems into a known good state. The acute impact was resolved in 10 minutes and all lingering errors resolved in 1 hour 38 minutes.\n\n### **IMPACT**\n\nThe acute impact occurred on\u00a0September 22, 2025, between 04:38 UTC and 04:48 UTC to Confluence, Compass and Jira, including Jira Service Management. The incident caused service disruption to customers when they attempted to load those products in their browser or interact with APIs. Between 04:48 UTC and 06:17 UTC some customers continued to observe intermittent errors as services gradually recovered.\n\n### **ROOT CAUSE**\n\nThe issue was caused by a change to the hostname configuration of our Content Delivery Network \\(CDN\\). As a result, the products mentioned could not receive connections, and the users received TLS handshake errors, followed by HTTP 503 and 403 errors.\n\nMore specifically a new CDN configuration contained a resource name which conflicted with the existing customer-serving CDN resource, and was able to be deployed, overwriting it. The root cause of the incident was the failure in the detection of the bug by our pre-deployment validations and tests.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that you rely on our products for your daily operations and productivity, and we sincerely apologize for any impact this disruption has had on you, your team or your organisation.\n\nWe are prioritizing the following improvement actions to help avoid repeating this type of incident:\n\n* Improved pre-deployment change controls and testing.\n* Improved validation of target configurations before deployment to ensure customer-serving CDN resources cannot their hostnames changed.\n* Sharding of our CDN configuration to enable progressive changes.\n\nWe sincerely appreciate your understanding and patience as we improve our processes to provide a better customer experience.\n\nThank you,\n\nAtlassian Customer Support",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-09-22T07:17:23.797Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-09-22T05:59:59.234Z",
 
155
  "body": "Between 2025-08-03T21:34 and 2025-08-05T03:43 UTC some users would not have received the emails for product invitations.\nThe change that caused these emails to stop being sent has been rolled back.\nNew invitation emails should now be sent correctly for all products.\nFor users that were impacted by this issue, re-submitting their invitation will also re-send the email to them if required.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-08-05T04:19:02.903Z",
160
  "resolved_inferred": false,
161
  "started_at": "2025-08-04T23:44:47.052Z",
api/v/atlassian-compass.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atlassian-compass",
4
  "platform": "statuspage",
5
  "status_url": "https://compass.status.atlassian.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-05-14T06:48:27.600Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:24:54.073Z",
@@ -25,7 +25,7 @@
25
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-05-08T19:45:32.332Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-08T01:31:38.318Z",
@@ -38,7 +38,7 @@
38
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2025-10-21T05:24:27.565Z",
43
  "resolved_inferred": false,
44
  "started_at": "2025-10-20T07:56:12.959Z",
@@ -51,7 +51,7 @@
51
  "body": "Between 13:10 UTC to 14:00 UTC, we experienced notification delay for Jira Service Management, Opsgenie, and Compass in only EU-region. The issue has been resolved and the service is operating normally.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2025-09-30T14:32:25.335Z",
56
  "resolved_inferred": false,
57
  "started_at": "2025-09-30T14:07:08.233Z",
@@ -64,7 +64,7 @@
64
  "body": "### **SUMMARY**\n\nOn September 22, 2025, between 04:38 and 04:48 UTC, Atlassian customers experienced connection errors preventing access to their [atlassian.net](http://atlassian.net/) sites. Some customers observed intermittent errors as services gradually recovered until 06:17 UTC.\n\nThe event was triggered by a faulty configuration change to our Content Delivery Network \\(CDN\\). The change included an invalid hostname which prevented customers from successfully connecting to [atlassian.net](http://atlassian.net/) domains.\n\nThe incident was detected within 1 minute by our monitoring systems and mitigated by rolling back the change, which put Atlassian systems into a known good state. The acute impact was resolved in 10 minutes and all lingering errors resolved in 1 hour 38 minutes.\n\n### **IMPACT**\n\nThe acute impact occurred on\u00a0September 22, 2025, between 04:38 UTC and 04:48 UTC to Confluence, Compass and Jira, including Jira Service Management. The incident caused service disruption to customers when they attempted to load those products in their browser or interact with APIs. Between 04:48 UTC and 06:17 UTC some customers continued to observe intermittent errors as services gradually recovered.\n\n### **ROOT CAUSE**\n\nThe issue was caused by a change to the hostname configuration of our Content Delivery Network \\(CDN\\). As a result, the products mentioned could not receive connections, and the users received TLS handshake errors, followed by HTTP 503 and 403 errors.\n\nMore specifically a new CDN configuration contained a resource name which conflicted with the existing customer-serving CDN resource, and was able to be deployed, overwriting it. The root cause of the incident was the failure in the detection of the bug by our pre-deployment validations and tests.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that you rely on our products for your daily operations and productivity, and we sincerely apologize for any impact this disruption has had on you, your team or your organisation.\n\nWe are prioritizing the following improvement actions to help avoid repeating this type of incident:\n\n* Improved pre-deployment change controls and testing.\n* Improved validation of target configurations before deployment to ensure customer-serving CDN resources cannot their hostnames changed.\n* Sharding of our CDN configuration to enable progressive changes.\n\nWe sincerely appreciate your understanding and patience as we improve our processes to provide a better customer experience.\n\nThank you,\n\nAtlassian Customer Support",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2025-09-22T07:17:23.768Z",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-22T05:59:59.177Z",
@@ -77,7 +77,7 @@
77
  "body": "Between September 10, 2025, 3:19 PM UTC and September 11, 2025, 2:44 PM UTC, there was degraded performance in web experiences and the REST APIs for some Jira Service Management, Opsgenie, and Compass Cloud customers in the US region. We have deployed a fix to mitigate the issue and have verified that the services have recovered. The issue has been resolved and the service is operating normally.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-09-11T18:45:19.750Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-11T08:53:32.822Z",
 
3
  "slug": "atlassian-compass",
4
  "platform": "statuspage",
5
  "status_url": "https://compass.status.atlassian.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-05-14T06:48:27.600Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:24:54.073Z",
 
25
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-05-08T19:45:32.332Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-08T01:31:38.318Z",
 
38
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2025-10-21T05:24:27.565Z",
43
  "resolved_inferred": false,
44
  "started_at": "2025-10-20T07:56:12.959Z",
 
51
  "body": "Between 13:10 UTC to 14:00 UTC, we experienced notification delay for Jira Service Management, Opsgenie, and Compass in only EU-region. The issue has been resolved and the service is operating normally.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2025-09-30T14:32:25.335Z",
56
  "resolved_inferred": false,
57
  "started_at": "2025-09-30T14:07:08.233Z",
 
64
  "body": "### **SUMMARY**\n\nOn September 22, 2025, between 04:38 and 04:48 UTC, Atlassian customers experienced connection errors preventing access to their [atlassian.net](http://atlassian.net/) sites. Some customers observed intermittent errors as services gradually recovered until 06:17 UTC.\n\nThe event was triggered by a faulty configuration change to our Content Delivery Network \\(CDN\\). The change included an invalid hostname which prevented customers from successfully connecting to [atlassian.net](http://atlassian.net/) domains.\n\nThe incident was detected within 1 minute by our monitoring systems and mitigated by rolling back the change, which put Atlassian systems into a known good state. The acute impact was resolved in 10 minutes and all lingering errors resolved in 1 hour 38 minutes.\n\n### **IMPACT**\n\nThe acute impact occurred on\u00a0September 22, 2025, between 04:38 UTC and 04:48 UTC to Confluence, Compass and Jira, including Jira Service Management. The incident caused service disruption to customers when they attempted to load those products in their browser or interact with APIs. Between 04:48 UTC and 06:17 UTC some customers continued to observe intermittent errors as services gradually recovered.\n\n### **ROOT CAUSE**\n\nThe issue was caused by a change to the hostname configuration of our Content Delivery Network \\(CDN\\). As a result, the products mentioned could not receive connections, and the users received TLS handshake errors, followed by HTTP 503 and 403 errors.\n\nMore specifically a new CDN configuration contained a resource name which conflicted with the existing customer-serving CDN resource, and was able to be deployed, overwriting it. The root cause of the incident was the failure in the detection of the bug by our pre-deployment validations and tests.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that you rely on our products for your daily operations and productivity, and we sincerely apologize for any impact this disruption has had on you, your team or your organisation.\n\nWe are prioritizing the following improvement actions to help avoid repeating this type of incident:\n\n* Improved pre-deployment change controls and testing.\n* Improved validation of target configurations before deployment to ensure customer-serving CDN resources cannot their hostnames changed.\n* Sharding of our CDN configuration to enable progressive changes.\n\nWe sincerely appreciate your understanding and patience as we improve our processes to provide a better customer experience.\n\nThank you,\n\nAtlassian Customer Support",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2025-09-22T07:17:23.768Z",
69
  "resolved_inferred": false,
70
  "started_at": "2025-09-22T05:59:59.177Z",
 
77
  "body": "Between September 10, 2025, 3:19 PM UTC and September 11, 2025, 2:44 PM UTC, there was degraded performance in web experiences and the REST APIs for some Jira Service Management, Opsgenie, and Compass Cloud customers in the US region. We have deployed a fix to mitigate the issue and have verified that the services have recovered. The issue has been resolved and the service is operating normally.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-09-11T18:45:19.750Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-09-11T08:53:32.822Z",
api/v/atlassian-developer.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atlassian-developer",
4
  "platform": "statuspage",
5
  "status_url": "https://developer.status.atlassian.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "We have identified the cause of the issue impacting installation requests and deployed a fix. The issue is now resolved, and the service is operating normally for all affected customers.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-02T03:17:39.246Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-02T03:09:23.978Z",
@@ -25,7 +25,7 @@
25
  "body": "On Aug 25th, 2026, between 08:12 UTC and 11:03 UTC, some Marketplace apps may have experienced scheduled triggers (5-minute intervals) not firing as expected.\n\nThe issue has now been resolved and the 5-minute scheduled triggers are operating normally for all customers.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-25T11:11:04.824Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-25T10:58:56.965Z",
@@ -38,7 +38,7 @@
38
  "body": "We have confirmed that the issues relating to installing, uninstalling and managing Forge and OAuth 2.0 apps should now be fully resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-03T03:37:51.207Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-03T03:26:36.528Z",
@@ -51,7 +51,7 @@
51
  "body": "On Jul 13, 2026, partner operations may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-07-13T17:46:03.265Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-13T15:48:27.246Z",
@@ -64,7 +64,7 @@
64
  "body": "All customers that had previously received the incorrect notifications about the Time Tracker for Jira Cloud and DC app should have received corrective communications at this time.\n\nWe are now resolving this issue.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-07-02T04:43:17.909Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-06-30T02:45:58.000Z",
@@ -77,7 +77,7 @@
77
  "body": "On June 26, 2026, some customers may have experienced performance degradation with remote Forge apps facing rate-limiting issues. The issue has now been resolved, and the service is operating normally for all affected customers.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-06-26T21:39:37.248Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-26T14:32:39.810Z",
@@ -90,7 +90,7 @@
90
  "body": "We are now confident that any of the tasks that were impacted by this incident and were delayed should now be operating as expected.\n\nWe apologize for any inconvenience that this issue may have caused.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2026-06-10T06:31:05.820Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-10T04:55:13.006Z",
@@ -103,7 +103,7 @@
103
  "body": "Between 08:30 UTC and 13:51 UTC on 26 May 2026, some users were unable to load or edit certain macros in the Confluence Cloud page editor. Our engineering team identified and resolved the underlying issue, and macro functionality has been fully restored.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2026-05-26T13:55:52.263Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-05-26T10:40:00.326Z",
@@ -116,7 +116,7 @@
116
  "body": "The root cause has been identified and a fix has been applied.\n\nFull service restoration has been completed.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2026-05-20T14:14:35.345Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-05-20T12:06:23.836Z",
@@ -129,7 +129,7 @@
129
  "body": "Due to an incorrect deployment, a banner stating 'This app may stop working soon' was briefly displayed on the Marketplace Apps. This banner was not intended to appear on these apps.\n\nThe feature has since been corrected and the banner is no longer appearing. No action is required, the banner was displayed in error and there is no impact to app functionality or availability.\n\nWe apologise for any confusion this may have caused.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2026-05-20T10:16:52.997Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-20T10:16:52.944Z",
@@ -142,7 +142,7 @@
142
  "body": "On May 14, 2026, Developer and Marketplace service desks were inaccessible for affected users. The issue has now been resolved, and the service is operating normally for all affected customers.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "critical",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2026-05-14T21:35:12.921Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-14T21:04:04.214Z",
@@ -155,7 +155,7 @@
155
  "body": "All products and services impacted by this incident should now be fully recovered, and this incident is resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2026-05-14T06:49:28.904Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-14T05:11:20.261Z",
@@ -168,7 +168,7 @@
168
  "body": "On May 12, 2026, some users in US East region may have experienced intermittent failures with forge invocations for some applications. The issue has now been resolved, and the service is operating normally for all affected customers.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2026-05-12T17:40:43.123Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-12T15:50:29.317Z",
@@ -181,7 +181,7 @@
181
  "body": "On May 12, 2026, some users in EU West region may have experienced delayed or queued webhook events. The issue has now been resolved, and the service is operating normally for all affected customers.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2026-05-12T18:11:26.274Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-12T14:03:20.536Z",
@@ -194,7 +194,7 @@
194
  "body": "On May 11, 2026, users in EU West and US East regions may have experienced performance degradation with delayed or queued webhook events. The issue has now been resolved, and the service is operating normally for all affected customers.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2026-05-11T18:16:05.697Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-05-11T14:24:14.135Z",
@@ -207,7 +207,7 @@
207
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2026-05-08T19:45:31.603Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-05-08T04:10:28.630Z",
@@ -220,7 +220,7 @@
220
  "body": "On Tuesday, May 5, 2026, some Forge users may have experienced performance delays in webhook delivery in the US East region. The issue has now been resolved, and the service is operating normally for all affected customers.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2026-05-05T22:34:14.686Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-05-05T17:40:11.867Z",
@@ -233,7 +233,7 @@
233
  "body": "The issue causing intermittent delays in our webhook delivery has been resolved. A fix was deployed to address a resource constraint in our systems. Our monitoring shows webhook delivery is now operating normally.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2026-04-30T14:56:57.972Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-04-30T08:59:04.029Z",
@@ -246,7 +246,7 @@
246
  "body": "The issue has now been resolved, and the service is operating normally for all affected customers.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2026-04-28T21:50:42.758Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-04-28T18:28:20.767Z",
@@ -259,7 +259,7 @@
259
  "body": "The issue has now been resolved, and the service is operating normally for all affected customers.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "major",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2026-04-23T16:14:43.771Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-04-22T06:57:00.565Z",
@@ -272,7 +272,7 @@
272
  "body": "The issue has now been resolved, and the service is operating normally for all affected customers.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2026-04-13T15:11:45.243Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-04-13T10:58:02.547Z",
@@ -285,7 +285,7 @@
285
  "body": "The outage affecting Forge app logs between 05:00 UTC and 07:00 UTC on 8 April 2026 has been resolved, and systems are now stable.\n\nWe are currently working on recovery efforts, including retrieving logs from this downtime window and validating data completeness. During this process, you may temporarily see duplicate log entries; however, this will not result in duplicate usage or additional costs.\n\nWe will continue to monitor the system closely and provide further updates as needed.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "critical",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2026-04-08T07:45:13.000Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-04-08T06:55:07.248Z",
@@ -298,7 +298,7 @@
298
  "body": "On April 2, 2026, affected users may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "major",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2026-04-02T22:36:41.280Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-04-02T20:46:43.730Z",
@@ -311,7 +311,7 @@
311
  "body": "On March 24, 2026, between 04:14 AM UTC and 08:40 AM UTC, Connect Apps using connect API's experienced performance degradation. The issue has now been resolved, and the service is operating normally for all affected customers.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
- "last_seen": "2026-09-04T09:06:33Z",
315
  "resolved_at": "2026-03-24T08:44:23.346Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-03-24T07:59:20.308Z",
@@ -324,7 +324,7 @@
324
  "body": "On March 17th, 2026, between 9:05 AM UTC and 11:10 AM UTC, Forge app management and related developer tooling experienced some service disruption. The issue has now been resolved, and the service is operating normally for affected customers.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
- "last_seen": "2026-09-04T09:06:33Z",
328
  "resolved_at": "2026-03-17T11:37:37.061Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-03-17T10:05:28.000Z",
@@ -337,7 +337,7 @@
337
  "body": "On March 12, 2026, affected Confluence Cloud users may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "major",
340
- "last_seen": "2026-09-04T09:06:33Z",
341
  "resolved_at": "2026-03-13T00:26:04.153Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-03-12T11:42:38.845Z",
@@ -350,7 +350,7 @@
350
  "body": "We are providing a further update regarding the install count discrepancy that some partners may have observed for some apps since Feb 27, 2026.\n\n- The Active Installations tab in the Marketplace Partner Portal is now showing accurate install counts for impacted apps from Mar 3, 2026 onward.\n- The install counts displayed on app listings remain accurate for impacted apps.\n- Please note that data from Mar 3, 2026 onward will remain accurate going forward.\n- You may notice a temporary dip in install counts for Mar 2, 2026. We are backfilling the data, and counts for that date will be restored once complete.\n- Actual customer installs were not impacted; only the reported counts displayed in the Partner Portal and on app listings were affected for some apps, and this is now fully functional.\n\nThank you for your patience and understanding.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
- "last_seen": "2026-09-04T09:06:33Z",
354
  "resolved_at": "2026-03-04T03:04:15.737Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-03-02T16:15:12.562Z",
@@ -363,7 +363,7 @@
363
  "body": "We have now reactivated all subscriptions that were previously cancelled. Impacted users may have received email notifications confirming this change. There has been no impact to the functioning of the app, it should continue to work as expected.\nTo help prevent any future interruptions, we kindly request that billing admins ensure a valid billing payment method is added before the next billing cycle.\nWe apologise for any confusion and appreciate your understanding.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
- "last_seen": "2026-09-04T09:06:33Z",
367
  "resolved_at": "2026-02-19T17:12:31.473Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-02-16T11:24:02.892Z",
@@ -376,7 +376,7 @@
376
  "body": "This issue is resolved. In our monitoring no other unexpected issues were seen.\n\nFor customers still experiencing errors, this may indicate a legitimate permission configuration issue on your side and should be investigated as usual.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
- "last_seen": "2026-09-04T09:06:33Z",
380
  "resolved_at": "2026-02-19T08:04:57.460Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-02-13T07:41:39.717Z",
@@ -389,7 +389,7 @@
389
  "body": "Impact\n\nWe are currently experiencing an issue affecting the Forge platform, specifically related to scheduled triggers. Users may encounter instances where these triggers are not executing as anticipated, disrupting the normal operation of their Forge apps. This behavior began approximately at 2 AM UTC.\n\nCurrent Status\n\nOur engineering team identified the root cause and performed a rollback deployment to resolve the issue.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
- "last_seen": "2026-09-04T09:06:33Z",
393
  "resolved_at": "2026-02-06T11:32:35.358Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-02-06T09:37:35.831Z",
@@ -402,7 +402,7 @@
402
  "body": "Team has identified the root cause and the issue has now been resolved, and the impacted services are operating normally. Team will continue to monitor the impacted services.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
- "last_seen": "2026-09-04T09:06:33Z",
406
  "resolved_at": "2026-02-03T10:50:35.750Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-02-03T10:19:54.355Z",
@@ -415,7 +415,7 @@
415
  "body": "On January 28, 2026, some customers may have experienced Forge function invocation availability disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "major",
418
- "last_seen": "2026-09-04T09:06:33Z",
419
  "resolved_at": "2026-01-28T19:20:20.274Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-01-28T17:34:56.308Z",
@@ -428,7 +428,7 @@
428
  "body": "The issue is completely resolved and Developer Console is now displaying all the usage metrics correctly. We apologize for any inconvenience this may have caused.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
- "last_seen": "2026-09-04T09:06:33Z",
432
  "resolved_at": "2025-12-17T06:07:27.782Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-12-16T05:47:29.672Z",
@@ -441,7 +441,7 @@
441
  "body": "The rollback required to resolve this issue is now completed, and we have verified across the impacted products that App installation behaviour is now working as expected. We apologize for any inconvenience this may have caused.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "critical",
444
- "last_seen": "2026-09-04T09:06:33Z",
445
  "resolved_at": "2025-12-11T04:37:14.124Z",
446
  "resolved_inferred": false,
447
  "started_at": "2025-12-11T01:08:44.953Z",
@@ -454,7 +454,7 @@
454
  "body": "Between Dec 8 05:30 UTC and Dec 9 05:30 UTC, new Forge app versions were not auto-published to Atlassian Marketplace. We\u2019ve implemented a mitigation and auto-publish is operating normally.\n\nAction required: If you deployed during this window, please manually publish those versions in Marketplace (or re-deploy your app with forge deploy). \n\nWe\u2019re sorry for the inconvenience.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "none",
457
- "last_seen": "2026-09-04T09:06:33Z",
458
  "resolved_at": "2025-12-09T08:14:04.000Z",
459
  "resolved_inferred": false,
460
  "started_at": "2025-12-09T08:14:04.000Z",
@@ -467,7 +467,7 @@
467
  "body": "The feature flag causing the issue has been reverted, fixing the problem. With that this incident is resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
- "last_seen": "2026-09-04T09:06:33Z",
471
  "resolved_at": "2025-12-05T12:09:05.554Z",
472
  "resolved_inferred": false,
473
  "started_at": "2025-12-05T08:08:53.836Z",
@@ -480,7 +480,7 @@
480
  "body": "Impact\n\nCustomers experienced degraded performance in log ingestion services affecting the Ecosystem, particularly the Forge platform. Due to this issue, accessing logs ingested from the morning of the incident (starting 06:00 UTC) was impacted, leading to delays or incomplete data visibility through the Dev Console and related channels.\n\nCurrent Status\n\nThis incident has been resolved, and Forge Logs are back in operational mode.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
- "last_seen": "2026-09-04T09:06:33Z",
484
  "resolved_at": "2025-11-10T14:03:18.231Z",
485
  "resolved_inferred": false,
486
  "started_at": "2025-11-10T10:41:39.876Z",
@@ -493,7 +493,7 @@
493
  "body": "Validation is complete. All tables backing Aggregated Sales Reporting, Transaction Reporting, and Export Transaction APIs have been fully repopulated. Data for the impacted window (25 Oct 2025 00:00 IST \u2013 27 Oct 2025 14:00 IST) has been restored and verified. No action is required from vendors. We are closing this incident.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "minor",
496
- "last_seen": "2026-09-04T09:06:33Z",
497
  "resolved_at": "2025-10-28T13:42:21.577Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-10-27T12:04:05.344Z",
@@ -506,7 +506,7 @@
506
  "body": "### Summary\n\nOn October 22, 2025, Confluence Cloud webhook events were not delivered to Connect apps and Forge apps that use webhooks via `connectModules`. This outage began after a backend deployment introduced a code change that prevented Confluence from recognizing registered webhook listeners. As a result, no webhook events were generated for approximately 20 hours, impacting apps that depend on webhooks. The issue was resolved by rolling back to a previous stable deployment. We\u2019re taking steps to improve detection and rollback processes.\n\n### **IMPACT**\n\nBetween 01:12 UTC and 21:46 UTC on October 22, 2025, Confluence was unable to send out webhook events. As a result, none of the apps that rely on these events received them during this time. This includes Connect apps and Forge apps that use webhooks through `connectModules`.\n\nCustomers may have noticed outdated content appearing in their Marketplace apps, or new content not syncing.\n\n### **ROOT CAUSE**\n\nThe issue was caused by a change to Confluence backend systems. As a result, no webhook events were delivered to Connect and Forge apps that use webhooks via `connectModules`. This occurred because a Java class was loaded by 2 different classloaders, causing Confluence to fail to find registered webhook listeners and thus not emit events.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWebhooks are a critical functionality for many apps. On this occasion, our system did not generate any errors because it was inadvertently using an incorrect version of a Java class, which was loaded by a different ClassLoader. As a result, the issue occurred silently and couldn\u2019t be detected via existing automated error monitoring.\n\n\u00a0\n\nWe are prioritizing the following improvement actions to help prevent this issue from reoccurring:\n\n* Additional integration tests to identify problems before merging code to our main branch.\n* Additional detectors and alerts to identify when webhook event volume drops below a certain threshold.\n* Exploring resync / lost event recovery mechanism without overloading Atlassian infrastructure\n\n * We acknowledge that the availability of Connect apps is important for our customers and ecosystem partners, and we will endeavour to provide support for these apps in line with our public roadmap for Connect end of life. You can read our announcement here: [Announcing Connect End of Support: Timeline and Next Steps - Work Life by Atlassian](https://www.atlassian.com/blog/developer/announcing-connect-end-of-support-timeline-and-next-steps)\n \n While this incident primarily impacted Connect, we would like to note that Forge currently includes additional internal capabilities, such as retry [Atlassian app events](https://developer.atlassian.com/platform/forge/events-reference/product_events/#retry-atlassian-app-events) and internal DLQ, that could assist with recovery in these types of incidents..\n\n \n \n We highly encourage partners to migrate to Forge to utilize the latest webhook infrastructure.\n\n \n \n\nWe apologize to customers and ecosystem partners whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "critical",
509
- "last_seen": "2026-09-04T09:06:33Z",
510
  "resolved_at": "2025-10-22T22:09:20.000Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-10-22T12:15:57.948Z",
@@ -519,7 +519,7 @@
519
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "none",
522
- "last_seen": "2026-09-04T09:06:33Z",
523
  "resolved_at": "2025-10-21T05:24:25.603Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-10-20T07:56:11.430Z",
@@ -532,7 +532,7 @@
532
  "body": "Between 06:58 12 Oct UTC to 18:30 12 Oct UTC, we experienced calls from a some forge apps to external services (outside of Atlassian) intermittently fail. The issue has been resolved and the service is operating normally.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
- "last_seen": "2026-09-04T09:06:33Z",
536
  "resolved_at": "2025-10-12T19:25:16.839Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-10-12T15:25:53.472Z",
@@ -545,7 +545,7 @@
545
  "body": "Between 06:30 12th Oct, 2025 UTC to 08:33 12th Oct, 2025 UTC, we experienced a degradation in us-east and ca-central regions affecting authenticated egress calls from Forge functions and from Forge bridge. \n\nThe issue has been resolved and the service is operating normally.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "none",
548
- "last_seen": "2026-09-04T09:06:33Z",
549
  "resolved_at": "2025-10-12T09:14:40.272Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-10-12T07:29:47.822Z",
@@ -558,7 +558,7 @@
558
  "body": "Between 29 Sep 2025 07:10 UTC and 03 Oct 2025 06:00 UTC, some customers experienced unexpected Allow access OAuth consent prompts when using the Forge app UI. The issue has been resolved, and the service is operating normally.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
- "last_seen": "2026-09-04T09:06:33Z",
562
  "resolved_at": "2025-10-03T06:24:19.291Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-10-03T03:43:27.000Z",
@@ -571,7 +571,7 @@
571
  "body": "Between 08:30 AM UTC to 16:30 UTC on September 29, 2025, some developers experienced delays of log delivery for the Dev Console. The root cause was an unexpected spike in volume that required updates to autoscaling configurations to address. We have deployed a fix to mitigate the issue and have verified that the services have recovered. The conditions that cause the bug have been addressed and we\u2019re actively working on a permanent fix. The issue has been resolved and the service is processing logs normally. We are currently processing the delayed logs and anticipate completion by 17:00 UTC today, September 29, 2025.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "minor",
574
- "last_seen": "2026-09-04T09:06:33Z",
575
  "resolved_at": "2025-09-29T17:07:09.374Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-09-29T15:32:40.124Z",
@@ -584,7 +584,7 @@
584
  "body": "Issues affecting Marketplace Reporting APIs and Partner Portal have been resolved. Both services are now back up and running normally. This incident has been resolved.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "critical",
587
- "last_seen": "2026-09-04T09:06:33Z",
588
  "resolved_at": "2025-09-26T10:45:55.450Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-09-26T10:09:49.455Z",
@@ -597,7 +597,7 @@
597
  "body": "We experienced a disruption affecting all JSM assets APIs using Connect JWT and user impersonation for connect apps, starting on September 13th at 2:05 AM UTC and lasting until September 17th at 3:36 PM UTC. This issue was caused by an internal routing change within Atlassian systems. During this time, all Assets API calls using Connect authentications were disrupted. The issue has now been resolved, and all affected APIs are fully operational again. We sincerely apologise for any inconvenience caused and thank you for your patience and understanding.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "none",
600
- "last_seen": "2026-09-04T09:06:33Z",
601
  "resolved_at": "2025-09-25T08:14:11.708Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-09-25T08:14:11.610Z",
@@ -610,7 +610,7 @@
610
  "body": "No customer impact has been observed seen since mitigation began. We are now closing this incident.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "major",
613
- "last_seen": "2026-09-04T09:06:33Z",
614
  "resolved_at": "2025-09-19T02:02:51.884Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-09-15T02:06:05.594Z",
@@ -623,7 +623,7 @@
623
  "body": "Changes have landed in production at 11:40 AM (UTC). The issue is resolved and the endpoint is now operating normally.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
- "last_seen": "2026-09-04T09:06:33Z",
627
  "resolved_at": "2025-09-12T11:56:02.700Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-09-12T08:14:51.720Z",
@@ -636,7 +636,7 @@
636
  "body": "Between 12:50 UTC to 13:20 UTC, we experienced partial failures for deploying forge apps via forge cli for Atlassian Developers. \nThe issue has been resolved and the service is operating normally.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "major",
639
- "last_seen": "2026-09-04T09:06:33Z",
640
  "resolved_at": "2025-09-08T13:46:29.610Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-09-08T13:35:23.947Z",
@@ -649,7 +649,7 @@
649
  "body": "This incident is resolved now. Between 6:30 AM and 8:35 AM UTC on September 8th, there was an issue with one of the dependent vendor services, due to which invocations were intermittently failing, primarily in the EU-CENTRAL-1 Region. This issue is fixed now.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "major",
652
- "last_seen": "2026-09-04T09:06:33Z",
653
  "resolved_at": "2025-09-08T10:05:53.000Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-09-08T07:44:14.089Z",
 
3
  "slug": "atlassian-developer",
4
  "platform": "statuspage",
5
  "status_url": "https://developer.status.atlassian.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "We have identified the cause of the issue impacting installation requests and deployed a fix. The issue is now resolved, and the service is operating normally for all affected customers.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "minor",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-02T03:17:39.246Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-02T03:09:23.978Z",
 
25
  "body": "On Aug 25th, 2026, between 08:12 UTC and 11:03 UTC, some Marketplace apps may have experienced scheduled triggers (5-minute intervals) not firing as expected.\n\nThe issue has now been resolved and the 5-minute scheduled triggers are operating normally for all customers.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-25T11:11:04.824Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-25T10:58:56.965Z",
 
38
  "body": "We have confirmed that the issues relating to installing, uninstalling and managing Forge and OAuth 2.0 apps should now be fully resolved.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-03T03:37:51.207Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-03T03:26:36.528Z",
 
51
  "body": "On Jul 13, 2026, partner operations may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-07-13T17:46:03.265Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-07-13T15:48:27.246Z",
 
64
  "body": "All customers that had previously received the incorrect notifications about the Time Tracker for Jira Cloud and DC app should have received corrective communications at this time.\n\nWe are now resolving this issue.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-07-02T04:43:17.909Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-06-30T02:45:58.000Z",
 
77
  "body": "On June 26, 2026, some customers may have experienced performance degradation with remote Forge apps facing rate-limiting issues. The issue has now been resolved, and the service is operating normally for all affected customers.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-06-26T21:39:37.248Z",
82
  "resolved_inferred": false,
83
  "started_at": "2026-06-26T14:32:39.810Z",
 
90
  "body": "We are now confident that any of the tasks that were impacted by this incident and were delayed should now be operating as expected.\n\nWe apologize for any inconvenience that this issue may have caused.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2026-06-10T06:31:05.820Z",
95
  "resolved_inferred": false,
96
  "started_at": "2026-06-10T04:55:13.006Z",
 
103
  "body": "Between 08:30 UTC and 13:51 UTC on 26 May 2026, some users were unable to load or edit certain macros in the Confluence Cloud page editor. Our engineering team identified and resolved the underlying issue, and macro functionality has been fully restored.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "none",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2026-05-26T13:55:52.263Z",
108
  "resolved_inferred": false,
109
  "started_at": "2026-05-26T10:40:00.326Z",
 
116
  "body": "The root cause has been identified and a fix has been applied.\n\nFull service restoration has been completed.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2026-05-20T14:14:35.345Z",
121
  "resolved_inferred": false,
122
  "started_at": "2026-05-20T12:06:23.836Z",
 
129
  "body": "Due to an incorrect deployment, a banner stating 'This app may stop working soon' was briefly displayed on the Marketplace Apps. This banner was not intended to appear on these apps.\n\nThe feature has since been corrected and the banner is no longer appearing. No action is required, the banner was displayed in error and there is no impact to app functionality or availability.\n\nWe apologise for any confusion this may have caused.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "none",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2026-05-20T10:16:52.997Z",
134
  "resolved_inferred": false,
135
  "started_at": "2026-05-20T10:16:52.944Z",
 
142
  "body": "On May 14, 2026, Developer and Marketplace service desks were inaccessible for affected users. The issue has now been resolved, and the service is operating normally for all affected customers.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "critical",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2026-05-14T21:35:12.921Z",
147
  "resolved_inferred": false,
148
  "started_at": "2026-05-14T21:04:04.214Z",
 
155
  "body": "All products and services impacted by this incident should now be fully recovered, and this incident is resolved.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "critical",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2026-05-14T06:49:28.904Z",
160
  "resolved_inferred": false,
161
  "started_at": "2026-05-14T05:11:20.261Z",
 
168
  "body": "On May 12, 2026, some users in US East region may have experienced intermittent failures with forge invocations for some applications. The issue has now been resolved, and the service is operating normally for all affected customers.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2026-05-12T17:40:43.123Z",
173
  "resolved_inferred": false,
174
  "started_at": "2026-05-12T15:50:29.317Z",
 
181
  "body": "On May 12, 2026, some users in EU West region may have experienced delayed or queued webhook events. The issue has now been resolved, and the service is operating normally for all affected customers.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2026-05-12T18:11:26.274Z",
186
  "resolved_inferred": false,
187
  "started_at": "2026-05-12T14:03:20.536Z",
 
194
  "body": "On May 11, 2026, users in EU West and US East regions may have experienced performance degradation with delayed or queued webhook events. The issue has now been resolved, and the service is operating normally for all affected customers.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "minor",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2026-05-11T18:16:05.697Z",
199
  "resolved_inferred": false,
200
  "started_at": "2026-05-11T14:24:14.135Z",
 
207
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2026-05-08T19:45:31.603Z",
212
  "resolved_inferred": false,
213
  "started_at": "2026-05-08T04:10:28.630Z",
 
220
  "body": "On Tuesday, May 5, 2026, some Forge users may have experienced performance delays in webhook delivery in the US East region. The issue has now been resolved, and the service is operating normally for all affected customers.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "minor",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2026-05-05T22:34:14.686Z",
225
  "resolved_inferred": false,
226
  "started_at": "2026-05-05T17:40:11.867Z",
 
233
  "body": "The issue causing intermittent delays in our webhook delivery has been resolved. A fix was deployed to address a resource constraint in our systems. Our monitoring shows webhook delivery is now operating normally.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "minor",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2026-04-30T14:56:57.972Z",
238
  "resolved_inferred": false,
239
  "started_at": "2026-04-30T08:59:04.029Z",
 
246
  "body": "The issue has now been resolved, and the service is operating normally for all affected customers.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "minor",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2026-04-28T21:50:42.758Z",
251
  "resolved_inferred": false,
252
  "started_at": "2026-04-28T18:28:20.767Z",
 
259
  "body": "The issue has now been resolved, and the service is operating normally for all affected customers.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "major",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2026-04-23T16:14:43.771Z",
264
  "resolved_inferred": false,
265
  "started_at": "2026-04-22T06:57:00.565Z",
 
272
  "body": "The issue has now been resolved, and the service is operating normally for all affected customers.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "major",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2026-04-13T15:11:45.243Z",
277
  "resolved_inferred": false,
278
  "started_at": "2026-04-13T10:58:02.547Z",
 
285
  "body": "The outage affecting Forge app logs between 05:00 UTC and 07:00 UTC on 8 April 2026 has been resolved, and systems are now stable.\n\nWe are currently working on recovery efforts, including retrieving logs from this downtime window and validating data completeness. During this process, you may temporarily see duplicate log entries; however, this will not result in duplicate usage or additional costs.\n\nWe will continue to monitor the system closely and provide further updates as needed.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "critical",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2026-04-08T07:45:13.000Z",
290
  "resolved_inferred": false,
291
  "started_at": "2026-04-08T06:55:07.248Z",
 
298
  "body": "On April 2, 2026, affected users may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "major",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2026-04-02T22:36:41.280Z",
303
  "resolved_inferred": false,
304
  "started_at": "2026-04-02T20:46:43.730Z",
 
311
  "body": "On March 24, 2026, between 04:14 AM UTC and 08:40 AM UTC, Connect Apps using connect API's experienced performance degradation. The issue has now been resolved, and the service is operating normally for all affected customers.",
312
  "first_seen": "2026-09-04T07:06:16Z",
313
  "impact": "major",
314
+ "last_seen": "2026-09-04T10:17:20Z",
315
  "resolved_at": "2026-03-24T08:44:23.346Z",
316
  "resolved_inferred": false,
317
  "started_at": "2026-03-24T07:59:20.308Z",
 
324
  "body": "On March 17th, 2026, between 9:05 AM UTC and 11:10 AM UTC, Forge app management and related developer tooling experienced some service disruption. The issue has now been resolved, and the service is operating normally for affected customers.",
325
  "first_seen": "2026-09-04T07:06:16Z",
326
  "impact": "major",
327
+ "last_seen": "2026-09-04T10:17:20Z",
328
  "resolved_at": "2026-03-17T11:37:37.061Z",
329
  "resolved_inferred": false,
330
  "started_at": "2026-03-17T10:05:28.000Z",
 
337
  "body": "On March 12, 2026, affected Confluence Cloud users may have experienced some service disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
338
  "first_seen": "2026-09-04T07:06:16Z",
339
  "impact": "major",
340
+ "last_seen": "2026-09-04T10:17:20Z",
341
  "resolved_at": "2026-03-13T00:26:04.153Z",
342
  "resolved_inferred": false,
343
  "started_at": "2026-03-12T11:42:38.845Z",
 
350
  "body": "We are providing a further update regarding the install count discrepancy that some partners may have observed for some apps since Feb 27, 2026.\n\n- The Active Installations tab in the Marketplace Partner Portal is now showing accurate install counts for impacted apps from Mar 3, 2026 onward.\n- The install counts displayed on app listings remain accurate for impacted apps.\n- Please note that data from Mar 3, 2026 onward will remain accurate going forward.\n- You may notice a temporary dip in install counts for Mar 2, 2026. We are backfilling the data, and counts for that date will be restored once complete.\n- Actual customer installs were not impacted; only the reported counts displayed in the Partner Portal and on app listings were affected for some apps, and this is now fully functional.\n\nThank you for your patience and understanding.",
351
  "first_seen": "2026-09-04T07:06:16Z",
352
  "impact": "minor",
353
+ "last_seen": "2026-09-04T10:17:20Z",
354
  "resolved_at": "2026-03-04T03:04:15.737Z",
355
  "resolved_inferred": false,
356
  "started_at": "2026-03-02T16:15:12.562Z",
 
363
  "body": "We have now reactivated all subscriptions that were previously cancelled. Impacted users may have received email notifications confirming this change. There has been no impact to the functioning of the app, it should continue to work as expected.\nTo help prevent any future interruptions, we kindly request that billing admins ensure a valid billing payment method is added before the next billing cycle.\nWe apologise for any confusion and appreciate your understanding.",
364
  "first_seen": "2026-09-04T07:06:16Z",
365
  "impact": "major",
366
+ "last_seen": "2026-09-04T10:17:20Z",
367
  "resolved_at": "2026-02-19T17:12:31.473Z",
368
  "resolved_inferred": false,
369
  "started_at": "2026-02-16T11:24:02.892Z",
 
376
  "body": "This issue is resolved. In our monitoring no other unexpected issues were seen.\n\nFor customers still experiencing errors, this may indicate a legitimate permission configuration issue on your side and should be investigated as usual.",
377
  "first_seen": "2026-09-04T07:06:16Z",
378
  "impact": "major",
379
+ "last_seen": "2026-09-04T10:17:20Z",
380
  "resolved_at": "2026-02-19T08:04:57.460Z",
381
  "resolved_inferred": false,
382
  "started_at": "2026-02-13T07:41:39.717Z",
 
389
  "body": "Impact\n\nWe are currently experiencing an issue affecting the Forge platform, specifically related to scheduled triggers. Users may encounter instances where these triggers are not executing as anticipated, disrupting the normal operation of their Forge apps. This behavior began approximately at 2 AM UTC.\n\nCurrent Status\n\nOur engineering team identified the root cause and performed a rollback deployment to resolve the issue.",
390
  "first_seen": "2026-09-04T07:06:16Z",
391
  "impact": "major",
392
+ "last_seen": "2026-09-04T10:17:20Z",
393
  "resolved_at": "2026-02-06T11:32:35.358Z",
394
  "resolved_inferred": false,
395
  "started_at": "2026-02-06T09:37:35.831Z",
 
402
  "body": "Team has identified the root cause and the issue has now been resolved, and the impacted services are operating normally. Team will continue to monitor the impacted services.",
403
  "first_seen": "2026-09-04T07:06:16Z",
404
  "impact": "major",
405
+ "last_seen": "2026-09-04T10:17:20Z",
406
  "resolved_at": "2026-02-03T10:50:35.750Z",
407
  "resolved_inferred": false,
408
  "started_at": "2026-02-03T10:19:54.355Z",
 
415
  "body": "On January 28, 2026, some customers may have experienced Forge function invocation availability disruption. The issue has now been resolved, and the service is operating normally for all affected customers.",
416
  "first_seen": "2026-09-04T07:06:16Z",
417
  "impact": "major",
418
+ "last_seen": "2026-09-04T10:17:20Z",
419
  "resolved_at": "2026-01-28T19:20:20.274Z",
420
  "resolved_inferred": false,
421
  "started_at": "2026-01-28T17:34:56.308Z",
 
428
  "body": "The issue is completely resolved and Developer Console is now displaying all the usage metrics correctly. We apologize for any inconvenience this may have caused.",
429
  "first_seen": "2026-09-04T07:06:16Z",
430
  "impact": "minor",
431
+ "last_seen": "2026-09-04T10:17:20Z",
432
  "resolved_at": "2025-12-17T06:07:27.782Z",
433
  "resolved_inferred": false,
434
  "started_at": "2025-12-16T05:47:29.672Z",
 
441
  "body": "The rollback required to resolve this issue is now completed, and we have verified across the impacted products that App installation behaviour is now working as expected. We apologize for any inconvenience this may have caused.",
442
  "first_seen": "2026-09-04T07:06:16Z",
443
  "impact": "critical",
444
+ "last_seen": "2026-09-04T10:17:20Z",
445
  "resolved_at": "2025-12-11T04:37:14.124Z",
446
  "resolved_inferred": false,
447
  "started_at": "2025-12-11T01:08:44.953Z",
 
454
  "body": "Between Dec 8 05:30 UTC and Dec 9 05:30 UTC, new Forge app versions were not auto-published to Atlassian Marketplace. We\u2019ve implemented a mitigation and auto-publish is operating normally.\n\nAction required: If you deployed during this window, please manually publish those versions in Marketplace (or re-deploy your app with forge deploy). \n\nWe\u2019re sorry for the inconvenience.",
455
  "first_seen": "2026-09-04T07:06:16Z",
456
  "impact": "none",
457
+ "last_seen": "2026-09-04T10:17:20Z",
458
  "resolved_at": "2025-12-09T08:14:04.000Z",
459
  "resolved_inferred": false,
460
  "started_at": "2025-12-09T08:14:04.000Z",
 
467
  "body": "The feature flag causing the issue has been reverted, fixing the problem. With that this incident is resolved.",
468
  "first_seen": "2026-09-04T07:06:16Z",
469
  "impact": "minor",
470
+ "last_seen": "2026-09-04T10:17:20Z",
471
  "resolved_at": "2025-12-05T12:09:05.554Z",
472
  "resolved_inferred": false,
473
  "started_at": "2025-12-05T08:08:53.836Z",
 
480
  "body": "Impact\n\nCustomers experienced degraded performance in log ingestion services affecting the Ecosystem, particularly the Forge platform. Due to this issue, accessing logs ingested from the morning of the incident (starting 06:00 UTC) was impacted, leading to delays or incomplete data visibility through the Dev Console and related channels.\n\nCurrent Status\n\nThis incident has been resolved, and Forge Logs are back in operational mode.",
481
  "first_seen": "2026-09-04T07:06:16Z",
482
  "impact": "major",
483
+ "last_seen": "2026-09-04T10:17:20Z",
484
  "resolved_at": "2025-11-10T14:03:18.231Z",
485
  "resolved_inferred": false,
486
  "started_at": "2025-11-10T10:41:39.876Z",
 
493
  "body": "Validation is complete. All tables backing Aggregated Sales Reporting, Transaction Reporting, and Export Transaction APIs have been fully repopulated. Data for the impacted window (25 Oct 2025 00:00 IST \u2013 27 Oct 2025 14:00 IST) has been restored and verified. No action is required from vendors. We are closing this incident.",
494
  "first_seen": "2026-09-04T07:06:16Z",
495
  "impact": "minor",
496
+ "last_seen": "2026-09-04T10:17:20Z",
497
  "resolved_at": "2025-10-28T13:42:21.577Z",
498
  "resolved_inferred": false,
499
  "started_at": "2025-10-27T12:04:05.344Z",
 
506
  "body": "### Summary\n\nOn October 22, 2025, Confluence Cloud webhook events were not delivered to Connect apps and Forge apps that use webhooks via `connectModules`. This outage began after a backend deployment introduced a code change that prevented Confluence from recognizing registered webhook listeners. As a result, no webhook events were generated for approximately 20 hours, impacting apps that depend on webhooks. The issue was resolved by rolling back to a previous stable deployment. We\u2019re taking steps to improve detection and rollback processes.\n\n### **IMPACT**\n\nBetween 01:12 UTC and 21:46 UTC on October 22, 2025, Confluence was unable to send out webhook events. As a result, none of the apps that rely on these events received them during this time. This includes Connect apps and Forge apps that use webhooks through `connectModules`.\n\nCustomers may have noticed outdated content appearing in their Marketplace apps, or new content not syncing.\n\n### **ROOT CAUSE**\n\nThe issue was caused by a change to Confluence backend systems. As a result, no webhook events were delivered to Connect and Forge apps that use webhooks via `connectModules`. This occurred because a Java class was loaded by 2 different classloaders, causing Confluence to fail to find registered webhook listeners and thus not emit events.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWebhooks are a critical functionality for many apps. On this occasion, our system did not generate any errors because it was inadvertently using an incorrect version of a Java class, which was loaded by a different ClassLoader. As a result, the issue occurred silently and couldn\u2019t be detected via existing automated error monitoring.\n\n\u00a0\n\nWe are prioritizing the following improvement actions to help prevent this issue from reoccurring:\n\n* Additional integration tests to identify problems before merging code to our main branch.\n* Additional detectors and alerts to identify when webhook event volume drops below a certain threshold.\n* Exploring resync / lost event recovery mechanism without overloading Atlassian infrastructure\n\n * We acknowledge that the availability of Connect apps is important for our customers and ecosystem partners, and we will endeavour to provide support for these apps in line with our public roadmap for Connect end of life. You can read our announcement here: [Announcing Connect End of Support: Timeline and Next Steps - Work Life by Atlassian](https://www.atlassian.com/blog/developer/announcing-connect-end-of-support-timeline-and-next-steps)\n \n While this incident primarily impacted Connect, we would like to note that Forge currently includes additional internal capabilities, such as retry [Atlassian app events](https://developer.atlassian.com/platform/forge/events-reference/product_events/#retry-atlassian-app-events) and internal DLQ, that could assist with recovery in these types of incidents..\n\n \n \n We highly encourage partners to migrate to Forge to utilize the latest webhook infrastructure.\n\n \n \n\nWe apologize to customers and ecosystem partners whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support",
507
  "first_seen": "2026-09-04T07:06:16Z",
508
  "impact": "critical",
509
+ "last_seen": "2026-09-04T10:17:20Z",
510
  "resolved_at": "2025-10-22T22:09:20.000Z",
511
  "resolved_inferred": false,
512
  "started_at": "2025-10-22T12:15:57.948Z",
 
519
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
520
  "first_seen": "2026-09-04T07:06:16Z",
521
  "impact": "none",
522
+ "last_seen": "2026-09-04T10:17:20Z",
523
  "resolved_at": "2025-10-21T05:24:25.603Z",
524
  "resolved_inferred": false,
525
  "started_at": "2025-10-20T07:56:11.430Z",
 
532
  "body": "Between 06:58 12 Oct UTC to 18:30 12 Oct UTC, we experienced calls from a some forge apps to external services (outside of Atlassian) intermittently fail. The issue has been resolved and the service is operating normally.",
533
  "first_seen": "2026-09-04T07:06:16Z",
534
  "impact": "none",
535
+ "last_seen": "2026-09-04T10:17:20Z",
536
  "resolved_at": "2025-10-12T19:25:16.839Z",
537
  "resolved_inferred": false,
538
  "started_at": "2025-10-12T15:25:53.472Z",
 
545
  "body": "Between 06:30 12th Oct, 2025 UTC to 08:33 12th Oct, 2025 UTC, we experienced a degradation in us-east and ca-central regions affecting authenticated egress calls from Forge functions and from Forge bridge. \n\nThe issue has been resolved and the service is operating normally.",
546
  "first_seen": "2026-09-04T07:06:16Z",
547
  "impact": "none",
548
+ "last_seen": "2026-09-04T10:17:20Z",
549
  "resolved_at": "2025-10-12T09:14:40.272Z",
550
  "resolved_inferred": false,
551
  "started_at": "2025-10-12T07:29:47.822Z",
 
558
  "body": "Between 29 Sep 2025 07:10 UTC and 03 Oct 2025 06:00 UTC, some customers experienced unexpected Allow access OAuth consent prompts when using the Forge app UI. The issue has been resolved, and the service is operating normally.",
559
  "first_seen": "2026-09-04T07:06:16Z",
560
  "impact": "major",
561
+ "last_seen": "2026-09-04T10:17:20Z",
562
  "resolved_at": "2025-10-03T06:24:19.291Z",
563
  "resolved_inferred": false,
564
  "started_at": "2025-10-03T03:43:27.000Z",
 
571
  "body": "Between 08:30 AM UTC to 16:30 UTC on September 29, 2025, some developers experienced delays of log delivery for the Dev Console. The root cause was an unexpected spike in volume that required updates to autoscaling configurations to address. We have deployed a fix to mitigate the issue and have verified that the services have recovered. The conditions that cause the bug have been addressed and we\u2019re actively working on a permanent fix. The issue has been resolved and the service is processing logs normally. We are currently processing the delayed logs and anticipate completion by 17:00 UTC today, September 29, 2025.",
572
  "first_seen": "2026-09-04T07:06:16Z",
573
  "impact": "minor",
574
+ "last_seen": "2026-09-04T10:17:20Z",
575
  "resolved_at": "2025-09-29T17:07:09.374Z",
576
  "resolved_inferred": false,
577
  "started_at": "2025-09-29T15:32:40.124Z",
 
584
  "body": "Issues affecting Marketplace Reporting APIs and Partner Portal have been resolved. Both services are now back up and running normally. This incident has been resolved.",
585
  "first_seen": "2026-09-04T07:06:16Z",
586
  "impact": "critical",
587
+ "last_seen": "2026-09-04T10:17:20Z",
588
  "resolved_at": "2025-09-26T10:45:55.450Z",
589
  "resolved_inferred": false,
590
  "started_at": "2025-09-26T10:09:49.455Z",
 
597
  "body": "We experienced a disruption affecting all JSM assets APIs using Connect JWT and user impersonation for connect apps, starting on September 13th at 2:05 AM UTC and lasting until September 17th at 3:36 PM UTC. This issue was caused by an internal routing change within Atlassian systems. During this time, all Assets API calls using Connect authentications were disrupted. The issue has now been resolved, and all affected APIs are fully operational again. We sincerely apologise for any inconvenience caused and thank you for your patience and understanding.",
598
  "first_seen": "2026-09-04T07:06:16Z",
599
  "impact": "none",
600
+ "last_seen": "2026-09-04T10:17:20Z",
601
  "resolved_at": "2025-09-25T08:14:11.708Z",
602
  "resolved_inferred": false,
603
  "started_at": "2025-09-25T08:14:11.610Z",
 
610
  "body": "No customer impact has been observed seen since mitigation began. We are now closing this incident.",
611
  "first_seen": "2026-09-04T07:06:16Z",
612
  "impact": "major",
613
+ "last_seen": "2026-09-04T10:17:20Z",
614
  "resolved_at": "2025-09-19T02:02:51.884Z",
615
  "resolved_inferred": false,
616
  "started_at": "2025-09-15T02:06:05.594Z",
 
623
  "body": "Changes have landed in production at 11:40 AM (UTC). The issue is resolved and the endpoint is now operating normally.",
624
  "first_seen": "2026-09-04T07:06:16Z",
625
  "impact": "major",
626
+ "last_seen": "2026-09-04T10:17:20Z",
627
  "resolved_at": "2025-09-12T11:56:02.700Z",
628
  "resolved_inferred": false,
629
  "started_at": "2025-09-12T08:14:51.720Z",
 
636
  "body": "Between 12:50 UTC to 13:20 UTC, we experienced partial failures for deploying forge apps via forge cli for Atlassian Developers. \nThe issue has been resolved and the service is operating normally.",
637
  "first_seen": "2026-09-04T07:06:16Z",
638
  "impact": "major",
639
+ "last_seen": "2026-09-04T10:17:20Z",
640
  "resolved_at": "2025-09-08T13:46:29.610Z",
641
  "resolved_inferred": false,
642
  "started_at": "2025-09-08T13:35:23.947Z",
 
649
  "body": "This incident is resolved now. Between 6:30 AM and 8:35 AM UTC on September 8th, there was an issue with one of the dependent vendor services, due to which invocations were intermittently failing, primarily in the EU-CENTRAL-1 Region. This issue is fixed now.",
650
  "first_seen": "2026-09-04T07:06:16Z",
651
  "impact": "major",
652
+ "last_seen": "2026-09-04T10:17:20Z",
653
  "resolved_at": "2025-09-08T10:05:53.000Z",
654
  "resolved_inferred": false,
655
  "started_at": "2025-09-08T07:44:14.089Z",
api/v/atlassian-partners.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atlassian-partners",
4
  "platform": "statuspage",
5
  "status_url": "https://partners.status.atlassian.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-05-14T06:48:27.737Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:11:20.126Z",
@@ -25,7 +25,7 @@
25
  "body": "Users attempting to access the Atlassian shop will now be directed to our Homepage. This will prevent ongoing security related error messages from being presented in the meantime while the shop is able to be restored to its full functionality.\nPlease reach out to Atlassian Support for additional assistance if required.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-05-07T02:38:02.620Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-07T02:27:15.303Z",
@@ -38,7 +38,7 @@
38
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2025-10-21T05:24:27.089Z",
43
  "resolved_inferred": false,
44
  "started_at": "2025-10-20T07:56:11.485Z",
 
3
  "slug": "atlassian-partners",
4
  "platform": "statuspage",
5
  "status_url": "https://partners.status.atlassian.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-05-14T06:48:27.737Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:11:20.126Z",
 
25
  "body": "Users attempting to access the Atlassian shop will now be directed to our Homepage. This will prevent ongoing security related error messages from being presented in the meantime while the shop is able to be restored to its full functionality.\nPlease reach out to Atlassian Support for additional assistance if required.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-05-07T02:38:02.620Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-07T02:27:15.303Z",
 
38
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "major",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2025-10-21T05:24:27.089Z",
43
  "resolved_inferred": false,
44
  "started_at": "2025-10-20T07:56:11.485Z",
api/v/atlassian-support.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atlassian-support",
4
  "platform": "statuspage",
5
  "status_url": "https://support.status.atlassian.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-05-14T06:48:27.570Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:03:32.221Z",
@@ -25,7 +25,7 @@
25
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-05-08T02:02:13.089Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-08T01:31:38.263Z",
@@ -38,7 +38,7 @@
38
  "body": "### SUMMARY\n\n### \n\nBetween May 1, 2026 at 23:34 UTC and May 2, 2026 at 02:53 UTC Atlassian customers using Jira and Jira Service Management (JSM) across all Cloud tenants received an error page when attempting to open a work item due to a schema incompatibility, and editing work item fields was degraded for both products. Navigating to and interacting with boards were degraded for Jira specifically. On Jira mobile, users were unable to view work items and work item search was degraded. This was caused by a deployment of a schema configuration change that had only been validated against some production environments.\n\n \n\nThe issue also affected Atlassian's customer support operations and temporarily impacted Atlassian\u2019s ability to respond to incoming support requests. Customers were able to raise tickets as usual.\n\n \n\nAtlassian\u2019s automated monitoring systems detected the issue on May 1, 2026 at 23:41 UTC, and engineering teams promptly began investigating.\n\n \n\nThe issue was reported on Statuspage on May 2, 2026 at 00:55 UTC.\n\n \n\nThe issue was resolved after 3 hours and 19 minutes on May 2, 2026 at 02:53 UTC when the previous version of the schema configuration was successfully redeployed to all regions.\n\n \n\n### IMPACT\n\n### \n\n- **Duration**: 3 hours 19 minutes (May 1, 2026 at 23:34 UTC \u2013 May 2, 2026 at 02:53 UTC)\n- **Affected regions**: All regions.\n- **Affected products**: Jira, JSM, Jira Mobile\n- **Customer experience**:\n- Users were unable to view work items using the work item view; consequently updating and creating work items from the work item view was affected.\n- Editing work items was degraded.\n- Boards did not show under Spaces in the Jira navigation.\n- Certain board interactions were affected.\n- Other areas of Jira not dependent on the broken schema configuration continued to operate normally.\n\n### \n\n### ROOT CAUSE\n\n### \n\nThe root cause was a deployment sequencing issue. A schema configuration change was deployed to the API gateway layer before the corresponding application-level change had been deployed across all production environments. This created a mismatch between the schema expected by the gateway and the schema served by the application servers.\n\n### \n\n### MITIGATIONS\n\n### \n\nThe engineering team identified the problematic schema change and initiated a rollback of the deployment. A deployment blocker was put in place to prevent further changes while the rollback was executed. The previous version of the schema configuration was redeployed, and service was restored across all regions.\n\n### \n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\n### \n\nWe understand that service disruptions impact your productivity. In addition to our existing testing and preventative processes, Atlassian is prioritizing the following actions to help reduce the likelihood and impact of similar incidents in the future and to speed up recovery when issues occur:\n\n- We are adding automated pre-deployment checks to verify that schema configurations are compatible across all production environments before changes are deployed.\n- We will streamline our incident communication processes, incident response training and tooling to reduce the time between incident detection and customer notification.\n- We are working to improve resilience of critical customer-facing support services to ensure SLA continuity during outages.\n\nWe apologize to customers whose services were impacted during this incident. We are taking immediate steps to reduce the risk and impact of similar issues in future.\n\n \n\nThanks,\n\nAtlassian",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-05-02T02:47:55.357Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-05-02T01:38:27.814Z",
@@ -51,7 +51,7 @@
51
  "body": "### Summary\n\nOn April 13, 2026, between 05:49 and 06:29 UTC, customers experienced failures when attempting to log in, sign up, reset passwords, and complete multi-factor authentication flows across Atlassian cloud products. Approximately 90% of authentication requests failed during the peak impact window, affecting users in the US East and EU regions. The incident was mitigated within 40 minutes through manual intervention, and full service was restored by 06:29 UTC.\n\n### **IMPACT**\n\n* **Duration**: ~40 minutes \\(05:49\u201306:29 UTC, April 13, 2026\\)\n* **Affected regions**: US East and EU \\(authentication infrastructure serves EU traffic from US East, with traffic primarily from EU at this time of day\\).\n* **Affected products**: All Atlassian cloud products requiring authentication, including Jira, Confluence, Jira Service Management, and Trello.\n* **Customer experience**: Users attempting to log in, sign up, reset passwords, or complete MFA flows received errors. Users already logged in with active sessions were unaffected.\n\n### **ROOT CAUSE**\n\nThis incident had several contributing factors that combined to produce a failure that the system could not recover from without manual intervention.\n\n**The primary cause** was a recently enabled change that caused our authentication infrastructure to retry requests to a downstream identity service when those requests were slow to respond. This retry behaviour was rolled out to 100% of traffic earlier the same day. Under normal conditions this would be benign, but it meant that any slowness in the downstream service was amplified. Since multiple upstream services were also independently retrying their own failed requests, the amplification compounded further into a retry storm.\n\n**The trigger** was a burst of legitimate user traffic. A pattern of many parallel link preview requests for a single user caused a concentrated load spike on a downstream identity service, pushing its response times above the retry threshold. On its own, this kind of spike had occurred many times before and always recovered. With the retry amplification now in effect, the spike instead created a runaway feedback loop: slow responses caused retries, retries increased load, increased load caused slower responses, preventing recovery.\n\nThe incident was mitigated by manually scaling up the downstream identity service to provide sufficient capacity to absorb the amplified load. Once scaled, the service recovered immediately, bringing authentication error rates to zero within one minute.\n\n**REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe are taking the following actions designed to prevent recurrence and improve our resilience:\n\n1. **Immediate**: The retry-on-timeout change has been disabled.\n2. **Load shedding and self-healing**: We are adding load shedding capabilities to our authentication services so that they can automatically shed excess load and self-recover during traffic spikes, without requiring action before automatic scaling starts.\n3. **Reducing request fan-out**: We are reviewing patterns where a single user action can generate many parallel downstream requests, and will introduce methods where possible to reduce the amplification potential.\n\nWe apologize to customers whose services were interrupted by this incident and we are taking immediate steps to improve the platform\u2019s reliability.\n\nThanks,\n\nAtlassian Customer Support",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-04-13T10:17:20.727Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-13T07:29:45.882Z",
@@ -64,7 +64,7 @@
64
  "body": "Our team has been able to successfully recover all services from confluence.atlassian.com and ja.confluence.atlassian.com and these sites are now performing as expected. This incident is now resolved.\nWe apologize for any inconvenience that this issue may have caused.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "critical",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-04-02T02:39:51.742Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-04-02T01:49:20.929Z",
@@ -77,7 +77,7 @@
77
  "body": "Team has reconfirmed everything is working as expected. This issue is resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2025-12-17T14:43:58.021Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-12-17T13:48:38.385Z",
@@ -90,7 +90,7 @@
90
  "body": "The feature flag causing the issue has been reverted, fixing the problem. With that this incident is resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-12-05T12:09:05.412Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-05T08:08:52.709Z",
@@ -103,7 +103,7 @@
103
  "body": "The issue has been resolved and there is no performance related slowness on Atlassian Community Forums now.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2025-11-10T04:17:13.505Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-11-06T19:36:32.503Z",
@@ -116,7 +116,7 @@
116
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2025-10-21T05:24:27.129Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-10-20T07:56:12.455Z",
@@ -129,7 +129,7 @@
129
  "body": "We have resolved the incident. A new version of the Loom chrome extension has been approved and published to the Chrome Extension store. Update to the latest version(v5.5.142) of the extension.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-10-09T20:00:15.226Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-10-08T22:20:37.356Z",
@@ -142,7 +142,7 @@
142
  "body": "We are closing this incident on Statuspage as the Atlassian Support portal functionality has been restored. \n\nWe are aware that the ticket attachments panel remains unavailable and that some customers may be receiving a 'Something went wrong!' error message despite successfully uploading ticket attachments. We are working to resolve these UX issues. Atlassian Support is available for customers needing further assistance.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-10-08T02:18:18.900Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-10-06T01:10:49.669Z",
 
3
  "slug": "atlassian-support",
4
  "platform": "statuspage",
5
  "status_url": "https://support.status.atlassian.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "### Summary\n\nOn May 14, 2026, between 04:30 and 05:26 UTC, Atlassian customers experienced widespread service disruption across multiple Atlassian Cloud products. The issue was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products. The incident was detected within a minute by automated monitoring systems and mitigated in 56 minutes.\n\n### **IMPACT**\n\nDuring the incident, customers attempting to access Atlassian Cloud products in the us-east region experienced authentication and permission failures and were unable to access services. Customers also experienced errors when accessing the support portal until Atlassian fell back to an alternate support method. This was caused by a core identity service in the us-east region becoming unavailable. Affected products included Atlassian Administration, Atlassian Analytics, Bitbucket, Compass, Confluence, Jira, Jira Product Discovery, Jira Service Management and Trello. Some users outside us-east may have been affected in certain scenarios.\n\n### **ROOT CAUSE**\n\nThe incident was caused by a race condition in our internal deployment orchestration platform during a routine rollback operation of a core identity service in the us-east region. This race condition resulted in insufficient capacity for the identity service in the affected region which started returning errors to dependent products.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know that outages impact your productivity. Atlassian is prioritizing the following actions to help prevent similar incidents in future:\n\n* **Refine deployment orchestration safeguards**\n\n * Harden our deployment platform to prevent similar race conditions or resulting capacity loss during a rollback operation.\n * Streamline mitigation steps when a service becomes unavailable in a region.\n \n* **Reduce cross-region impact**\n\n * Improve regional isolation and fallback handling so an issue affecting a single region is less likely to impact customers or product functionality in other regions.\n \n\nWe recognise how critical reliable access to Atlassian products is for our customers' productivity, and we apologize to customers who were impacted by this incident.\n\nThanks,\n\nAtlassian",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-05-14T06:48:27.570Z",
17
  "resolved_inferred": false,
18
  "started_at": "2026-05-14T05:03:32.221Z",
 
25
  "body": "All dates and times below are in UTC unless stated otherwise.\n\n### Summary\n\nOn May 8, 2026 between 00:22 and 06:08, one of our hosting providers suffered a significant incident in a specific availability zone in prod-east which led to Atlassian customers experiencing degraded performance and delays of background operations and automation execution.\n\nThe incident started on May 8, 2026 at 00:22 and was detected within 4 minutes by automated monitoring systems. Our teams worked to restore core access by 06:08. Final cleanup of backlogged processes and minor issues progressed in stages from there was completed iteratively by 19:15.\n\n### **IMPACT**\n\nThe primary infrastructure affected in this incident was the event processing pipeline in the prod-east region, which distributes events between Atlassian services and underpins background operations such as automation execution, search indexing, notifications, permission synchronisation.\n\n* Between 00:22 and 06:08, an infrastructure incident in our hosting provider triggered an ingestion failure in our event processing pipeline.\n* At 02:50, event ingestion was failed over to an unaffected availability zone, progressively restoring live event flows.\n* At 06:08, reliability for new ingestion in prod-east recovered to 100%. The remaining work was to drain the accumulated cross-region backlog of messages, which completed by 17:00.\n* By 18:48, Automation had processed their backlog of events that were created while processing\n\n**Automation**\n\nBetween 00:22 and 02:50, customers with automation rules triggered by events originating from the prod-east region experienced a significant reduction in rule executions. During this window, event-triggered automation rules were not firing because the events that trigger them were not being delivered. Rule authoring, saving, and rules triggered manually, by schedules, or by webhooks were not affected.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of live events to Automation and allowing new event-triggered rules to begin executing normally. However, events generated during the impact window still needed to be replayed before delayed automations could be processed.\n\nBeginning at 08:28, upstream services replayed their queued events in a coordinated sequence, and all replayed events were processed by 18:48. During the replay window, customers may have experienced automation rules executing later than expected, a small number of rules reaching daily processing limits due to compressed replay, and time-sensitive rules not completing as expected if internal timeout thresholds were exceeded.\n\n**Jira and Jira Service Management**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruption to Jira and Jira Service Management event-driven features like automation, along with a short period of elevated errors during infrastructure failover. Core Jira experiences, including issue view, boards, and project navigation, remained available throughout the incident.\n\nJira event delivery was affected by the primary impact, preventing downstream services from receiving issue lifecycle events. This affected automation rules triggered by Jira events, AI agent orchestration in Jira, notifications for issue updates and transitions, search indexing for newly created or modified issues, and event-driven integrations between Jira and other Atlassian products.\n\nAt 02:50, the event processing infrastructure failed over to an unaffected availability zone, restoring delivery of new events. All events generated during the impact window were retained in a recovery queue and required replaying. This began at 08:28 and completed at 12:00. During the replay window, customers may have experienced automation rules executing later than expected, delayed notifications arriving hours after the triggering action, temporary gaps in search results for content created or modified during the impact window, and AI agent workflows not completing as expected where internal timeout thresholds were exceeded.\n\n**Confluence**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced disruptions to event-driven services in Confluence. This resulted in delays to search indexing, notifications, automation rule execution, and permission synchronisation.\n\nThe underlying event processing infrastructure failed over to an unaffected availability zone, after which live Confluence operations resumed normally. However, events generated during the impact window were queued for replay, and some background services remained delayed until that replay and related validation work completed.\n\nBetween 10:14 and 17:00, a bulk replay of all the queued tenant replay tasks was completed to restore data consistency. During and immediately after the replay window, customers may have experienced search results not reflecting content created or modified during the outage, delayed or missing notifications for page and comment activity, automation rules firing later than expected, and brief delays in permission synchronisation for tenants relying on incremental identity sync.\n\n**Bitbucket and Pipelines**\n\nBetween 00:22 and 06:08, customers using Bitbucket and Pipelines experienced failures and degraded functionality across event-driven workflows. Core Git operations, including push, pull, and clone, were not affected and continued to operate normally throughout the incident.\n\nAutomatic pipeline triggers initiated by push or pull request events were unavailable during the impact window. Merge queues, custom merge checks, Forge-based triggers, workspace permission changes, and some workspace provisioning flows were also affected. Customers using merge queues were unable to merge pull requests, and some pipeline steps failed because queued work contributed to elevated concurrency limits.\n\nAt approximately 03:57, Pipelines was reconfigured to consume events through an alternative path, restoring automatic pipeline triggering. Merge queues, custom merge checks, Forge triggers, and other affected workflows were progressively restored as the underlying event processing infrastructure recovered. All Bitbucket and Pipelines services were confirmed fully operational by 06:08. After recovery, queued events were reviewed and replayed where safe to restore data consistency for billing, audit logging, and other background processes.\n\n**Identity Services**\n\nBetween 00:22 and 02:50, customers with tenants hosted in the prod-east region experienced delays in the propagation of identity and group membership changes to downstream Atlassian products. Core identity operations, including authentication, login, and direct group management actions, were not affected and continued to function normally throughout the incident.\n\nThe impact was limited to asynchronous, event-driven operations that depend on the event processing pipeline. This included delays in delivering group membership and user profile changes to products such as Jira and Confluence, which affected downstream permission synchronisation and crowd sync flows. A small number of SCIM-based identity synchronisation and site provisioning workflows also experienced temporary delays.\n\nAfter the event processing infrastructure recovered, backed-up identity and group directory events were replayed where required, restoring downstream consistency for affected products. No identity data was lost. Group membership changes, user profile updates, and provisioning-related events that occurred during the impact window were retained and processed after recovery.\n\n### **REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe know outages impact your productivity. While our monitoring and recovery processes helped us respond quickly, this incident highlighted opportunities to further strengthen resilience for event-driven services.\n\nWe are prioritizing improvements that will:\n\n* **Enhance failover coverage** so critical event processing can recover more smoothly during infrastructure disruptions.\n* **Strengthen recovery handling** so replayed events can be processed more quickly.\n\nWe apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform\u2019s performance and availability.\n\nThanks,\n\nAtlassian Customer Support",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "minor",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-05-08T02:02:13.089Z",
30
  "resolved_inferred": false,
31
  "started_at": "2026-05-08T01:31:38.263Z",
 
38
  "body": "### SUMMARY\n\n### \n\nBetween May 1, 2026 at 23:34 UTC and May 2, 2026 at 02:53 UTC Atlassian customers using Jira and Jira Service Management (JSM) across all Cloud tenants received an error page when attempting to open a work item due to a schema incompatibility, and editing work item fields was degraded for both products. Navigating to and interacting with boards were degraded for Jira specifically. On Jira mobile, users were unable to view work items and work item search was degraded. This was caused by a deployment of a schema configuration change that had only been validated against some production environments.\n\n \n\nThe issue also affected Atlassian's customer support operations and temporarily impacted Atlassian\u2019s ability to respond to incoming support requests. Customers were able to raise tickets as usual.\n\n \n\nAtlassian\u2019s automated monitoring systems detected the issue on May 1, 2026 at 23:41 UTC, and engineering teams promptly began investigating.\n\n \n\nThe issue was reported on Statuspage on May 2, 2026 at 00:55 UTC.\n\n \n\nThe issue was resolved after 3 hours and 19 minutes on May 2, 2026 at 02:53 UTC when the previous version of the schema configuration was successfully redeployed to all regions.\n\n \n\n### IMPACT\n\n### \n\n- **Duration**: 3 hours 19 minutes (May 1, 2026 at 23:34 UTC \u2013 May 2, 2026 at 02:53 UTC)\n- **Affected regions**: All regions.\n- **Affected products**: Jira, JSM, Jira Mobile\n- **Customer experience**:\n- Users were unable to view work items using the work item view; consequently updating and creating work items from the work item view was affected.\n- Editing work items was degraded.\n- Boards did not show under Spaces in the Jira navigation.\n- Certain board interactions were affected.\n- Other areas of Jira not dependent on the broken schema configuration continued to operate normally.\n\n### \n\n### ROOT CAUSE\n\n### \n\nThe root cause was a deployment sequencing issue. A schema configuration change was deployed to the API gateway layer before the corresponding application-level change had been deployed across all production environments. This created a mismatch between the schema expected by the gateway and the schema served by the application servers.\n\n### \n\n### MITIGATIONS\n\n### \n\nThe engineering team identified the problematic schema change and initiated a rollback of the deployment. A deployment blocker was put in place to prevent further changes while the rollback was executed. The previous version of the schema configuration was redeployed, and service was restored across all regions.\n\n### \n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\n### \n\nWe understand that service disruptions impact your productivity. In addition to our existing testing and preventative processes, Atlassian is prioritizing the following actions to help reduce the likelihood and impact of similar incidents in the future and to speed up recovery when issues occur:\n\n- We are adding automated pre-deployment checks to verify that schema configurations are compatible across all production environments before changes are deployed.\n- We will streamline our incident communication processes, incident response training and tooling to reduce the time between incident detection and customer notification.\n- We are working to improve resilience of critical customer-facing support services to ensure SLA continuity during outages.\n\nWe apologize to customers whose services were impacted during this incident. We are taking immediate steps to reduce the risk and impact of similar issues in future.\n\n \n\nThanks,\n\nAtlassian",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "critical",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-05-02T02:47:55.357Z",
43
  "resolved_inferred": false,
44
  "started_at": "2026-05-02T01:38:27.814Z",
 
51
  "body": "### Summary\n\nOn April 13, 2026, between 05:49 and 06:29 UTC, customers experienced failures when attempting to log in, sign up, reset passwords, and complete multi-factor authentication flows across Atlassian cloud products. Approximately 90% of authentication requests failed during the peak impact window, affecting users in the US East and EU regions. The incident was mitigated within 40 minutes through manual intervention, and full service was restored by 06:29 UTC.\n\n### **IMPACT**\n\n* **Duration**: ~40 minutes \\(05:49\u201306:29 UTC, April 13, 2026\\)\n* **Affected regions**: US East and EU \\(authentication infrastructure serves EU traffic from US East, with traffic primarily from EU at this time of day\\).\n* **Affected products**: All Atlassian cloud products requiring authentication, including Jira, Confluence, Jira Service Management, and Trello.\n* **Customer experience**: Users attempting to log in, sign up, reset passwords, or complete MFA flows received errors. Users already logged in with active sessions were unaffected.\n\n### **ROOT CAUSE**\n\nThis incident had several contributing factors that combined to produce a failure that the system could not recover from without manual intervention.\n\n**The primary cause** was a recently enabled change that caused our authentication infrastructure to retry requests to a downstream identity service when those requests were slow to respond. This retry behaviour was rolled out to 100% of traffic earlier the same day. Under normal conditions this would be benign, but it meant that any slowness in the downstream service was amplified. Since multiple upstream services were also independently retrying their own failed requests, the amplification compounded further into a retry storm.\n\n**The trigger** was a burst of legitimate user traffic. A pattern of many parallel link preview requests for a single user caused a concentrated load spike on a downstream identity service, pushing its response times above the retry threshold. On its own, this kind of spike had occurred many times before and always recovered. With the retry amplification now in effect, the spike instead created a runaway feedback loop: slow responses caused retries, retries increased load, increased load caused slower responses, preventing recovery.\n\nThe incident was mitigated by manually scaling up the downstream identity service to provide sufficient capacity to absorb the amplified load. Once scaled, the service recovered immediately, bringing authentication error rates to zero within one minute.\n\n**REMEDIAL ACTIONS PLAN & NEXT STEPS**\n\nWe are taking the following actions designed to prevent recurrence and improve our resilience:\n\n1. **Immediate**: The retry-on-timeout change has been disabled.\n2. **Load shedding and self-healing**: We are adding load shedding capabilities to our authentication services so that they can automatically shed excess load and self-recover during traffic spikes, without requiring action before automatic scaling starts.\n3. **Reducing request fan-out**: We are reviewing patterns where a single user action can generate many parallel downstream requests, and will introduce methods where possible to reduce the amplification potential.\n\nWe apologize to customers whose services were interrupted by this incident and we are taking immediate steps to improve the platform\u2019s reliability.\n\nThanks,\n\nAtlassian Customer Support",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-04-13T10:17:20.727Z",
56
  "resolved_inferred": false,
57
  "started_at": "2026-04-13T07:29:45.882Z",
 
64
  "body": "Our team has been able to successfully recover all services from confluence.atlassian.com and ja.confluence.atlassian.com and these sites are now performing as expected. This incident is now resolved.\nWe apologize for any inconvenience that this issue may have caused.",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "critical",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-04-02T02:39:51.742Z",
69
  "resolved_inferred": false,
70
  "started_at": "2026-04-02T01:49:20.929Z",
 
77
  "body": "Team has reconfirmed everything is working as expected. This issue is resolved.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2025-12-17T14:43:58.021Z",
82
  "resolved_inferred": false,
83
  "started_at": "2025-12-17T13:48:38.385Z",
 
90
  "body": "The feature flag causing the issue has been reverted, fixing the problem. With that this incident is resolved.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-12-05T12:09:05.412Z",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-05T08:08:52.709Z",
 
103
  "body": "The issue has been resolved and there is no performance related slowness on Atlassian Community Forums now.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2025-11-10T04:17:13.505Z",
108
  "resolved_inferred": false,
109
  "started_at": "2025-11-06T19:36:32.503Z",
 
116
  "body": "### Postmortem publish date: Nov 19th, 2025\n\n### Summary\n\nAll dates and times below are in UTC unless stated otherwise.\n\nCustomers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region.\n\nThe incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025.\n\nWe recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust.\n\n### IMPACT\n\nBefore examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies.\n\nProducts such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1.\n\nWhile in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes.\n\nHowever, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It\u2019s important to note that all in-scope application data for supported products is pinned according to a customer\u2019s chosen region.\n\n**Jira**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \\(NLB\\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval.\n\nNormally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers.\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide.\n\n**Jira Service Management \\(JSM\\)**\n\nJSM was impacted similarly to Jira above, with the same timeframes and for the same reasons.\n\nBetween Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts.\n\n**Confluence**\n\nBetween Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively.\n\nThough the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes.\n\nTo protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored.\n\n**Automation**\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution.\n\nDuring this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage.\n\nBy Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage.\n\nBetween Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner.\n\n**Bitbucket and Pipelines**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services.\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers.\n\nFurthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025.\n\n**Trello**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments.\n\n**Login**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access.\n\nThe issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed.\n\n**Statuspage**\n\nBetween Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps.\n\n### REMEDIAL ACTION PLAN & NEXT STEPS\n\nWe have completed the following critical actions designed to help prevent cross-region impact from similar issues:\n\n* Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage.\n* Fixed the issue that prevented timely failover of the identity service which impacted new login sessions.\n* Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages.\n\nAdditionally, we are prioritizing the following improvement actions:\n\n* Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service.\n\nAlthough disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues.\n\nWe recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance.\n\nThanks,\n\nAtlassian Customer Support",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "none",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2025-10-21T05:24:27.129Z",
121
  "resolved_inferred": false,
122
  "started_at": "2025-10-20T07:56:12.455Z",
 
129
  "body": "We have resolved the incident. A new version of the Loom chrome extension has been approved and published to the Chrome Extension store. Update to the latest version(v5.5.142) of the extension.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-10-09T20:00:15.226Z",
134
  "resolved_inferred": false,
135
  "started_at": "2025-10-08T22:20:37.356Z",
 
142
  "body": "We are closing this incident on Statuspage as the Atlassian Support portal functionality has been restored. \n\nWe are aware that the ticket attachments panel remains unavailable and that some customers may be receiving a 'Something went wrong!' error message despite successfully uploading ticket attachments. We are working to resolve these UX issues. Atlassian Support is available for customers needing further assistance.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "major",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-10-08T02:18:18.900Z",
147
  "resolved_inferred": false,
148
  "started_at": "2025-10-06T01:10:49.669Z",
api/v/atlassian.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "atlassian",
4
  "platform": "statuspage",
5
  "status_url": "https://status.atlassian.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "atlassian",
4
  "platform": "statuspage",
5
  "status_url": "https://status.atlassian.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/authentic8.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "authentic8",
4
  "platform": "status.io",
5
  "status_url": "https://status.authentic8.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
3
  "slug": "authentic8",
4
  "platform": "status.io",
5
  "status_url": "https://status.authentic8.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": false,
9
  "first_watched": "2026-09-04T07:06:16Z",
api/v/auvik.json CHANGED
@@ -3,7 +3,7 @@
3
  "slug": "auvik",
4
  "platform": "statuspage",
5
  "status_url": "https://status.auvik.com",
6
- "last_checked": "2026-09-04T09:06:33Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
@@ -12,7 +12,7 @@
12
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.\n\nWe will provide a Root Cause Analysis (RCA) once it is available.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
- "last_seen": "2026-09-04T09:06:33Z",
16
  "resolved_at": "2026-09-03T08:18:52.526-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T07:12:53.072-04:00",
@@ -25,7 +25,7 @@
25
  "body": "# Service Disruption - Availability Issues on the AU1 Cluster\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 27, 2026 12:20 - UTC \nResolved: Aug 27, 2026 13:15 - UTC\n\n### Customer impact\n\nClients hosted in the AU1 region experienced a temporary interruption of Auvik services. Depending on the client, monitoring, alerting, collector connectivity, and access to the web interface were unavailable for up to approximately one hour.\n\n### Cause\n\nA cascading failure in core platform services caused multiple service components to restart, including a central coordination component. This resulted in widespread client-environment restarts across the AU1 region.\n\n### Effect\n\nAffected client environments became temporarily unavailable while services restarted. The platform recovered automatically. Post-recovery verification confirmed normal service operation.\n\n### Future consideration\\(s\\)\n\n* Continue evaluating resiliency improvements for core service coordination and recovery behavior following large-scale restarts.\n* Continue using post-recovery validation checks to confirm client services return to expected operation after a broad service restart.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
- "last_seen": "2026-09-04T09:06:33Z",
29
  "resolved_at": "2026-08-27T09:30:25.575-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-27T08:46:10.771-04:00",
@@ -38,7 +38,7 @@
38
  "body": "# Service Degradation - Legacy Alerts Notification\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 17, 2026 13:15 - UTC \nResolved: Aug 21, 2026 14:12 - UTC\n\n### Customer impact\n\nSome customers using Legacy Alerts experienced inaccurate alert notifications, including false-positive alerts and unintended email notifications. During remediation, some legacy alert processing was delayed, and alert visibility in the user interface temporarily lagged. V2 Alerts remained operational throughout the incident.\n\n### Cause\n\nA product release intended to retire older default Legacy Alert configurations for new environments also removed supporting alert conditions that were still required by some existing customers with customized Legacy Alerts. Without the complete conditions, certain Legacy Alerts could trigger inaccurately. The remediation required reprocessing affected alerts, which temporarily increased processing load and contributed to delayed alert visibility, alert flapping, and excessive notifications.\n\n### Effect\n\nAffected Legacy Alerts could trigger when the underlying condition was not present, re-trigger after being paused, or send notifications more broadly than intended. The resulting in-service lag also temporarily delayed displaying some alerts. Engineering restored the required alert configuration, removed the unintended broad email association, increased processing capacity, and proactively corrected additional affected customer environments.\n\n### Future consideration\\(s\\)\n\n\u2022 Add monitoring for abnormal volumes of Legacy Alerts so unexpected alert activity can be detected earlier.\n\n\u2022 Expand pre-release and end-to-end testing for existing customized Legacy Alerts, including alert triggering, notification delivery, and post-change recovery behavior.\n\n\u2022 Strengthen canary-release review so alerting anomalies are investigated and understood before wider deployment.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
- "last_seen": "2026-09-04T09:06:33Z",
42
  "resolved_at": "2026-08-20T10:11:24.839-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-17T13:53:50.634-04:00",
@@ -51,7 +51,7 @@
51
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.\n\nWe will provide a Root Cause Analysis (RCA) once it is available.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
- "last_seen": "2026-09-04T09:06:33Z",
55
  "resolved_at": "2026-08-17T12:42:43.026-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-17T11:00:40.735-04:00",
@@ -64,7 +64,7 @@
64
  "body": "# Service Disruption - SNMPv3 Monitoring Loss Following Collector Upgrade\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Apr 13, 2026 20:00 - UTC \nResolved: Apr 13, 2026 22:32 - UTC\n\n### Customer impact\n\nCustomers experienced a loss of monitoring data from only devices using specific SNMPv3 configurations. While devices remained online and reachable, monitoring data was not collected, resulting in reduced visibility across environments.\n\n### Cause\n\nA recent collector upgrade introduced changes to encryption handling that affected support for certain legacy SNMPv3 configurations. This resulted in failures when attempting to collect data from devices configured that way.\n\n### Effect\n\nMonitoring data collection failed for affected devices across multiple clusters. This led to a noticeable drop in available device metrics and visibility, despite no loss of connectivity to the devices themselves.\n\n### Future consideation\\(s\\)\n\n* Expand test coverage to include a broader range of SNMP configurations\n* Improve monitoring to detect drops in data collection more proactively\n* Strengthen validation processes for major upgrades and dependency changes\n* Implement additional safeguards to identify compatibility issues prior to release",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
- "last_seen": "2026-09-04T09:06:33Z",
68
  "resolved_at": "2026-04-13T22:33:40.666-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-04-13T20:32:11.502-04:00",
@@ -77,7 +77,7 @@
77
  "body": "# Service Degraded - Some Customers Experiencing Login Issues After Maintenance\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Mar 7, 2026 18:42 - UTC \nResolved: Mar 9, 2026 21:10 - UTC\n\n### Cause\n\nFollowing a platform upgrade, an internal reconciliation process incorrectly identified a subset of user records as deleted. This occurred due to an error condition in a synchronization component that failed to process all expected user data during reconciliation.\n\n### Effect\n\nAffected users were able to log in to the platform but were unable to access their expected sites or tenants due to missing user authorizations. In some cases, API access using previously generated API keys was also affected.\n\nMonitoring, alerting, and data collection services continued to function normally throughout the incident.\n\n### Action taken\n\nEngineering paused the process that spreads the changes across the platform to prevent further impact.\n\nUser access was then restored using backup data taken prior to the upgrade. This allowed the team to recover user access, permissions, and related access keys.\n\nAfter restoration was completed and access was verified across all environments, the incident was declared resolved.\n\n### Future consideration\\(s\\)\n\n* Implement additional monitoring to detect unexpected changes in user or authorization records.\n* Add safeguards within reconciliation processes to prevent large-scale unintended deletions.\n* Improve post-upgrade validation checks to identify abnormal record changes earlier.\n* Enhance disaster recovery tooling and backup retrieval processes to speed up restoration efforts.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
- "last_seen": "2026-09-04T09:06:33Z",
81
  "resolved_at": "2026-03-09T17:26:06.121-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-03-08T15:10:43.417-04:00",
@@ -90,7 +90,7 @@
90
  "body": "# Service Disruption - The EU2 cluster was unavailable \n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Dec 15, 2025 20:00 \u2013 UTC \nResolved: Dec 16, 2025 02:00 \u2013 UTC\n\n### Customer impact\n\nDuring the incident window, customers hosted in the EU2 region experienced intermittent service degradation. This included slower system responsiveness, temporary inconsistencies in monitoring data, and brief periods where alerts may have been delayed or inaccurate. \nMost customers regained access as services were progressively restored, and complete stability was confirmed before the incident was closed.\n\n### Cause\n\nThe incident was caused by an elevated load in the EU2 service environment, resulting in an uneven workload distribution across backend resources. As the load increased, automated recovery mechanisms were unable to stabilize the environment fully, necessitating a controlled restart of the regional service to restore normal operations.\n\n### Effect\n\nThe imbalance led to reduced service performance and temporary unavailability for some customers until recovery actions were completed. Engineering teams were required to intervene to safely restart the affected region and validate service health before returning operations to normal.\n\n### Future consideation\\(s\\)\n\n* Improve automated workload balancing to absorb regional load increases.\n* Strengthen early indicators for backend saturation to enable earlier intervention.\n* Refine operational procedures to further reduce recovery time in similar scenarios.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
- "last_seen": "2026-09-04T09:06:33Z",
94
  "resolved_at": "2025-12-15T20:57:36.921-05:00",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-15T18:28:18.629-05:00",
@@ -103,7 +103,7 @@
103
  "body": "# Service Degraded - Duplicated Devices for Meraki Switch Stacks\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Dec 15, 2025 08:34 \u2013 UTC \nResolved: Dec 15, 2025 13:20 \u2013 UTC\n\n### Customer impact\n\nCustomers with Meraki switch stacks across all clusters experienced: \nDuplicate Meraki switches are appearing in the device inventory, including entries without management IP addresses. \nInability to manually delete duplicates, as they were automatically recreated. \nConfusing or inaccurate device and stack representations. \nTemporary inflation of billable device counts for some tenants \\(billing data captured and under review\\). \nNo other device types were affected.\n\n### Cause\n\nA configuration update intended to improve how Meraki switch stacks are represented in the platform caused unintended behavior. \nFor tenants already using Meraki stacking, the system was unable to match newly processed stack data to existing switches consistently. This caused already-stacked switches to be incorrectly interpreted as new devices, generating duplicate inventory entries. Because the underlying synchronization logic reinforced these entries, any customer deletion of duplicates did not persist, and duplicates reappeared.\n\n### Effect\n\nThe issue led to inaccurate device inventories and misleading switch-stack views for customers using Meraki stacking, causing confusion in device management and increasing support tickets. Internal teams experienced additional operational overhead as they investigated the duplication patterns and validated safe removal procedures. Complete remediation required coordinated cleanup across all clusters to restore accurate device records and ensure no further duplicates were generated.\n\n### Future consideration\\(s\\)\n\n* Strengthen validation of device and stack metadata before inventory updates.\n* Improve testing coverage using a production-like stacked device configuration.\n* Add monitoring and alerting for abnormal changes in device counts.\n* Use safer rollout controls and feature flags for changes affecting device inventory logic.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
- "last_seen": "2026-09-04T09:06:33Z",
107
  "resolved_at": "2025-12-15T13:23:04.412-05:00",
108
  "resolved_inferred": false,
109
  "started_at": "2025-12-15T09:35:29.220-05:00",
@@ -116,7 +116,7 @@
116
  "body": "# Service Degraded - FortiGate firewalls duplicated in the EU2 cluster, causing a flood of alerts.\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Dec 11, 2025 14:00 \u2013 UTC \nResolved: Dec 17, 2025 06:45 \u2013 UTC\n\n### Customer impact\n\nClients with FortiGate firewalls in the EU2 region experienced:\n\n* A significant increase in \u201cdevice offline\u201d alerts due to status flapping between duplicate and original device entries.\n* Duplicate firewalls appear in inventory views, leading to confusion in device management.\n* Inaccurate device statistics and monitoring gaps.\n* In some cases, customers attempted to delete duplicates, which resulted in the loss of historical data on the original device.\n\nNo other device types or regions were affected.\n\n### Cause\n\nA system change intended to improve how high-availability firewall configurations were processed introduced unexpected behavior. Under certain conditions, the platform was unable to detect when multiple records referenced the same firewall device consistently. As a result, some firewalls were incorrectly detected as new devices, causing duplicate entries and inconsistent operational status reporting.\n\n### Effect\n\nThe issue resulted in elevated alert volumes across impacted tenants and caused instability in device-status reporting for the affected firewalls. Customers experienced increased operational overhead as they reviewed unexpected alerts and duplicate device entries, and engineering teams were required to intervene to restore accurate device associations and remove the duplicated records.fFuture consideration\\(s\\)\n\n* Strengthen validation of device-supplied information before it affects inventory or monitoring.\n* Implement alerting for sudden spikes in offline/online transitions to detect similar issues earlier.\n* Improve observability of device lifecycle behavior to identify anomalies proactively.\n* Use feature-flagged or staged rollouts for changes that affect device processing logic.\n* Incorporate production-like data into pre-deployment testing to better anticipate unexpected device behaviors.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
- "last_seen": "2026-09-04T09:06:33Z",
120
  "resolved_at": "2025-12-11T18:46:29.027-05:00",
121
  "resolved_inferred": false,
122
  "started_at": "2025-12-11T09:30:41.924-05:00",
@@ -129,7 +129,7 @@
129
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.\n\nWe appreciate your understanding and patience.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
- "last_seen": "2026-09-04T09:06:33Z",
133
  "resolved_at": "2025-12-05T08:32:57.269-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2025-12-05T07:50:30.000-05:00",
@@ -142,7 +142,7 @@
142
  "body": "Latest update from Okta\nIncident Resolved\n\nDecember 3, 2025 at 8:58am PST\n\nAn issue impacting the core authentication service for customers in Okta Cell US7 has been resolved. Additional root cause information will be available within five business days.\n\nWe will close the status page for Auvik's sites.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
- "last_seen": "2026-09-04T09:06:33Z",
146
  "resolved_at": "2025-12-03T12:28:00.389-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2025-12-03T09:21:09.865-05:00",
@@ -155,7 +155,7 @@
155
  "body": "# Service Degraded - Data Not Loading Across All Clusters\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Nov 21, 2025 17:43 \u2013 UTC \nResolved: Nov 21, 2025 19:18 \u2013 UTC\n\n### Customer impact\n\nCustomers across all regions were able to log in, but many were unable to view key data within the platform. This included features such as:\n\n* Network maps\n* Inventory and site lists\n* Dashboards\n* Other views are dependent on permissions and hierarchical data.\n\nThis resulted in degraded usability and limited visibility into managed environments.\n\n### Cause\n\nDuring a routine maintenance task intended to clean up older data records, an incorrect piece of information was unintentionally added to the system. This faulty data prevented a core component\u2014responsible for organizing how customer information is displayed in the platform\u2014from functioning correctly.\n\nBecause this component could not run as expected, many areas of the product that rely on structured data \\(such as maps, dashboards, and inventory views\\) were unable to load. This led to widespread service degradation across all clusters.\n\n### Effect\n\nBecause the system could not correctly load the information needed to display customer environments, several parts of the platform were unable to show data. As a result, many users could log in but were unable to see maps, inventory details, site lists, dashboards, or other information they usually rely on. \nThis created a degraded experience across all regions, limiting visibility and making it difficult for customers to perform routine monitoring and management tasks until the issue was resolved.\n\n### Future consideation\\(s\\)\n\n* Introduce stronger validation and safeguards to prevent malformed data from being accepted into critical systems.\n* Improve the resilience of backend services so they fail gracefully rather than entering repeated restart cycles.\n* Implement additional monitoring to provide earlier detection of issues affecting data-loading functions.\n* Enhance internal tools used during maintenance and cleanup activities to reduce the risk of unintentional data corruption.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
- "last_seen": "2026-09-04T09:06:33Z",
159
  "resolved_at": "2025-11-21T14:26:06.441-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-11-21T13:29:10.342-05:00",
@@ -168,7 +168,7 @@
168
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
- "last_seen": "2026-09-04T09:06:33Z",
172
  "resolved_at": "2025-10-20T06:57:38.371-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-10-20T05:51:11.783-04:00",
@@ -181,7 +181,7 @@
181
  "body": "# Service Degraded - Sites have lost settings after maintenance\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Oct 11, 2025 \u2013 12:00 UTC \nResolved: Oct 15, 2025 \u2013 22:00 UTC\n\n### Cause\n\nDuring a scheduled system update, a background maintenance process unintentionally removed reference files used to identify stored site configurations. When affected systems restarted after the update, they were unable to locate those configuration files and temporarily appeared as new, empty sites.\n\nThis occurred because the maintenance process was using outdated information when determining which data to clean up safely. The underlying data remained securely stored, but the missing reference files prevented normal access until they were restored.\n\n### Effect\n\nA subset of tenants across multiple clusters temporarily lost access to their site configurations and appeared as newly created environments. \nCustomers observed missing data and configurations, including previously defined network settings and device details.\n\n### Action taken\n\n_All times are in UTC_\n\n**10/11/2025**\n\n**12:00** \u2013 A scheduled system upgrade began across all clusters.\n\n**15:25** \u2013 The support team received reports from customers that some sites appeared empty or missing data.\n\n**16:00** \u2013 Engineering immediately began investigating and determined this was not related to normal data processing delays.\n\n**10/12/2025**\n\nAdditional reports confirmed that several sites were missing configuration information. The engineering team confirmed that the original data was still securely stored, but was not being correctly loaded by the system.\n\n**10/13/2025**\n\nThe issue was traced to missing metadata files that help identify stored configurations. The engineering team began restoring affected sites using the most recent valid configuration data.\n\nAutomated recovery tools were developed to safely restore additional sites and ensure consistent recovery across all clusters.\n\n**10/14/2025**\n\nEngineering verified that configuration data was fully restored and synchronized across supporting services.\n\nThe recovery process was extended to all remaining sites, with validation steps confirming successful restoration.\n\n**10/15/2025**\n\nFinal recovery efforts for the remaining affected clusters were completed..\n\n**22:00** \u2013 All affected sites were confirmed operational with their configurations restored and verified.\n\n### Future consideration\\(s\\)\n\n* Remove dependency of cleanup processes on outdated cluster data sources.\n* Validate all automated cleanup jobs to ensure they do not operate on production clusters.\n* Implement monitoring for missing or corrupted metadata files before deployments.\n* Enhance post-deployment validation to verify the integrity of configuration data across all clusters.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
- "last_seen": "2026-09-04T09:06:33Z",
185
  "resolved_at": "2025-10-15T13:33:51.847-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-10-15T11:22:07.158-04:00",
@@ -194,7 +194,7 @@
194
  "body": "# Service Disruption - Platform Availability and Login Access \n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Sep 23, 2025 \u2013 17:45- UTC \nResolved: Sep 26, 2025 \u2013 13:58 - UTC\n\n### Customer impact\n\nTenants on the CA1 cluster lost their settings, and Auvik was inaccessible for a time.\n\nIntermittent platform errors and degraded performance for some customers.\n\nA temporary issue prevented certain users from logging in via Okta.\n\nDelays in data synchronization in the EU1 region necessitate restarting the cluster.\n\n### Cause\n\nA configuration update intended for specific tenants was applied globally due to a missing query constraint.\n\nThis caused the deletion of tenant and user records in one cluster, leading to cascading synchronization and workload impacts across other clusters.\n\nAs a result, user data was propagated as deletions to the identity provider, temporarily removing affected user accounts.\n\n### Effect\n\nThe CA1 cluster required restoration from a backup, resulting in the temporary unavailability of some tenant data.\n\n43 tenants and 22 user accounts required manual recreation and verification.\n\nAuthentication failures occurred for affected users due to the removal of identity records.\n\nThe EU1 cluster experienced performance degradation as it processed a large data synchronization backlog.\n\nIncreased load briefly impacted the responsiveness of other clusters\u2019 regional services.\n\n### Future consideration\\(s\\)\n\n* Implement a dry-run and confirmation step in internal tooling to validate production commands before execution.\n* Reinforce the change-management process for improved peer visibility and validation.\n* Expand resource and capacity monitoring to identify anomalies earlier and respond proactively.\n* Revisit release control lifecycle practices to remove obsolete configurations after rollout completion.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
- "last_seen": "2026-09-04T09:06:33Z",
198
  "resolved_at": "2025-09-26T09:58:35.912-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2025-09-23T13:45:56.147-04:00",
@@ -207,7 +207,7 @@
207
  "body": "# Service Degraded - Clients experienced login issues to their site because the URL redirect was not working.\n\n## Root Cause Analysis\n\n \nA recent update led to more traffic than expected, resulting in simultaneous overload of the same systems. This overloaded them, leading to delays and occasional failures when customers tried to log in. Some customers also experienced issues when trying to start new trials.\n\n### Duration of the incident\n\nDiscovered: Sep 17, 2025 13:50 - UTC \nResolved: Sep 18, 2025 21:00 - UTC\n\n### Cause\n\nThe update unintentionally created extra demand on shared systems. As a result, the login process and new trial creation sometimes failed or responded slowly.\n\n### Effect\n\n* Some customers could not log in after entering their password or completing MFA.\n* Occasional slow responses and error messages \\(404/500/502/504\\).\n* New trial sign-ups sometimes failed or were delayed.\n* Internal tools that rely on the same login process also saw intermittent issues.\n\n### Action taken \n\n* Adjusted system settings to reduce pressure on overloaded services.\n* Closely monitored traffic while making changes to keep the service stable.\n* Applied a temporary workaround to allow new trials to be created reliably.\n* Released a fix to stabilize the login redirect process.\n* Made further tuning changes to spread out demand and reduce load.\n* Continued monitoring until the login and sign-up flows were confirmed to be stable.\n\n### Future consideration\\(s\\)\n\n* Reduce reliance on a single system for login and trial flows by distributing the workload across multiple systems..\n* Enhance monitoring to identify login errors and trial creation issues more promptly.\n* Add safeguards to prevent overload, including traffic limits and fallback options.\n* Test updates under heavier load conditions to catch these issues earlier.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
- "last_seen": "2026-09-04T09:06:33Z",
211
  "resolved_at": "2025-09-18T17:00:23.307-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2025-09-17T09:53:56.227-04:00",
@@ -220,7 +220,7 @@
220
  "body": "# Service Degraded - Login and Collector Installation Issues on US3 Cluster\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Sep 10, 2025 13:17 UTC \nResolved: Sep 12, 2025 15:08 UTC\n\n### Cause\n\nTwo separate but overlapping issues contributed to this incident:\n\n* Collector Installation Failures \u2013 Windows collectors were unable to install due to missing service principal credentials on the backend agent server, which prevented successful API calls for subscription data.\n* Login and Redirect Failures \u2013 Following a restart of the US3 frontend, requests for user and tenant data from secondary clusters intermittently failed. This caused login attempts through Okta to hang and product redirects to fail.\n\n### Effect\n\n* Users attempting to log in via Okta were unable to complete authentication and access tenants.\n* Some sites experienced 500 errors when attempting to access dashboards.\n* Windows collector installations via GUI and CLI failed, preventing the deployment of new collectors.\n\n### Action taken\n\n_All times are in UTC_\n\n \n**09/10/2025**\n\n**13:17** \u2013 Users report inability to log in to Auvik Production through Okta.\n\n**13:28** \u2013 Errors in US3 frontend logs identified relating to user/tenant data queries.\n\n**13:37** \u2013 Engineering suspends frontend deployment in the US3 cluster.\n\n**13:39** \u2013 Issues confirmed across secondary clusters; logs analyzed for root cause.\n\n**14:54** \u2013 Identified that the frontend redirect service could not fetch required tenant data; feature flag disabled to restore functionality.\n\n**15:01** \u2013 Engineering confirms that the workaround restores login functionality while monitoring tenant recovery. The incident is resolved on the status page.\n\n**09/12/2025**\n\n**15:08** \u2013 Feature flag re-enabled after system recovery; frontend services reconciled successfully. Incident fully resolved.\n\n### Future consideration\\(s\\)\n\n* Improve validation of service principal credentials to prevent collector installation failures.\n* Enhance monitoring and alerting around login and redirect workflows to detect tenant query failures earlier.\n* Review and refine feature flag rollout procedures to minimize dependency risks and ensure optimal deployment.\n* Continue improving how customer data is distributed across clusters so that queries run more efficiently and reliably, even during high system load or maintenance events.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
- "last_seen": "2026-09-04T09:06:33Z",
224
  "resolved_at": "2025-09-10T13:26:51.000-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2025-09-10T12:43:33.677-04:00",
@@ -233,7 +233,7 @@
233
  "body": "The access issues for clients on the US4 cluster have been fully resolved, and services are operating as expected.\n\nImpact: \nCustomers should no longer experience any related issues. If you continue to experience issues, please report them to Auvik Support.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
- "last_seen": "2026-09-04T09:06:33Z",
237
  "resolved_at": "2025-08-27T19:06:55.799-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2025-08-27T17:30:17.548-04:00",
@@ -246,7 +246,7 @@
246
  "body": "# Service Disruption - Intermittent Availability & Performance Issues Across Multiple Clusters\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 25, 2025 18:00 - UTC \nResolved: Aug 29, 2025 14:00 - UTC\n\n### Cause\n\nA configuration rollout unexpectedly generated a large number of configuration entries, which propagated across tenants. This resulted in excessive background processing and memory pressure in core services. The strain led to degraded performance, instability, and in some cases, brief service crashes across clusters.\n\n### Effect\n\nCustomers experienced:\n\n* Intermittent access and sign-in issues in several regions\n* Slow page loads and missing/delayed alert notifications\n* Errors or gaps in specific dashboard and visualization views\n* Temporary unavailability for a small number of tenants\n\n### Action taken\n\n_All times are in UTC_\n\n**08/25/2025** \n**18:00** \u2014 Rollout halted after error rates increased. \n**19:00** \u2014 Targeted service restarts restored partial availability. \n**22:00** \u2014 Added backend capacity and began controlled rollouts.\n\n**08/26\u201308/28/2025**\n\nContinued staged rollouts with adjusted capacity. \nCleaned up configuration entries for affected tenants. \nTuned resource allocations for read/permissioning services\n\n**08/29/2025**\n\n**14:00** \u2014 All clusters stabilized; monitoring confirmed normal performance.\n\n### Future consideration\\(s\\)\n\n* Enhance autoscaling and resource thresholds for services under heavy background processing.\n* Add scale-aware pre-deployment validation for configuration rollouts.\n* Refine monitoring to surface customer-visible issues earlier.\n* Expand operational runbooks for rollback and tenant recovery.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
- "last_seen": "2026-09-04T09:06:33Z",
250
  "resolved_at": "2025-08-27T10:13:51.026-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2025-08-25T14:32:03.498-04:00",
@@ -259,7 +259,7 @@
259
  "body": "# Performance Degraded - Site dropdown not working for several clusters\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 25, 2025 \u2013 15:40 UTC \nResolved: Aug 25, 2025 \u2013 16:45 UTC\n\n### Cause\n\nA recent system update introduced a change that depended on data not yet available in our production environment. As a result, the site selector \\(drop-down\\) was unable to load correctly, which prevented users from switching between sites until the update was rolled back.\n\n### Effect\n\nCustomers were unable to switch sites in the platform, which limited access to some account information and historical data.\n\n### Action taken\n\n_All times are in UTC_\n\n**08/25/2025**\n\n**15:40** \u2013 Update deployed across production clusters.\n\n**16:17** \u2013 Customer reports received that the site drop-down was not loading.\n\n**16:26** \u2013 Engineering identified the change that introduced the issue.\n\n16**:27** \u2013 Incident declared; response team assembled.\n\n**16:40** \u2013 Deployment was rolled back.\n\n**16:45** \u2013 Service restored; site drop-down working as expected. Incident resolved.\n\n### \nFuture consideration\\(s\\)\n\n* Add extra checks before updates to ensure all required data is available in production.\n* Improve safeguards so that unrelated changes are not deployed together.\n* Build fallback mechanisms to ensure that new features do not impact existing functionality.\n* Strengthen monitoring to detect and alert on similar issues in the future quickly.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
- "last_seen": "2026-09-04T09:06:33Z",
263
  "resolved_at": "2025-08-25T12:58:53.882-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-08-25T12:58:53.838-04:00",
@@ -272,7 +272,7 @@
272
  "body": "# Service Degraded - Clients on the EU1 cluster using V2 alerting are not reviewing device alerts.\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 21, 2025 23:47 - UTC \nResolved: Aug 22, 2025 12:00 - UTC\n\n### Cause\n\nA change to the alert-processing timing logic introduced a defect where time windows did not close properly. This prevented events from being processed promptly, causing alerts to queue up and delaying their delivery to the user interface.\n\n### Effect\n\nCustomers on the EU1 cluster using V2 alerting experienced delays in reviewing device alerts, with some alerts being delayed by up to 12 hours.\n\n### Action taken\n\n_All times are in UTC_\n\n**08/21/2025**\n\n**23:47** \u2013 Alert processing began lagging; backlog started building.\n\n**08/22/2025**\n\n**06:00** \u2013 Incident declared; engineers engaged to investigate.\n\n**12:00** \u2013 Adjustments made to processing pipeline; backlog cleared; all delayed alerts reprocessed; service restored.\n\n### Future consideration\\(s\\)\n\n* Add monitoring for time-window stalls and backlog growth.\n* Expand testing to cover out-of-order and skewed event scenarios.\n* Strengthen rollback plans for all future alert-processing changes.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
- "last_seen": "2026-09-04T09:06:33Z",
276
  "resolved_at": "2025-08-22T06:36:49.497-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2025-08-22T05:32:22.637-04:00",
@@ -285,7 +285,7 @@
285
  "body": "# Performance Degraded - Sites on the EU2 cluster are slow to load\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 20, 2025 09:27 \u2013 UTC \nResolved: Aug 20, 2025 10:05 \u2013 UTC\n\n### Cause\n\nOne application component handling user requests on EU2 became unhealthy and stopped responding normally.\n\n### Effect\n\nSome EU2 customers experienced slow page loads and intermittent timeouts in the web experience during the incident window. \nAction taken\n\n_All times are in UTC_\n\n**08/20/2025**\n\n**09:27** \u2013 Potential slowness on EU2 reported; investigation initiated.\n\n**09:35** \u2013 Elevated errors observed; incident declared; response team engaged.\n\n**09:45** \u2013 Application components restarted to restore service.\n\n**10:05** \u2013 Service performance restored.\n\n**10:07** \u2013 Validation confirmed recovery; incident closed.\n\n### Future consideration\\(s\\)\n\n* Complete an investigation into the component crash and address any defects found.\n* Enhance monitoring/alerting for rising request latency and timeout errors to detect earlier.\n* Review deployment and health-check safeguards to auto-recover unresponsive components safely.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
- "last_seen": "2026-09-04T09:06:33Z",
289
  "resolved_at": "2025-08-20T10:09:21.589-04:00",
290
  "resolved_inferred": false,
291
  "started_at": "2025-08-20T09:50:24.176-04:00",
@@ -298,7 +298,7 @@
298
  "body": "# Performance Degraded - Clients on the US2 cluster are slow to load\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 19, 2025 \u2013 13:10 UTC \nResolved: Aug 19, 2025 \u2013 15:30 UTC\n\n### Cause\n\nRecent configuration changes to backend data replication caused a surge in database writes. This increased CPU utilization across all clusters, but while other clusters recovered, the US2 database instance did not. The elevated CPU load persisted for over 24 hours, which led to customer-facing slowness when loading sites on the US2 cluster.\n\n### Effect\n\nCustomers on the US2 cluster experienced significantly slower site load times in the Auvik UI. This impacted demos, trials, and production users, resulting in degraded user experience until resolution.\n\n### Action taken\n\n_All times are in UTC_\n\n**08/19/2025**\n\n**13:10** \u2013 Sales reported demo site loading issues on US2.\n\n**13:22** \u2013 Engineering identified elevated CPU usage on the US2 database.\n\n**13:27** \u2013 Investigation into DB performance began.\n\n**13:57** \u2013 Confirmed that US2 had remained at 100% CPU since Aug 18.\n\n**14:25** \u2013 Troubleshooting efforts to recover performance begin.\n\n**14:36** \u2013 Proposal made to scale up resources for the DB.\n\n**15:00** \u2013 Decision made to upgrade the US2 database instance type.\n\n**15:09** \u2013 Database instance size increased.\n\n**15:22** \u2013 Read/write latency returned to normal.\n\n**15:30** \u2013 US2 UI performance confirmed as fully recovered.\n\n### Future consideration\\(s\\)\n\n* Enhance database CPU monitoring alerts to ensure visibility into leading indicators.\n* Improve alerting for customer-impacting issues such as UI slowness.\n* Conduct proactive reviews of cluster resource utilization to identify potential bottlenecks.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
- "last_seen": "2026-09-04T09:06:33Z",
302
  "resolved_at": "2025-08-19T11:30:00.000-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-08-19T11:30:00.000-04:00",
 
3
  "slug": "auvik",
4
  "platform": "statuspage",
5
  "status_url": "https://status.auvik.com",
6
+ "last_checked": "2026-09-04T10:17:20Z",
7
  "last_state": "ok",
8
  "history_backfilled": true,
9
  "first_watched": "2026-09-04T07:06:16Z",
 
12
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.\n\nWe will provide a Root Cause Analysis (RCA) once it is available.",
13
  "first_seen": "2026-09-04T07:06:16Z",
14
  "impact": "critical",
15
+ "last_seen": "2026-09-04T10:17:20Z",
16
  "resolved_at": "2026-09-03T08:18:52.526-04:00",
17
  "resolved_inferred": false,
18
  "started_at": "2026-09-03T07:12:53.072-04:00",
 
25
  "body": "# Service Disruption - Availability Issues on the AU1 Cluster\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 27, 2026 12:20 - UTC \nResolved: Aug 27, 2026 13:15 - UTC\n\n### Customer impact\n\nClients hosted in the AU1 region experienced a temporary interruption of Auvik services. Depending on the client, monitoring, alerting, collector connectivity, and access to the web interface were unavailable for up to approximately one hour.\n\n### Cause\n\nA cascading failure in core platform services caused multiple service components to restart, including a central coordination component. This resulted in widespread client-environment restarts across the AU1 region.\n\n### Effect\n\nAffected client environments became temporarily unavailable while services restarted. The platform recovered automatically. Post-recovery verification confirmed normal service operation.\n\n### Future consideration\\(s\\)\n\n* Continue evaluating resiliency improvements for core service coordination and recovery behavior following large-scale restarts.\n* Continue using post-recovery validation checks to confirm client services return to expected operation after a broad service restart.",
26
  "first_seen": "2026-09-04T07:06:16Z",
27
  "impact": "major",
28
+ "last_seen": "2026-09-04T10:17:20Z",
29
  "resolved_at": "2026-08-27T09:30:25.575-04:00",
30
  "resolved_inferred": false,
31
  "started_at": "2026-08-27T08:46:10.771-04:00",
 
38
  "body": "# Service Degradation - Legacy Alerts Notification\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 17, 2026 13:15 - UTC \nResolved: Aug 21, 2026 14:12 - UTC\n\n### Customer impact\n\nSome customers using Legacy Alerts experienced inaccurate alert notifications, including false-positive alerts and unintended email notifications. During remediation, some legacy alert processing was delayed, and alert visibility in the user interface temporarily lagged. V2 Alerts remained operational throughout the incident.\n\n### Cause\n\nA product release intended to retire older default Legacy Alert configurations for new environments also removed supporting alert conditions that were still required by some existing customers with customized Legacy Alerts. Without the complete conditions, certain Legacy Alerts could trigger inaccurately. The remediation required reprocessing affected alerts, which temporarily increased processing load and contributed to delayed alert visibility, alert flapping, and excessive notifications.\n\n### Effect\n\nAffected Legacy Alerts could trigger when the underlying condition was not present, re-trigger after being paused, or send notifications more broadly than intended. The resulting in-service lag also temporarily delayed displaying some alerts. Engineering restored the required alert configuration, removed the unintended broad email association, increased processing capacity, and proactively corrected additional affected customer environments.\n\n### Future consideration\\(s\\)\n\n\u2022 Add monitoring for abnormal volumes of Legacy Alerts so unexpected alert activity can be detected earlier.\n\n\u2022 Expand pre-release and end-to-end testing for existing customized Legacy Alerts, including alert triggering, notification delivery, and post-change recovery behavior.\n\n\u2022 Strengthen canary-release review so alerting anomalies are investigated and understood before wider deployment.",
39
  "first_seen": "2026-09-04T07:06:16Z",
40
  "impact": "minor",
41
+ "last_seen": "2026-09-04T10:17:20Z",
42
  "resolved_at": "2026-08-20T10:11:24.839-04:00",
43
  "resolved_inferred": false,
44
  "started_at": "2026-08-17T13:53:50.634-04:00",
 
51
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.\n\nWe will provide a Root Cause Analysis (RCA) once it is available.",
52
  "first_seen": "2026-09-04T07:06:16Z",
53
  "impact": "minor",
54
+ "last_seen": "2026-09-04T10:17:20Z",
55
  "resolved_at": "2026-08-17T12:42:43.026-04:00",
56
  "resolved_inferred": false,
57
  "started_at": "2026-08-17T11:00:40.735-04:00",
 
64
  "body": "# Service Disruption - SNMPv3 Monitoring Loss Following Collector Upgrade\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Apr 13, 2026 20:00 - UTC \nResolved: Apr 13, 2026 22:32 - UTC\n\n### Customer impact\n\nCustomers experienced a loss of monitoring data from only devices using specific SNMPv3 configurations. While devices remained online and reachable, monitoring data was not collected, resulting in reduced visibility across environments.\n\n### Cause\n\nA recent collector upgrade introduced changes to encryption handling that affected support for certain legacy SNMPv3 configurations. This resulted in failures when attempting to collect data from devices configured that way.\n\n### Effect\n\nMonitoring data collection failed for affected devices across multiple clusters. This led to a noticeable drop in available device metrics and visibility, despite no loss of connectivity to the devices themselves.\n\n### Future consideation\\(s\\)\n\n* Expand test coverage to include a broader range of SNMP configurations\n* Improve monitoring to detect drops in data collection more proactively\n* Strengthen validation processes for major upgrades and dependency changes\n* Implement additional safeguards to identify compatibility issues prior to release",
65
  "first_seen": "2026-09-04T07:06:16Z",
66
  "impact": "minor",
67
+ "last_seen": "2026-09-04T10:17:20Z",
68
  "resolved_at": "2026-04-13T22:33:40.666-04:00",
69
  "resolved_inferred": false,
70
  "started_at": "2026-04-13T20:32:11.502-04:00",
 
77
  "body": "# Service Degraded - Some Customers Experiencing Login Issues After Maintenance\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Mar 7, 2026 18:42 - UTC \nResolved: Mar 9, 2026 21:10 - UTC\n\n### Cause\n\nFollowing a platform upgrade, an internal reconciliation process incorrectly identified a subset of user records as deleted. This occurred due to an error condition in a synchronization component that failed to process all expected user data during reconciliation.\n\n### Effect\n\nAffected users were able to log in to the platform but were unable to access their expected sites or tenants due to missing user authorizations. In some cases, API access using previously generated API keys was also affected.\n\nMonitoring, alerting, and data collection services continued to function normally throughout the incident.\n\n### Action taken\n\nEngineering paused the process that spreads the changes across the platform to prevent further impact.\n\nUser access was then restored using backup data taken prior to the upgrade. This allowed the team to recover user access, permissions, and related access keys.\n\nAfter restoration was completed and access was verified across all environments, the incident was declared resolved.\n\n### Future consideration\\(s\\)\n\n* Implement additional monitoring to detect unexpected changes in user or authorization records.\n* Add safeguards within reconciliation processes to prevent large-scale unintended deletions.\n* Improve post-upgrade validation checks to identify abnormal record changes earlier.\n* Enhance disaster recovery tooling and backup retrieval processes to speed up restoration efforts.",
78
  "first_seen": "2026-09-04T07:06:16Z",
79
  "impact": "minor",
80
+ "last_seen": "2026-09-04T10:17:20Z",
81
  "resolved_at": "2026-03-09T17:26:06.121-04:00",
82
  "resolved_inferred": false,
83
  "started_at": "2026-03-08T15:10:43.417-04:00",
 
90
  "body": "# Service Disruption - The EU2 cluster was unavailable \n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Dec 15, 2025 20:00 \u2013 UTC \nResolved: Dec 16, 2025 02:00 \u2013 UTC\n\n### Customer impact\n\nDuring the incident window, customers hosted in the EU2 region experienced intermittent service degradation. This included slower system responsiveness, temporary inconsistencies in monitoring data, and brief periods where alerts may have been delayed or inaccurate. \nMost customers regained access as services were progressively restored, and complete stability was confirmed before the incident was closed.\n\n### Cause\n\nThe incident was caused by an elevated load in the EU2 service environment, resulting in an uneven workload distribution across backend resources. As the load increased, automated recovery mechanisms were unable to stabilize the environment fully, necessitating a controlled restart of the regional service to restore normal operations.\n\n### Effect\n\nThe imbalance led to reduced service performance and temporary unavailability for some customers until recovery actions were completed. Engineering teams were required to intervene to safely restart the affected region and validate service health before returning operations to normal.\n\n### Future consideation\\(s\\)\n\n* Improve automated workload balancing to absorb regional load increases.\n* Strengthen early indicators for backend saturation to enable earlier intervention.\n* Refine operational procedures to further reduce recovery time in similar scenarios.",
91
  "first_seen": "2026-09-04T07:06:16Z",
92
  "impact": "minor",
93
+ "last_seen": "2026-09-04T10:17:20Z",
94
  "resolved_at": "2025-12-15T20:57:36.921-05:00",
95
  "resolved_inferred": false,
96
  "started_at": "2025-12-15T18:28:18.629-05:00",
 
103
  "body": "# Service Degraded - Duplicated Devices for Meraki Switch Stacks\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Dec 15, 2025 08:34 \u2013 UTC \nResolved: Dec 15, 2025 13:20 \u2013 UTC\n\n### Customer impact\n\nCustomers with Meraki switch stacks across all clusters experienced: \nDuplicate Meraki switches are appearing in the device inventory, including entries without management IP addresses. \nInability to manually delete duplicates, as they were automatically recreated. \nConfusing or inaccurate device and stack representations. \nTemporary inflation of billable device counts for some tenants \\(billing data captured and under review\\). \nNo other device types were affected.\n\n### Cause\n\nA configuration update intended to improve how Meraki switch stacks are represented in the platform caused unintended behavior. \nFor tenants already using Meraki stacking, the system was unable to match newly processed stack data to existing switches consistently. This caused already-stacked switches to be incorrectly interpreted as new devices, generating duplicate inventory entries. Because the underlying synchronization logic reinforced these entries, any customer deletion of duplicates did not persist, and duplicates reappeared.\n\n### Effect\n\nThe issue led to inaccurate device inventories and misleading switch-stack views for customers using Meraki stacking, causing confusion in device management and increasing support tickets. Internal teams experienced additional operational overhead as they investigated the duplication patterns and validated safe removal procedures. Complete remediation required coordinated cleanup across all clusters to restore accurate device records and ensure no further duplicates were generated.\n\n### Future consideration\\(s\\)\n\n* Strengthen validation of device and stack metadata before inventory updates.\n* Improve testing coverage using a production-like stacked device configuration.\n* Add monitoring and alerting for abnormal changes in device counts.\n* Use safer rollout controls and feature flags for changes affecting device inventory logic.",
104
  "first_seen": "2026-09-04T07:06:16Z",
105
  "impact": "minor",
106
+ "last_seen": "2026-09-04T10:17:20Z",
107
  "resolved_at": "2025-12-15T13:23:04.412-05:00",
108
  "resolved_inferred": false,
109
  "started_at": "2025-12-15T09:35:29.220-05:00",
 
116
  "body": "# Service Degraded - FortiGate firewalls duplicated in the EU2 cluster, causing a flood of alerts.\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Dec 11, 2025 14:00 \u2013 UTC \nResolved: Dec 17, 2025 06:45 \u2013 UTC\n\n### Customer impact\n\nClients with FortiGate firewalls in the EU2 region experienced:\n\n* A significant increase in \u201cdevice offline\u201d alerts due to status flapping between duplicate and original device entries.\n* Duplicate firewalls appear in inventory views, leading to confusion in device management.\n* Inaccurate device statistics and monitoring gaps.\n* In some cases, customers attempted to delete duplicates, which resulted in the loss of historical data on the original device.\n\nNo other device types or regions were affected.\n\n### Cause\n\nA system change intended to improve how high-availability firewall configurations were processed introduced unexpected behavior. Under certain conditions, the platform was unable to detect when multiple records referenced the same firewall device consistently. As a result, some firewalls were incorrectly detected as new devices, causing duplicate entries and inconsistent operational status reporting.\n\n### Effect\n\nThe issue resulted in elevated alert volumes across impacted tenants and caused instability in device-status reporting for the affected firewalls. Customers experienced increased operational overhead as they reviewed unexpected alerts and duplicate device entries, and engineering teams were required to intervene to restore accurate device associations and remove the duplicated records.fFuture consideration\\(s\\)\n\n* Strengthen validation of device-supplied information before it affects inventory or monitoring.\n* Implement alerting for sudden spikes in offline/online transitions to detect similar issues earlier.\n* Improve observability of device lifecycle behavior to identify anomalies proactively.\n* Use feature-flagged or staged rollouts for changes that affect device processing logic.\n* Incorporate production-like data into pre-deployment testing to better anticipate unexpected device behaviors.",
117
  "first_seen": "2026-09-04T07:06:16Z",
118
  "impact": "minor",
119
+ "last_seen": "2026-09-04T10:17:20Z",
120
  "resolved_at": "2025-12-11T18:46:29.027-05:00",
121
  "resolved_inferred": false,
122
  "started_at": "2025-12-11T09:30:41.924-05:00",
 
129
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.\n\nWe appreciate your understanding and patience.",
130
  "first_seen": "2026-09-04T07:06:16Z",
131
  "impact": "minor",
132
+ "last_seen": "2026-09-04T10:17:20Z",
133
  "resolved_at": "2025-12-05T08:32:57.269-05:00",
134
  "resolved_inferred": false,
135
  "started_at": "2025-12-05T07:50:30.000-05:00",
 
142
  "body": "Latest update from Okta\nIncident Resolved\n\nDecember 3, 2025 at 8:58am PST\n\nAn issue impacting the core authentication service for customers in Okta Cell US7 has been resolved. Additional root cause information will be available within five business days.\n\nWe will close the status page for Auvik's sites.",
143
  "first_seen": "2026-09-04T07:06:16Z",
144
  "impact": "minor",
145
+ "last_seen": "2026-09-04T10:17:20Z",
146
  "resolved_at": "2025-12-03T12:28:00.389-05:00",
147
  "resolved_inferred": false,
148
  "started_at": "2025-12-03T09:21:09.865-05:00",
 
155
  "body": "# Service Degraded - Data Not Loading Across All Clusters\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Nov 21, 2025 17:43 \u2013 UTC \nResolved: Nov 21, 2025 19:18 \u2013 UTC\n\n### Customer impact\n\nCustomers across all regions were able to log in, but many were unable to view key data within the platform. This included features such as:\n\n* Network maps\n* Inventory and site lists\n* Dashboards\n* Other views are dependent on permissions and hierarchical data.\n\nThis resulted in degraded usability and limited visibility into managed environments.\n\n### Cause\n\nDuring a routine maintenance task intended to clean up older data records, an incorrect piece of information was unintentionally added to the system. This faulty data prevented a core component\u2014responsible for organizing how customer information is displayed in the platform\u2014from functioning correctly.\n\nBecause this component could not run as expected, many areas of the product that rely on structured data \\(such as maps, dashboards, and inventory views\\) were unable to load. This led to widespread service degradation across all clusters.\n\n### Effect\n\nBecause the system could not correctly load the information needed to display customer environments, several parts of the platform were unable to show data. As a result, many users could log in but were unable to see maps, inventory details, site lists, dashboards, or other information they usually rely on. \nThis created a degraded experience across all regions, limiting visibility and making it difficult for customers to perform routine monitoring and management tasks until the issue was resolved.\n\n### Future consideation\\(s\\)\n\n* Introduce stronger validation and safeguards to prevent malformed data from being accepted into critical systems.\n* Improve the resilience of backend services so they fail gracefully rather than entering repeated restart cycles.\n* Implement additional monitoring to provide earlier detection of issues affecting data-loading functions.\n* Enhance internal tools used during maintenance and cleanup activities to reduce the risk of unintentional data corruption.",
156
  "first_seen": "2026-09-04T07:06:16Z",
157
  "impact": "minor",
158
+ "last_seen": "2026-09-04T10:17:20Z",
159
  "resolved_at": "2025-11-21T14:26:06.441-05:00",
160
  "resolved_inferred": false,
161
  "started_at": "2025-11-21T13:29:10.342-05:00",
 
168
  "body": "The incident has been fully resolved, and all services are operating normally.\n\nCustomers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.",
169
  "first_seen": "2026-09-04T07:06:16Z",
170
  "impact": "minor",
171
+ "last_seen": "2026-09-04T10:17:20Z",
172
  "resolved_at": "2025-10-20T06:57:38.371-04:00",
173
  "resolved_inferred": false,
174
  "started_at": "2025-10-20T05:51:11.783-04:00",
 
181
  "body": "# Service Degraded - Sites have lost settings after maintenance\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Oct 11, 2025 \u2013 12:00 UTC \nResolved: Oct 15, 2025 \u2013 22:00 UTC\n\n### Cause\n\nDuring a scheduled system update, a background maintenance process unintentionally removed reference files used to identify stored site configurations. When affected systems restarted after the update, they were unable to locate those configuration files and temporarily appeared as new, empty sites.\n\nThis occurred because the maintenance process was using outdated information when determining which data to clean up safely. The underlying data remained securely stored, but the missing reference files prevented normal access until they were restored.\n\n### Effect\n\nA subset of tenants across multiple clusters temporarily lost access to their site configurations and appeared as newly created environments. \nCustomers observed missing data and configurations, including previously defined network settings and device details.\n\n### Action taken\n\n_All times are in UTC_\n\n**10/11/2025**\n\n**12:00** \u2013 A scheduled system upgrade began across all clusters.\n\n**15:25** \u2013 The support team received reports from customers that some sites appeared empty or missing data.\n\n**16:00** \u2013 Engineering immediately began investigating and determined this was not related to normal data processing delays.\n\n**10/12/2025**\n\nAdditional reports confirmed that several sites were missing configuration information. The engineering team confirmed that the original data was still securely stored, but was not being correctly loaded by the system.\n\n**10/13/2025**\n\nThe issue was traced to missing metadata files that help identify stored configurations. The engineering team began restoring affected sites using the most recent valid configuration data.\n\nAutomated recovery tools were developed to safely restore additional sites and ensure consistent recovery across all clusters.\n\n**10/14/2025**\n\nEngineering verified that configuration data was fully restored and synchronized across supporting services.\n\nThe recovery process was extended to all remaining sites, with validation steps confirming successful restoration.\n\n**10/15/2025**\n\nFinal recovery efforts for the remaining affected clusters were completed..\n\n**22:00** \u2013 All affected sites were confirmed operational with their configurations restored and verified.\n\n### Future consideration\\(s\\)\n\n* Remove dependency of cleanup processes on outdated cluster data sources.\n* Validate all automated cleanup jobs to ensure they do not operate on production clusters.\n* Implement monitoring for missing or corrupted metadata files before deployments.\n* Enhance post-deployment validation to verify the integrity of configuration data across all clusters.",
182
  "first_seen": "2026-09-04T07:06:16Z",
183
  "impact": "minor",
184
+ "last_seen": "2026-09-04T10:17:20Z",
185
  "resolved_at": "2025-10-15T13:33:51.847-04:00",
186
  "resolved_inferred": false,
187
  "started_at": "2025-10-15T11:22:07.158-04:00",
 
194
  "body": "# Service Disruption - Platform Availability and Login Access \n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Sep 23, 2025 \u2013 17:45- UTC \nResolved: Sep 26, 2025 \u2013 13:58 - UTC\n\n### Customer impact\n\nTenants on the CA1 cluster lost their settings, and Auvik was inaccessible for a time.\n\nIntermittent platform errors and degraded performance for some customers.\n\nA temporary issue prevented certain users from logging in via Okta.\n\nDelays in data synchronization in the EU1 region necessitate restarting the cluster.\n\n### Cause\n\nA configuration update intended for specific tenants was applied globally due to a missing query constraint.\n\nThis caused the deletion of tenant and user records in one cluster, leading to cascading synchronization and workload impacts across other clusters.\n\nAs a result, user data was propagated as deletions to the identity provider, temporarily removing affected user accounts.\n\n### Effect\n\nThe CA1 cluster required restoration from a backup, resulting in the temporary unavailability of some tenant data.\n\n43 tenants and 22 user accounts required manual recreation and verification.\n\nAuthentication failures occurred for affected users due to the removal of identity records.\n\nThe EU1 cluster experienced performance degradation as it processed a large data synchronization backlog.\n\nIncreased load briefly impacted the responsiveness of other clusters\u2019 regional services.\n\n### Future consideration\\(s\\)\n\n* Implement a dry-run and confirmation step in internal tooling to validate production commands before execution.\n* Reinforce the change-management process for improved peer visibility and validation.\n* Expand resource and capacity monitoring to identify anomalies earlier and respond proactively.\n* Revisit release control lifecycle practices to remove obsolete configurations after rollout completion.",
195
  "first_seen": "2026-09-04T07:06:16Z",
196
  "impact": "major",
197
+ "last_seen": "2026-09-04T10:17:20Z",
198
  "resolved_at": "2025-09-26T09:58:35.912-04:00",
199
  "resolved_inferred": false,
200
  "started_at": "2025-09-23T13:45:56.147-04:00",
 
207
  "body": "# Service Degraded - Clients experienced login issues to their site because the URL redirect was not working.\n\n## Root Cause Analysis\n\n \nA recent update led to more traffic than expected, resulting in simultaneous overload of the same systems. This overloaded them, leading to delays and occasional failures when customers tried to log in. Some customers also experienced issues when trying to start new trials.\n\n### Duration of the incident\n\nDiscovered: Sep 17, 2025 13:50 - UTC \nResolved: Sep 18, 2025 21:00 - UTC\n\n### Cause\n\nThe update unintentionally created extra demand on shared systems. As a result, the login process and new trial creation sometimes failed or responded slowly.\n\n### Effect\n\n* Some customers could not log in after entering their password or completing MFA.\n* Occasional slow responses and error messages \\(404/500/502/504\\).\n* New trial sign-ups sometimes failed or were delayed.\n* Internal tools that rely on the same login process also saw intermittent issues.\n\n### Action taken \n\n* Adjusted system settings to reduce pressure on overloaded services.\n* Closely monitored traffic while making changes to keep the service stable.\n* Applied a temporary workaround to allow new trials to be created reliably.\n* Released a fix to stabilize the login redirect process.\n* Made further tuning changes to spread out demand and reduce load.\n* Continued monitoring until the login and sign-up flows were confirmed to be stable.\n\n### Future consideration\\(s\\)\n\n* Reduce reliance on a single system for login and trial flows by distributing the workload across multiple systems..\n* Enhance monitoring to identify login errors and trial creation issues more promptly.\n* Add safeguards to prevent overload, including traffic limits and fallback options.\n* Test updates under heavier load conditions to catch these issues earlier.",
208
  "first_seen": "2026-09-04T07:06:16Z",
209
  "impact": "minor",
210
+ "last_seen": "2026-09-04T10:17:20Z",
211
  "resolved_at": "2025-09-18T17:00:23.307-04:00",
212
  "resolved_inferred": false,
213
  "started_at": "2025-09-17T09:53:56.227-04:00",
 
220
  "body": "# Service Degraded - Login and Collector Installation Issues on US3 Cluster\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Sep 10, 2025 13:17 UTC \nResolved: Sep 12, 2025 15:08 UTC\n\n### Cause\n\nTwo separate but overlapping issues contributed to this incident:\n\n* Collector Installation Failures \u2013 Windows collectors were unable to install due to missing service principal credentials on the backend agent server, which prevented successful API calls for subscription data.\n* Login and Redirect Failures \u2013 Following a restart of the US3 frontend, requests for user and tenant data from secondary clusters intermittently failed. This caused login attempts through Okta to hang and product redirects to fail.\n\n### Effect\n\n* Users attempting to log in via Okta were unable to complete authentication and access tenants.\n* Some sites experienced 500 errors when attempting to access dashboards.\n* Windows collector installations via GUI and CLI failed, preventing the deployment of new collectors.\n\n### Action taken\n\n_All times are in UTC_\n\n \n**09/10/2025**\n\n**13:17** \u2013 Users report inability to log in to Auvik Production through Okta.\n\n**13:28** \u2013 Errors in US3 frontend logs identified relating to user/tenant data queries.\n\n**13:37** \u2013 Engineering suspends frontend deployment in the US3 cluster.\n\n**13:39** \u2013 Issues confirmed across secondary clusters; logs analyzed for root cause.\n\n**14:54** \u2013 Identified that the frontend redirect service could not fetch required tenant data; feature flag disabled to restore functionality.\n\n**15:01** \u2013 Engineering confirms that the workaround restores login functionality while monitoring tenant recovery. The incident is resolved on the status page.\n\n**09/12/2025**\n\n**15:08** \u2013 Feature flag re-enabled after system recovery; frontend services reconciled successfully. Incident fully resolved.\n\n### Future consideration\\(s\\)\n\n* Improve validation of service principal credentials to prevent collector installation failures.\n* Enhance monitoring and alerting around login and redirect workflows to detect tenant query failures earlier.\n* Review and refine feature flag rollout procedures to minimize dependency risks and ensure optimal deployment.\n* Continue improving how customer data is distributed across clusters so that queries run more efficiently and reliably, even during high system load or maintenance events.",
221
  "first_seen": "2026-09-04T07:06:16Z",
222
  "impact": "none",
223
+ "last_seen": "2026-09-04T10:17:20Z",
224
  "resolved_at": "2025-09-10T13:26:51.000-04:00",
225
  "resolved_inferred": false,
226
  "started_at": "2025-09-10T12:43:33.677-04:00",
 
233
  "body": "The access issues for clients on the US4 cluster have been fully resolved, and services are operating as expected.\n\nImpact: \nCustomers should no longer experience any related issues. If you continue to experience issues, please report them to Auvik Support.",
234
  "first_seen": "2026-09-04T07:06:16Z",
235
  "impact": "major",
236
+ "last_seen": "2026-09-04T10:17:20Z",
237
  "resolved_at": "2025-08-27T19:06:55.799-04:00",
238
  "resolved_inferred": false,
239
  "started_at": "2025-08-27T17:30:17.548-04:00",
 
246
  "body": "# Service Disruption - Intermittent Availability & Performance Issues Across Multiple Clusters\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 25, 2025 18:00 - UTC \nResolved: Aug 29, 2025 14:00 - UTC\n\n### Cause\n\nA configuration rollout unexpectedly generated a large number of configuration entries, which propagated across tenants. This resulted in excessive background processing and memory pressure in core services. The strain led to degraded performance, instability, and in some cases, brief service crashes across clusters.\n\n### Effect\n\nCustomers experienced:\n\n* Intermittent access and sign-in issues in several regions\n* Slow page loads and missing/delayed alert notifications\n* Errors or gaps in specific dashboard and visualization views\n* Temporary unavailability for a small number of tenants\n\n### Action taken\n\n_All times are in UTC_\n\n**08/25/2025** \n**18:00** \u2014 Rollout halted after error rates increased. \n**19:00** \u2014 Targeted service restarts restored partial availability. \n**22:00** \u2014 Added backend capacity and began controlled rollouts.\n\n**08/26\u201308/28/2025**\n\nContinued staged rollouts with adjusted capacity. \nCleaned up configuration entries for affected tenants. \nTuned resource allocations for read/permissioning services\n\n**08/29/2025**\n\n**14:00** \u2014 All clusters stabilized; monitoring confirmed normal performance.\n\n### Future consideration\\(s\\)\n\n* Enhance autoscaling and resource thresholds for services under heavy background processing.\n* Add scale-aware pre-deployment validation for configuration rollouts.\n* Refine monitoring to surface customer-visible issues earlier.\n* Expand operational runbooks for rollback and tenant recovery.",
247
  "first_seen": "2026-09-04T07:06:16Z",
248
  "impact": "none",
249
+ "last_seen": "2026-09-04T10:17:20Z",
250
  "resolved_at": "2025-08-27T10:13:51.026-04:00",
251
  "resolved_inferred": false,
252
  "started_at": "2025-08-25T14:32:03.498-04:00",
 
259
  "body": "# Performance Degraded - Site dropdown not working for several clusters\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 25, 2025 \u2013 15:40 UTC \nResolved: Aug 25, 2025 \u2013 16:45 UTC\n\n### Cause\n\nA recent system update introduced a change that depended on data not yet available in our production environment. As a result, the site selector \\(drop-down\\) was unable to load correctly, which prevented users from switching between sites until the update was rolled back.\n\n### Effect\n\nCustomers were unable to switch sites in the platform, which limited access to some account information and historical data.\n\n### Action taken\n\n_All times are in UTC_\n\n**08/25/2025**\n\n**15:40** \u2013 Update deployed across production clusters.\n\n**16:17** \u2013 Customer reports received that the site drop-down was not loading.\n\n**16:26** \u2013 Engineering identified the change that introduced the issue.\n\n16**:27** \u2013 Incident declared; response team assembled.\n\n**16:40** \u2013 Deployment was rolled back.\n\n**16:45** \u2013 Service restored; site drop-down working as expected. Incident resolved.\n\n### \nFuture consideration\\(s\\)\n\n* Add extra checks before updates to ensure all required data is available in production.\n* Improve safeguards so that unrelated changes are not deployed together.\n* Build fallback mechanisms to ensure that new features do not impact existing functionality.\n* Strengthen monitoring to detect and alert on similar issues in the future quickly.",
260
  "first_seen": "2026-09-04T07:06:16Z",
261
  "impact": "none",
262
+ "last_seen": "2026-09-04T10:17:20Z",
263
  "resolved_at": "2025-08-25T12:58:53.882-04:00",
264
  "resolved_inferred": false,
265
  "started_at": "2025-08-25T12:58:53.838-04:00",
 
272
  "body": "# Service Degraded - Clients on the EU1 cluster using V2 alerting are not reviewing device alerts.\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 21, 2025 23:47 - UTC \nResolved: Aug 22, 2025 12:00 - UTC\n\n### Cause\n\nA change to the alert-processing timing logic introduced a defect where time windows did not close properly. This prevented events from being processed promptly, causing alerts to queue up and delaying their delivery to the user interface.\n\n### Effect\n\nCustomers on the EU1 cluster using V2 alerting experienced delays in reviewing device alerts, with some alerts being delayed by up to 12 hours.\n\n### Action taken\n\n_All times are in UTC_\n\n**08/21/2025**\n\n**23:47** \u2013 Alert processing began lagging; backlog started building.\n\n**08/22/2025**\n\n**06:00** \u2013 Incident declared; engineers engaged to investigate.\n\n**12:00** \u2013 Adjustments made to processing pipeline; backlog cleared; all delayed alerts reprocessed; service restored.\n\n### Future consideration\\(s\\)\n\n* Add monitoring for time-window stalls and backlog growth.\n* Expand testing to cover out-of-order and skewed event scenarios.\n* Strengthen rollback plans for all future alert-processing changes.",
273
  "first_seen": "2026-09-04T07:06:16Z",
274
  "impact": "minor",
275
+ "last_seen": "2026-09-04T10:17:20Z",
276
  "resolved_at": "2025-08-22T06:36:49.497-04:00",
277
  "resolved_inferred": false,
278
  "started_at": "2025-08-22T05:32:22.637-04:00",
 
285
  "body": "# Performance Degraded - Sites on the EU2 cluster are slow to load\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 20, 2025 09:27 \u2013 UTC \nResolved: Aug 20, 2025 10:05 \u2013 UTC\n\n### Cause\n\nOne application component handling user requests on EU2 became unhealthy and stopped responding normally.\n\n### Effect\n\nSome EU2 customers experienced slow page loads and intermittent timeouts in the web experience during the incident window. \nAction taken\n\n_All times are in UTC_\n\n**08/20/2025**\n\n**09:27** \u2013 Potential slowness on EU2 reported; investigation initiated.\n\n**09:35** \u2013 Elevated errors observed; incident declared; response team engaged.\n\n**09:45** \u2013 Application components restarted to restore service.\n\n**10:05** \u2013 Service performance restored.\n\n**10:07** \u2013 Validation confirmed recovery; incident closed.\n\n### Future consideration\\(s\\)\n\n* Complete an investigation into the component crash and address any defects found.\n* Enhance monitoring/alerting for rising request latency and timeout errors to detect earlier.\n* Review deployment and health-check safeguards to auto-recover unresponsive components safely.",
286
  "first_seen": "2026-09-04T07:06:16Z",
287
  "impact": "minor",
288
+ "last_seen": "2026-09-04T10:17:20Z",
289
  "resolved_at": "2025-08-20T10:09:21.589-04:00",
290
  "resolved_inferred": false,
291
  "started_at": "2025-08-20T09:50:24.176-04:00",
 
298
  "body": "# Performance Degraded - Clients on the US2 cluster are slow to load\n\n## Root Cause Analysis\n\n### Duration of the incident\n\nDiscovered: Aug 19, 2025 \u2013 13:10 UTC \nResolved: Aug 19, 2025 \u2013 15:30 UTC\n\n### Cause\n\nRecent configuration changes to backend data replication caused a surge in database writes. This increased CPU utilization across all clusters, but while other clusters recovered, the US2 database instance did not. The elevated CPU load persisted for over 24 hours, which led to customer-facing slowness when loading sites on the US2 cluster.\n\n### Effect\n\nCustomers on the US2 cluster experienced significantly slower site load times in the Auvik UI. This impacted demos, trials, and production users, resulting in degraded user experience until resolution.\n\n### Action taken\n\n_All times are in UTC_\n\n**08/19/2025**\n\n**13:10** \u2013 Sales reported demo site loading issues on US2.\n\n**13:22** \u2013 Engineering identified elevated CPU usage on the US2 database.\n\n**13:27** \u2013 Investigation into DB performance began.\n\n**13:57** \u2013 Confirmed that US2 had remained at 100% CPU since Aug 18.\n\n**14:25** \u2013 Troubleshooting efforts to recover performance begin.\n\n**14:36** \u2013 Proposal made to scale up resources for the DB.\n\n**15:00** \u2013 Decision made to upgrade the US2 database instance type.\n\n**15:09** \u2013 Database instance size increased.\n\n**15:22** \u2013 Read/write latency returned to normal.\n\n**15:30** \u2013 US2 UI performance confirmed as fully recovered.\n\n### Future consideration\\(s\\)\n\n* Enhance database CPU monitoring alerts to ensure visibility into leading indicators.\n* Improve alerting for customer-impacting issues such as UI slowness.\n* Conduct proactive reviews of cluster resource utilization to identify potential bottlenecks.",
299
  "first_seen": "2026-09-04T07:06:16Z",
300
  "impact": "none",
301
+ "last_seen": "2026-09-04T10:17:20Z",
302
  "resolved_at": "2025-08-19T11:30:00.000-04:00",
303
  "resolved_inferred": false,
304
  "started_at": "2025-08-19T11:30:00.000-04:00",