When delivery happens
Immediately after the report is stored, and never before. The reporter's browser gets its confirmation the moment the row is saved; filing the issue runs after that response has been sent, so nothing about GitHub is on the reporter's critical path.
That ordering is the point. A person reporting a bug on your site must never wait on GitHub, and must never get a different answer because GitHub was slow, rate-limited, unreachable, or holding a credential that has since been revoked. The report is already safe before delivery is attempted.
A delivery GitHub refuses is written to the report's delivery log with the reason GitHub gave, the error surfaces on the integration settings page, and you can retry it from the report itself. The report itself is stored before delivery is ever attempted, so it is never lost and never needs re-reporting — even in the rarer case where BugLoop cannot reach its own database to record the attempt, which is logged on our side rather than shown on the report.
What you need
A fine-grained personal access token scoped to the single repository you want issues filed in, with the repository permission "Issues" set to Read and write. Nothing else. A classic token with repo scope also works but grants far more than BugLoop needs.
Connecting
In your project, open Integrations → GitHub. Enter the repository owner and name, paste the token, and optionally add labels and assignees to apply to every issue.
Save, then use Test connection. BugLoop performs a real authenticated read of the repository and tells you what it found, so you know the credential works before a visitor depends on it.
What the issue looks like
The title is the visitor's summary, prefixed with the feedback type. The body contains the description, the steps to reproduce if given, every custom field with its label, and a context block: page URL, page title, viewport, browser user agent, timestamp, and the reporter's email if they left one.
Duplicate protection
GitHub has no idempotency key on issue creation, so BugLoop enforces it on our side. Each feedback-and-destination pair gets a deterministic key with a unique index behind it. A retry, a double-click, or two concurrent workers can only ever produce one issue.
The Retry button is held to the same standard. A delivery that is still being attempted cannot be retried at all — that window is exactly where a double-file would come from — and two retries that arrive together are settled by a conditional write, so one proceeds and the other is told the delivery is already spoken for.
When it fails
A failed delivery never fails the visitor's submission — they already saw "thanks", and the report is safely stored. The delivery is marked failed with the reason, the error surfaces on the integration settings page, and you can retry it from the report itself once the underlying problem is fixed.