Questions before you instrument.

Foveus is execution intelligence for .NET applications. It connects the incoming request or operation, its outbound calls, downstream services, related logs, context, business outcome, and recurring issue evidence into one investigation story.

It means treating a concrete backend run as the unit of investigation. Foveus preserves how work moved through requests and services, attaches the evidence produced along the way, and records how the operation actually ended instead of leaving those facts in separate tools.

Not in the broad, replace-everything sense. The private beta is an execution-first investigation layer for .NET teams. It uses logs, request telemetry, metrics, traces, and errors as evidence rather than trying to replace platforms such as Application Insights, Datadog, Grafana, New Relic, or Seq.

A distributed trace is primarily a path and timing model. Foveus uses request relationships and trace context where available, then adds execution context, ordered logs, outcome annotations, failure points, and issue linkage so the investigation can answer both what ran and whether the business operation succeeded.

An execution is one inspectable run of a backend request or operation. For the product available today, the clearest example is an incoming API request with its outbound HTTP calls, downstream incoming requests, parent-child relationships, logs, context, errors, durations, and outcome evidence.

A business outcome describes the result that mattered to the operation, such as payment failed, checkout completed, or attention required. It is separate from transport status: an HTTP request can return 200 while the provider response or application rule resolves the business outcome as failed.

No. Keep your existing logging setup. Foveus associates relevant logs with the request, service, and execution that produced them so engineers can read those lines in the context of the operation instead of searching disconnected streams manually.

Issues are the pattern layer above executions. Matching failure evidence can be grouped into an evolving issue with occurrence history, affected executions, shared factors, status, and regression context. The issue should always lead back to representative executions rather than hiding the underlying evidence.

The repository does not publish a confirmed version matrix. Foveus is currently .NET-first and the setup path targets ASP.NET Core, but beta teams should confirm their exact runtime and framework version during onboarding before instrumenting a service.

The product target is first telemetry in about three minutes: create or find an API key, install the SDK, register Foveus, start the application, and trigger one request. Real setup time depends on the application, deployment process, and whether the saved API key is available.

The current repository setup installs Foveus.SDK, registers it with builder.Services.AddFoveus using the workspace API key, and adds app.UseFoveus to the application pipeline. Use the private-beta documentation as the source for the current package version and placement details.

Yes. Incoming ASP.NET Core requests are the strongest current execution boundary. Foveus can show the route, timing, status, related context, logs, errors, and instrumented child work returned by the execution APIs.

Yes. Outbound HTTP telemetry is part of the current product model. It can appear as child work inside the originating execution and, when the downstream service is also instrumented, can be paired with that service's incoming request.

Yes. This is a primary capability represented by the current product. Foveus preserves the parent-child chain as one API makes an outbound request that becomes another instrumented API's incoming request, including service boundaries and durations.

Current beta materials include a Serilog integration path alongside the main SDK, and the product can attach Serilog logs to execution context. Confirm the current integration package and version in the beta documentation before installation because release details may change.

Useful worker-related telemetry exists today, including logs, logged exceptions, outbound HTTP telemetry, metrics, trace propagation, and some messaging hooks. Full automatic per-job execution capture is still evolving, so the private beta remains strongest around .NET API execution workflows.

Those execution roots and continuations are being introduced, but the repository does not confirm complete automatic coverage as a released capability. Queue, worker, retry, and scheduled-job examples describe the product direction; beta teams should confirm the exact integration available for their stack before relying on it.

No. Foveus is designed to work beside the logging and observability tools already in the application. Start with one service and one real workflow, then expand only when the execution evidence is useful.

The SDK carries execution and trace context across the outbound HTTP boundary. When the downstream instrumented service receives the request, Foveus uses that context to preserve the relationship between the caller's outbound request and the callee's incoming request without presenting Foveus as a proxy or network orchestrator.

Yes. An execution can show the root request, downstream services, outgoing and incoming request boundaries, durations, statuses, and the point where a failure or business decision occurred across the API chain.

Yes. The current execution and lineage models include parent references and child collections. The interface uses those relationships to keep downstream requests and related work attached to the execution that caused them.

Logs emitted within instrumented execution context carry enough relationship information for Foveus to associate them with the execution, service, request, and timeline position that produced them. This avoids treating the correlation identifier as something engineers must search manually in every stream.

Yes. Related execution logs can be presented as one ordered stream while retaining each line's service and request context. This is different from merging every application log globally; the scope is the execution being investigated.

The execution investigation model supports narrowing related evidence while preserving the surrounding execution. Current interfaces expose execution-scoped logs and request context; exact filter controls may continue to evolve during the beta.

Foveus keeps the technical status and business result separate. The timeline can show that the requests returned successfully while an outcome annotation or configured semantic rule classifies the operation as failed, declined, partial, or otherwise needing attention.

Yes, when the application records an outcome or a configured outcome rule can resolve it from captured evidence. The outcome is shown beside the technical timeline so engineers can see both how the system behaved and whether the operation accomplished what it was meant to do.

Depending on instrumentation and configuration, execution telemetry can include execution and trace identifiers, service and endpoint names, timestamps, durations, status codes, logs, stack traces, context properties, request relationships, outcome annotations, failure points, and issue-grouping metadata.

The current execution model can display request and response bodies and headers when they are supplied by the SDK and backend configuration. Customers control what their applications send and should avoid placing passwords, tokens, private keys, payment data, or other highly sensitive data in payloads, headers, logs, or custom context.

The repository does not document a single public self-serve switch that applies to every SDK and payload type. Configure collection conservatively and confirm the available SDK controls with the Foveus team before production use; broader workspace-level data controls are still being developed during the beta.

Foveus applies redaction or filtering for sensitive headers and configured sensitive fields where supported by the SDK and backend configuration. Those safeguards are not a substitute for data minimization, and the exact fields and integration behavior should be verified for each beta deployment.

Yes. The current private-beta settings define a 1 MB request-body ingestion limit and additional bounds for logs, errors, metrics, and context items. Limits may change during the beta, and response or integration-specific behavior should be confirmed in the current documentation.

Retention varies by telemetry type and is still being aligned during the private beta. The repository currently contains conflicting legacy and settings values, so this FAQ does not publish one universal duration. Confirm the active defaults shown for your workspace and the current privacy policy before sending production telemetry.

A specific hosting region and self-hosting option are not confirmed in the public repository. Foveus and its service providers may process data outside a customer's country, as described in the privacy policy. Teams with location requirements should confirm them before joining the beta.

Dashboard and workspace data require authenticated access, and the product models workspace membership and roles. Detailed enterprise governance controls are not presented as generally available during the private beta, so teams should review their access requirements during onboarding.

Foveus is not designed to intentionally collect passwords, access tokens, private keys, or application secrets. However, customers control their logs, headers, payloads, and context fields and must avoid including secrets there. Treat the Foveus ingestion key itself as sensitive configuration.

A team can stop sending telemetry by disabling or removing the application instrumentation or its usable ingestion credential. Key lifecycle and one-click workspace deletion are not fully self-serve during the beta, so contact Foveus promptly when revocation, deletion, or incident support is required.

The best fit is a .NET backend team investigating real API failures, support complaints, recurring issues, or confusing outcomes across production-facing services. Foveus is especially relevant when the evidence already exists but is scattered across requests, services, and logs.

The beta is intended to learn from real services, but it is not general availability and should not be treated as carrying a production SLA. Begin with one carefully selected service, minimize captured data, validate overhead and telemetry, and agree the rollout with the Foveus team.

Current public beta copy focuses on execution context search, execution detail and timelines, API request relationships, logs linked to executions, outcome and failure evidence, issue grouping, and alerts that lead back to evidence. Exact enabled features can vary as the beta evolves.

Beta teams can expect onboarding, troubleshooting, and product-feedback conversations with the Foveus team. Response times, dedicated support, security review, or other commitments are not standardized publicly and should be agreed directly where required.

Start with one service and one workflow that produces useful investigation evidence. Once the incoming request, outbound calls, logs, and outcome are behaving as expected, add the next downstream service deliberately rather than instrumenting the whole estate at once.

Use the private-beta page to request access. Access is invite-only and intended for teams whose .NET systems and investigation needs fit the current product focus.

The repository confirms invite-only access but does not define a fixed approval timeline. The Foveus team may review the request, discuss the service and workflow to instrument, and provide access and onboarding details when the team is a suitable beta fit.

Yes. Stop sending telemetry and contact Foveus to close the beta relationship or request data deletion. Some records may remain temporarily where required for backups, security, legal, or operational purposes, as described in the privacy policy and terms.

Pricing has not been finalised during the private beta. Beta teams will be informed before any paid plan is introduced. Plan names, prices, quotas, billing dates, discounts, and contracts shown in legacy experiments should not be treated as current commitments.

There is no single public commercial arrangement confirmed for every beta team. The terms state that access may be free, discounted, or covered by a separate written arrangement. Any applicable terms should be communicated directly before access is provided.

Self-serve billing is not enabled in the current product copy, and beta teams will be informed before a paid plan is introduced. Teams should not assume permanent free access, but this FAQ does not claim an automatic conversion date or billing event.

A general-availability date has not been finalised publicly. The current priority is validating setup, execution investigation, issue grouping, alerts, and linked logs with private-beta teams before making broader availability commitments.