Update — additional data points (still stuck, 17+ hours) Update from my side: all five submissions are still "In Progress" as of 2026-08-18 01:00 UTC (the oldest has been pending for ~17.5 hours). Additional data points that might help the diagnosis: The exact same toolchain worked normally 6 days ago. On 2026-08-12 we submitted Nika 1.3.0 (ZIP, 665 MB, ~87k files) via the same electron-builder → @electron/notarize 2.5.0 → notarytool submit path, and it was Accepted in normal time. Same certificate, same team, same machine, same command. This round's submissions carry substantially new content. The 1.3.5 ZIP is 787 MB (~91k files), +18% vs. the 1.3.0 build — mostly new bundled Node dependencies (~45 new npm packages, +122 MB). We realize the notary service may need to learn to recognize this new content, which may explain the in-depth analysis. All five submissions across an 8-hour window are affected simultaneously, including a byte-identical resubmission of the 1.3.1 ZIP (submitted 2 hours after the original, also still In Progress) — consistent with a team-level state rather than per-submission issues. Submission IDs (all still In Progress, oldest first): 99722c12-dc10-4098-88be-84b7b58ff1f4 — submitted 2026-08-17 07:51 UTC a41cf8fe-8883-4073-a043-5143323407da — 09:45 UTC (byte-identical resubmission of the first) 35746a17-d332-4398-a353-cd7b1d8520ac — 11:34 UTC 7cd3dd44-e510-4f68-99cd-7fe56b489140 — 13:36 UTC 87a1a1bf-31c6-4258-beb4-a6606909149e — 16:08 UTC notarytool log returns "Submission log is not yet available" for all of them, so we have nothing further to inspect locally. We're not asking for escalation yet (we understand the guidance is to wait up to a week) — mainly sharing the data points in case the byte-identical-resubmission-also-stuck pattern or the content delta is useful for the team. Happy to provide anything else (Team ID via private channel, the notarytool submit invocation, ZIP manifest, etc.).