Good news: I checked your repo through the public API and the site is not actually stuck. Only one orphaned run is, and it isn't blocking anything.

What the API shows right now

• Pages: build_type: legacy (deploy from main /), status: built, cname: www.innercodesystems.com
• Deployments after the stuck one all completed:
  • 7c54ab9, Nov 2 19:31 UTC: success
  • 8bd86dc, Nov 3 03:21 UTC: success
  • 2c9d8f6, Nov 3 03:27 UTC: success
  • 0d627c1, Nov 3 03:34 UTC: success (this is the current head of main)
• https://www.innercodesystems.com returns 200 with last-modified: Tue, 03 Nov 2026 03:34:55 GMT, which matches that last deploy.

So your latest commit is live.

What happened to run 41288521485

It's the automatic pages build and deployment run (event dynamic) for 2841081. It was created at 09:21 on Nov 1, four minutes after 73038bb failed with the "deployment in progress" 400, and it was never picked up, so it's still queued with no jobs. That's why the two cancel calls contradict each other: one side treats it as finished, the other as never started, so there's nothing for a cancel to act on.

Later pushes create new, independent Pages runs, and they all went through. The orphan doesn't hold a lock.

What to do

1. Nothing is required for the site. Everything since Nov 2 deployed normally.
2. If you want it gone from the Actions list, you can try deleting the run (not cancelling it):

   gh api -X DELETE repos/innercodesystems/ics-auswertungstool/actions/runs/41288521485

   If that's refused too, it's safe to ignore. It's only a display record now.
3. To avoid the original 400: with legacy (branch) publishing, each push starts a Pages build, and pushes a few seconds apart can collide ("another deployment in progress"). Batch your commits, or switch Settings → Pages → Source to GitHub Actions and use the static workflow with concurrency: { group: "pages", cancel-in-progress: false } so deployments queue instead of failing.

There's no need to delete the repository or unpublish the site.