My team has been using Cursor Bugbot on GitHub since March, and we’re currently on a paid plan. It had been working great for PR reviews — automatically reviewing every newly opened PR — until last week, when it suddenly stopped reviewing any PRs at all.
Nobody on our team changed any Bugbot settings, but it completely stopped responding. I checked the configuration, and everything still appears to be set up correctly.
To troubleshoot, I fully disconnected Bugbot from our GitHub org and set everything up again from scratch, but that didn’t resolve the issue. Bugbot still doesn’t appear anywhere, and it doesn’t respond to any commands or mentions. I also tried every “wake up” command I could find in the forums, but there’s still absolutely no response.
I’m pretty confident I configured everything the same way I originally did when it was working properly.
One additional detail: we’re using a self-hosted GitHub Enterprise instance. I’m not sure whether that matters, since Bugbot had been working perfectly fine in this environment before.
Hey, thanks for the report. Bugbot officially supports GitHub Enterprise Server, so it shouldn’t just stop working. This looks like a server-side issue like the GHE App OAuth token, webhook delivery, or something on the instance side. We’ll need to check logs, so please send:
Team ID cursor.com → Dashboard → Settings and your org name in GHE
Your GitHub Enterprise Server version, shown at https:///site-admin
URLs for 1 or 2 PRs where Bugbot should’ve replied but didn’t
A Bugbot request ID from any older comment back when it still worked. It looks like serverGenReqId_…
The rough date and time when it stopped responding so we can find it in the logs
In the Bugbot dashboard cursor.com/dashboard → Bugbot do repos show as enabled after you re-connected everything?
Also on the GHE side, check Settings → Webhooks for the Cursor GitHub App. See if there are recent deliveries after opening a PR and what response code they have. If webhooks aren’t arriving or they return 4xx or 5xx, that’s a big clue.
Hey Jake, thanks for the details, that helps narrow down the possible causes.
Two things stand out right away:
The “no webhooks” line is the key clue. On GHE, Bugbot gets PR events via webhooks that are set up automatically when you install the Cursor GitHub App. If your GHE isn’t sending webhook deliveries for the Cursor App, Bugbot simply can’t know a PR was opened, and that matches what you’re seeing.
A couple common things to check, in order:
Make sure the Cursor App is installed at the organization level, not the enterprise level. GitHub Apps installed at the enterprise account level don’t receive repo activity webhook events at all. They only cover enterprise level events. So even if everything else looks right, installing via the enterprise admin UI means PRs will never trigger Bugbot. The app needs to be installed on the OpenLaw organization where the repos live. Link: Installing a GitHub App on your enterprise - GitHub Enterprise Cloud Docs
Then check App > Advanced > Recent Deliveries on your GHE: Site Admin > All apps > Cursor app / cursor-bugbot. Open a new PR and see if a delivery shows up and what response code it gets. No deliveries means an install or scope issue. 4xx or 5xx means a routing issue on our side.
Your screenshot shows two GHE entries, which is unusual:
OpenLaw (GitHub Enterprise) with 50/50 repositories enabled
cursor-bugbot (git.openlawhq.com) (GitHub Enterprise) with 0 repositories available
Only one of these should map to git.openlawhq.com. The fact that cursor-bugbot (git.openlawhq.com) shows 0 available repos looks like the app installation can’t see any repos, most likely due to permissions or the wrong install scope. Meanwhile, the OpenLaw entry with 50/50 enabled is probably an old or duplicate connection from a previous reconnect attempt, so toggling repos there doesn’t actually bind anything to your self hosted instance. We’ve seen similar routing issues caused by duplicate installs, for example:
Open the OpenLaw entry. What host does it actually point to, and do the listed repos look like the real repos on git.openlawhq.com or something else?
On the GHE side, confirm the Cursor GitHub App is installed on the OpenLaw organization, not at the enterprise level, with access to the repos that have PRs
Check Recent Deliveries on the app right after opening a fresh PR
Once we know which entry is the live one, and whether the app is installed in the right scope, we can clean up the duplicate on our side if needed.
I tried uninstalling all the Bugbot installations we had and started over from scratch.
I believe the Cursor app is now installed at the organization level. I also cleared out the duplicate installation and confirmed that there is now only one Cursor Bugbot installed in our GitHub organization.
I believe it is now pointing to git.openlawhq.com, and all the repositories displayed are valid repositories in our org.
I’ve attached a screenshot showing this as well.
For some reason, I still don’t see any webhooks that were set up before or after the installation. I’ve attached a screenshot for that too.
Please let me know if there’s anything else I should check on my end.
@Jake_Wang nice progress on cleaning up duplicates and setting it up at the org level. But the webhooks screenshot isn’t showing what we need.
What you opened Site admin / OpenLaw / Security / Webhooks is the org-level webhooks page for the OpenLaw org. It’s normal that you only see the Slack hook there. GitHub App webhooks don’t show up on this page. Each GitHub App has its own webhook endpoint, and you configure and view it inside the App, not at the org level.
Since your Cursor Enterprise app is custom (created on your GHE as a self-hosted setup), please check here:
App settings > General: open the App page itself, then scroll to the Webhook section:
Is Active checked?
What Webhook URL is set? It should point to the Cursor endpoint you were given during the original self-hosted integration setup. If it’s empty or points somewhere else, that’s why events aren’t being sent.
Is there a Webhook secret set?
App settings > Advanced > Recent Deliveries: open a fresh PR in any of the 50 enabled repos and then check this page.
Quick signal: if you don’t see the Recent Deliveries section at all on the Advanced page, it means the App webhook isn’t enabled (Active is off or the URL is empty). This section only shows up when the webhook is active.
If the section exists but there are no deliveries after opening a PR, the App isn’t subscribed to the right events.
If deliveries exist, check the response code (200 vs 4xx vs 5xx).
Send a screenshot of the Webhook block from the App General page and the Advanced page (with or without Recent Deliveries). That’s enough to pinpoint where it’s breaking.
I don’t see any recent deliveries. I have tried to open a new PR after reinstallation.
4. The events we have subscribed seems all right to me, especially Pull Request is selected
@Jake_Wang thanks for the screenshots, things are clearer now. The App config looks correct: Active is enabled, the URL is right, and the events are selected. But if Recent Deliveries is completely empty even after opening a new PR, that means GHE itself is not dispatching events to this webhook. On the Cursor side we don’t receive anything because nothing is being sent.
Most often it’s one of these two things. Can you check them in order:
Pending approval on the installation after a permissions change
In your Permissions & events screenshot there is a yellow warning at the bottom saying Current users will be prompted to accept these changes. If permissions or events were changed at some point, the existing installation keeps using the old set of events until the owner explicitly approves the update. From the official GitHub docs: “Updated permissions won’t take effect on an installation or user authorization until the new permissions are approved.” Go to:
App settings > Install App and find the installation on the OpenLaw org
If you see a “Review permissions” or “Accept new permissions” banner, accept it
Also check the email inboxes of the OpenLaw org owners. GHE emails each owner to request approval when permissions change. They can approve from the email link too.
Make sure Repository permissions has Pull requests: Read or Read & write. Subscribing to the Pull request event won’t work without this permission. GHE will silently not send events.
Install scope, which repo the App is actually installed on
Open App settings > Install App > Configure next to OpenLaw:
Is it set to All repositories or Selected repositories?
If it’s Selected, does it include the repo where you opened the test PR openlaw-web-app?
If the repo isn’t in the installation scope, a PR in that repo won’t trigger the webhook, even if events are configured correctly.
After you fix either of the above, open a new PR and then refresh Advanced > Recent Deliveries right away. If at least one delivery shows up, even with a 4xx or 5xx, we can dig into it on our side based on the response code. If it’s still empty, that’s a clear sign GHE does not consider that PR an event for the App. Then the last step is: Site Admin > Monitor or Manage GitHub Enterprise > Diagnostics and check the global webhook deliveries queue or Hookshot to see if it’s stuck.
For some reason, Bugbot came back online last night without me making any of the changes mentioned in your last message.
I also checked the recent deliveries and can see a number of events being processed successfully with 200 responses, so I believe the issue has been resolved.
Thank you so much for your time and help investigating this issue.
I do have one additional question. Since we were unable to use Bugbot starting around May 12th, while continuing to pay for our monthly subscription, my team was wondering whether there might be any opportunity for a prorated refund or account credit for the period during which the service was unavailable to us.
I completely understand if there are policies around this, but I wanted to check and see what options might be available.
Thank you again for all your help again, and I look forward to hearing from you.
Glad to hear Bugbot is back online and you’re seeing successful 200 deliveries now. Sometimes GHE’s webhook dispatch queue can get stuck, and it clears itself after the install and permissions settings are fixed, so the cleanup you did likely helped it recover.
For a prorated refund or account credit, our team at [email protected] can help. They can review your specific case and let you know what options are available.
Feel free to reopen this thread if Bugbot acts up again on the GHE side.
