A single visitor report traced upward until it meets one highlighted line of registered source

Website report investigation

Turn each website report into a source-backed next step.

Give visitors a short report form. Review safe browser evidence, source citations, unknown facts, and one recommended action before you respond or change production.

No card. One website. Three investigations each month.

Free plan
US$0
Websites
1
Investigations each month
3
Screenshot retention
7 days

01 Fixed evidence limits

Useful context without an open collection switch.

Website settings can disable a category. They cannot add fields or enable private browser-state values.

  • 01

    Approved screenshotThe visitor starts the capture, sees a preview, and approves inclusion.

  • 02

    Console errorsOnly bounded errors and warnings pass through a second redaction step.

  • 03

    Request metadataFailed or slow requests include a method, safe path, status, duration, and time.

  • 04

    Browser-state metadataCookies, forms, and local storage include a name, presence state, and size. Values never enter the report.

Bounded evidence categories layered as separate planes that converge into one review
Each category stays bounded and separate.

02 Human review

Every response and production change waits for a person.

IssueProbe prepares one draft response and one recommended action. The website owner edits, approves, and decides what reaches a visitor or production.

  • 01

    Separate result partsEvidence citations, the conclusion, unknown facts, and the next action stay distinct.

  • 02

    Exact source citationsEach source claim names the registered repository revision, path, and line range.

  • 03

    No visitor messageIssueProbe never sends the draft. A human copies it after review.

A visitor report and source evidence meeting at one calm owner decision
One decision line, held by the owner.

The widget a visitor sees

Three steps from the report to the send action.

These are real captures of the widget on a website. A visitor opens the launcher, describes the problem, reads exactly what the report carries, and then sends it.

An account settings page with a contact email field, a plan panel, and an activity list, and the IssueProbe launcher button over the lower right corner

1. Open the launcher

One small button sits on the website. The visitor selects it to start a report.

The open widget panel with a description of a failed profile save and an optional reply email field

2. Describe the problem

The visitor writes what happened. A reply email address stays optional.

The widget evidence review step that lists console, request, and browser-state counts with two consent checkboxes

3. Review, then send

The visitor reads each evidence category and approves the screenshot before the report leaves the browser.

From incomplete report to clear review

A short visitor report can still carry useful technical context.

IssueProbe keeps the visitor form small. It combines the report with fixed safe evidence and the registered website source.

Visitor report

A visitor sends one problem or suggestion from the website.

Safe evidence

The widget includes only approved bounded evidence categories.

Read-only source

IssueProbe checks the exact registered repository revision.

Source-backed result

The result separates citations, conclusion, unknown facts, and action.

Human review

The owner edits the draft and approves each response or production action.

Report IPR-1042 ยท Ready for review
Problem

Profile save fails when the time zone is absent

Likely

Visitor report

I selected Save on my profile, but the page showed an error.

Browser evidence

POST /api/profile returned 500 in 412 ms.

Source evidence

src/routes/profile.ts:118โ€“124

Conclusion

The active save path likely uses an absent time-zone field without a safe branch.

Unknown

The number of affected profiles is not known.

Next step

Review the cited branch and add a focused regression test.

Read-only repository setup

Give each website one narrow source connection.

IssueProbe creates one SSH deploy key for each website and returns only the public key. Add it to the registered repository with read-only access.

  • One separate key for each website.
  • No password, personal access key, or user-supplied private key.
  • Exact repository host verification before source access.
  • No push, release, or repository script action.
Why read-only keys reduce risk

What the connection cannot do

No write authority

The key cannot push a commit, create a release, or run a repository script.

No shared credential

Each website uses a separate key. Rotating one website does not affect another.

Exact host check

Source access verifies the complete repository host fingerprint first.

Exact revision

Each investigation reads the revision registered when it entered the queue.

Setup sequence

Four steps to the first source-backed review.

Complete each step once for a website. The dashboard and the account API follow the same order.

Register the website

Add the exact website origin and the SSH repository location.

Add the public deploy key

Grant read-only repository access to the website-specific key.

Check readiness

Confirm the origin, repository branch, revision, and widget installation.

Send a test report

Prove the complete website-to-review flow before wider use.

Human and agent paths

Use the dashboard or the same account API.

A founder can complete setup in the dashboard. An authorized software agent can complete the matching API flow after explicit owner approval.

H

Human setup

Create a Free account, register a website, add the public deploy key, install the widget, and review reports.

Start the human path

A

Agent setup

Request owner authorization, preserve the exchange secret, use narrow scopes, and record every action in account activity.

Read the complete agent guide

Have your agent do it

Paste one of these to your coding agent.

Each prompt points at a Markdown document written for an agent to fetch and follow. Both state plainly that you, the owner, must approve access by email before the agent can continue.

Decide whether it fits

Evaluate https://issueprobe.com for my project. Fetch and follow:
https://issueprobe.com/evaluate.md

The agent reads the plans, the real limits, and the cases where IssueProbe is the wrong choice, checks them against the live API, and gives you a recommendation.

Set it up

Integrate https://issueprobe.com into this project. Fetch and follow:
https://issueprobe.com/integrate.md

The agent requests owner authorization, pauses for you to approve the email, then registers the website, verifies the origin, installs the widget, and sends one test report.

Both documents are plain Markdown you can read yourself: evaluate.md and integrate.md. An agent cannot create an account without your approval.

Simple first plans

Prove the complete value before you pay.

Free

One website

US$0
  • Three investigations each month.
  • One active investigation for the account.
  • Seven-day screenshot retention.
  • No payment card.
Start free

A report that exceeds the monthly investigation limit remains stored.

Common questions

Clear limits before setup.

Does IssueProbe send a reply to the visitor?

No. IssueProbe prepares a draft response for the website owner. A human reviews and copies it.

Does the widget collect cookie or form values?

No. Cookies, form fields, and local storage use names, presence states, and sizes only.

Can IssueProbe change my repository?

No. Each website uses a separate read-only SSH deploy key. The first release does not push a change or run repository scripts.

What happens after the monthly investigation limit?

The visitor report remains stored. IssueProbe marks it as stored without an investigation.

Can a software agent set up an account?

Yes. The agent requests owner authorization, exchanges one approved secret, and uses narrow API scopes.

Start with one real website.

Install the first site by hand and use real reports to select the next change.