Team ID: RSNGKW5LNH I have a matched pair submitted seconds apart that I cannot explain, and I think it shows a service-side problem rather than one in my bundle. Submission Contents Result 359b004e-ccd2-4ab0-a02e-0516b5598b75 a signed Node binary + 2,000 identical one-line text files In Progress for 36+ minutes e4abe4b5-8829-47fb-aa1c-6a79d6824094 the same signed Node binary + a full 7,900-file npm dependency tree Accepted in 87 seconds Both created 2026-08-13 at 05:40Z, submitted in the same loop, same signing, same ditto -c -k --keepParent, same notarytool invocation. The trivial one hung; the complex one cleared. The first fixture is as innocuous as a submission gets — one Developer ID signed Node binary and 2,000 copies of a file whose entire content is // inert fixture stub. I can regenerate it from a script and share it. Eight of fifteen submissions tonight are still In Progress, the oldest at 78 minutes, spanning every shape I tried: with and without the dependency tree, with and without a signed binary, plain and encrypted inner archives, 11MB to 60MB, high-entropy and trivially compressible. WWDC21 session 10261 states a commitment to 15 minutes for 98% of submissions. WWDC21 session 10261 says Apple is "committed to completing this process within 15 minutes for 98 percent of Notary submissions, and most complete in under five." My cleared submissions match that — 19 to 113 seconds. The affected ones ran past five hours and were then deleted. I ran a 21-submission bisection with a decision rule fixed in advance (still In Progress at 10 minutes = hung; in practice the results were bimodal, with nothing at all between 113 seconds and 36 minutes). Each fixture differed from its neighbour by one property. Cleared, and so exonerated: the submission channel (31s), byte volume (108MB Node runtime alone, 44s), the Mach-O binaries themselves (9.9MB esbuild alone, 19s), file count (11,001 stubs, 110s), the name node_modules (108s), @-scoped directories, nesting depth, and directory count. Still hung after: pruning unused files, dereferencing all 222 symlinks, flattening the tree, and sealing it inside an inner zip. Two things make me think this is not a signing mistake on my side. First, a matched pair. A fixture containing an unsigned binary nested inside an inner zip came back Invalid in 113 seconds, with the log naming the offending path three times. Its pair — same layout, submitted two minutes later, differing only in that the nested binary was signed — has never returned anything. When the notary has something to say it says it quickly and precisely, and it descends into nested archives. Second, the stuck submissions are deleted. Seven were confirmed In Progress at 2026-08-12T07:13:12Z. Re-queried 21–26 hours later, all seven return "Submission does not exist or does not belong to your team" and none appears in notarytool history, while submissions from the same minutes under the same credentials still resolve — a978eb1f-d781-4fdc-9295-88540a37a504 (05:49:24Z) still returns Accepted; f991e71b-742e-4a7d-a47c-48809a60b321 (05:10:08Z) is gone. Two questions: Can anyone see what is happening to 359b004e-ccd2-4ab0-a02e-0516b5598b75? Given what is in it, I do not think there is anything in the archive to find, and its same-batch pair completing in 87 seconds suggests the service was healthy at that moment. Happy to provide the generating script, digests, or the full fifteen-submission ledger. Should a submission that cannot be processed disappear rather than reaching a terminal state? As it stands there is no way to tell "queued" from "will never complete," and the ids needed to report it expire before a support cycle finishes. The submission above is not my app — it is a fixture generated by a script, containing only my own JavaScript files and no Mach-O at all. I can describe its contents exactly, and regenerate it on request. I also have matched fixtures that differ only in directory naming, and a variant sealed inside an encrypted inner archive, if any of those would help narrow it.