Introducing Horus Lens: bug reports with the evidence attached

Most bug reports start with good intentions and bad context.

Someone writes: “This page is broken.” Or: “I clicked the button and nothing happened.”

Then the real work begins.

• An engineer asks for the browser.
• Then the URL.
• Then the steps.
• Then whether it happened once or keeps happening.
• Then someone asks for a screenshot.
• Then someone else asks for console logs.
• Then QA tries to reproduce it.
• Then the team checks whether it already has a Jira, Linear, or GitHub issue.

By the time the bug reaches engineering, half the context is missing.

We built Horus Lens to fix that.

What Horus Lens is

Horus Lens is an in-page bug-reporting and error-capture tool for web apps.

You add a small SDK to your app, and users, QA, support teams, or the app itself can submit a report directly from the page.

Each report can include the context engineers usually have to chase manually:

• Screenshot and DOM snapshot
• Session replay of what happened before the issue
• Console logs and network requests (including the ones that failed)
• JavaScript errors, source-mapped back to your original code
• Browser, route, page, and release metadata
• User annotations and a picked element

Then Horus Cloud takes that report, fingerprints it, groups repeats, routes the first occurrence to your tracker, and notifies Slack.

The goal is simple: turn “it broke” into a reproducible engineering issue.

Why this matters

A bug report is only useful if it answers the next engineering question.

• What page was the user on, and what did they click?
• What failed in the network tab? Was there a JavaScript error?
• Was this the same issue we already saw yesterday?
• Did it happen on the latest release?
• Can we see the user’s steps?
• Can we route this without creating five duplicate tickets?

Most tools capture one slice of that. A screenshot tool gives you a visual. An error tracker gives you a stack trace. A replay tool gives you session playback. A ticketing system gives you workflow. But the engineer still has to connect everything by hand.

How it works

A customer installs the Horus Lens SDK in their web app. For React apps that is as simple as wrapping the app with a provider; vanilla apps can mount Lens directly, or load it from a CDN script.

import { LensProvider } from "@merittdev/horus-lens/react";

<LensProvider
  accessId="lai_your_access_id"
  app={{ release: process.env.NEXT_PUBLIC_COMMIT_SHA }}
  autoCapture={{ errors: true }}
>
  <App />
</LensProvider>

Once active, the SDK keeps a rolling capture of useful debugging context — console logs, network activity, JavaScript errors, and session-replay events.

When someone submits a report, Lens adds the current page context, a screenshot, a DOM snapshot, annotations, the selected element, and metadata. The assets upload directly to storage through presigned URLs, while the API records the report and starts processing it.

From there, Horus Cloud handles the backend workflow:

1. Fingerprint the report.
2. Group it with existing repeats.
3. Symbolicate minified stack traces using uploaded sourcemaps.
4. Create a tracker issue only for the first report in a group.
5. Attach later repeats to the same grouped issue.
6. Notify Slack with links to the report, replay, and tracker issue.
7. Show everything in the Horus dashboard.

Manual reports and automatic errors

Lens supports both manual bug reports and automatic error capture.

Manual reports are for users, QA, support, and internal teams. Someone opens the overlay, writes a comment, annotates the page, picks an element, records steps, and submits.

Automatic capture is for when the app itself hits an unhandled error or rejected promise. Lens submits those as error-triggered reports, with cooldowns, sampling, ignore rules, and per-session caps so teams do not get flooded.

Built for real debugging, not just intake

The important part of Lens is not the overlay.

The overlay matters — it needs to be fast, clean, draggable, touch-friendly, and isolated from the customer app, so it runs inside a Shadow DOM and never fights the host page’s styles. But the bigger value is what happens after submit.

Horus Lens does not just collect reports into another inbox. It groups duplicates by fingerprint — normalized error message, stack frames, and route. It keeps the same issue grouped across releases when the underlying error is the same. It symbolicates minified stacks back to original source when sourcemaps are uploaded for the matching release. And it creates one tracker issue per group instead of spamming Jira, Linear, or GitHub with duplicates.

Bug-reporting tools should reduce noise, not create more of it.

Why this belongs in Horus

Horus started as a local-first investigation layer for engineering teams. The original problem was that agents and engineers waste too much time rebuilding context across code, logs, queues, metrics, deploys, and incidents.

Lens extends that idea to the browser. Instead of starting an investigation from a vague ticket or a Slack message, Horus can now start from the exact moment the user experienced the issue.

A frontend issue no longer starts as a mystery. It starts with a replay, a screenshot, a DOM snapshot, failed requests, console logs, release metadata, and source-mapped errors — a much better starting point for engineers and agents alike.

What teams get

• Let users or QA report bugs directly from the page.
• Capture the full browser context behind each report.
• Replay what happened before the issue.
• Review console logs, failed requests, and JavaScript errors.
• Annotate screenshots and blur sensitive regions before upload.
• Group repeat reports into a single issue.
• Create tracker issues once per group, not per report.
• Notify Slack with links to the report, replay, and tracker issue.
• Upload sourcemaps so minified stacks point back to original source.

The end result is fewer vague tickets, fewer duplicate issues, and less time spent asking for reproduction steps.

From “it broke” to “here is what happened”

The best bug reports are not longer. They are richer.

A good report should not force the engineer to ask five follow-up questions before they can begin. It should arrive with enough evidence to understand what happened, where it happened, and what to check next.

That is what Horus Lens is built for: from “it broke” to a triaged issue with the evidence attached.