Skip to content
Execution intelligence for .NET

See the whole execution. Know how it actually ended.

Follow incoming and outbound requests across services, then beyond the API response through queues, workers, retries, and the real business outcome.

Request access Read the docs
Unconnected evidence

Each system recorded a local fact, using its own identifier, clock precision, and idea of success.

API logs200 OKPOST /payments
request_idreq_8472
RabbitMQ managementACKpayment.requested
delivery_tag92message_idmsg_4821
Worker logscompletedPaymentWorker
attempt2job_idjob_318
Provider history200 OKPOST /charge
provider_refprv_319
Application eventfailedpayment.failed
reasondeclined
Five records. Four systems. No shared execution story.The evidence exists, but an engineer still has to prove that these records belong to the same payment.
Unconnected evidence

Each source recorded a local fact. None provides the complete investigation.

API logs200 OKPOST /payments
request_idreq_8472
RabbitMQ managementACKpayment.requested
delivery_tag92message_idmsg_4821
Worker logscompletedPaymentWorker
attempt2job_idjob_318
Provider history200 OKPOST /charge
provider_refprv_319
Application eventfailedpayment.failed
reasondeclined
Five records. Four systems. No shared execution story.The engineer still has to prove that these records belong to the same payment.

Foveus does not orchestrate your infrastructure. It reveals the execution already moving through it. Queue and worker continuation coverage is expanding during the private beta.

01 · Connected by causality

One execution across every API.

One request can cross several services. Foveus keeps it one execution, pairing every outbound call with the downstream incoming request it becomes.

Incoming requestOutbound requestService boundaryBusiness result

Checkout API outbound POST /payments becomes Payments API incoming POST /payments. The same relationship continues through Risk API to the provider.

02 · Execution roots

An execution can begin anywhere.

Request, message, worker, job, or schedule: the root changes, but the visual language and the final business result stay consistent.

01 / API chain

One request can cross several services.

An outbound call from one API becomes the incoming request of the next. Foveus preserves both sides and their parent-child chain.

Incoming HTTPOutbound HttpClientService boundaries
02 / Request to async

The response ends. The execution does not.

Carry context beyond ASP.NET Core into a queue, worker, retry, provider request, and the business outcome.

ASP.NET CoreRabbitMQ.NET Worker
03 / Message-led

A consumed message can be the beginning.

See consumers, fan-out work, publishes, and the terminal result even when there is no inbound HTTP request.

order.createdConsumerChild executions
04 / Background job

One job run. Every item it touched.

Understand batches, retries, partial completion, and the final state of the run as one business operation.

HangfireBatch workPartial outcome
05 / Scheduled

Recurring work deserves a real ending.

Follow a schedule from trigger to comparison, mismatch detection, issue creation, and the outcome needing attention.

CronReconciliationExpected outcome
03 · Logs in context

Logs that already know where they belong.

Foveus attaches every line to the request, service, and execution that produced it, then orders the complete stream chronologically.

Stop grepping the same correlation ID across separate streams. Move from the whole execution to one service without losing its surrounding story.

Connected log streamCheckout execution · EXE-8F2A
4 services · 7 related logs · 911ms
Root · Incoming HTTP requestCheckout execution · EXE-8F2A
4 services642msFailed
Clientroot
POST /checkoutBrowser request
Checkout APIincoming
POST /checkoutRoot request
Payments APIincoming
POST /paymentsChild of Checkout
Risk APIincoming
POST /risk/evaluateChild of Payments
Provider200 OK
POST /chargeapproved=false
04 · The result that matters

Infrastructure success is not business success.

Requests can return, messages can acknowledge, and workers can complete while the operation still fails the user.

Technical signalsEverything looks healthy
HTTP requestPOST /payments200 OK
Messagepayment.requestedAcknowledged
WorkerPaymentWorkerCompleted
ProviderPOST /charge200 OK
05 · One investigation surface

Investigate the complete execution.

Move from the root request to every child call, related log, payload, issue, and business outcome without reconstructing the chain across separate tools.

The execution is the unit of investigation. Requests and logs are evidence inside it, not disconnected screens you have to stitch together.

app.foveus.dev / executions / EXE-8F2A
API-to-API execution

Checkout execution

EXE-8F2A · production · 10 Jul 2026 14:02:18

Failed outcome
Duration642msRequests4 parent / childServices4Related issueFOV-218
Execution timelineChronological · parent and child requests
POST /checkoutCheckout API · incoming request · root62ms
POST /paymentsCheckout outbound → Payments incoming · child request110ms
POST /risk/evaluatePayments outbound → Risk incoming · child request184ms
POST /chargeRisk outbound → Card Provider · HTTP 200, approved=false231ms
checkout.failedBusiness outcome · payment declined by providerterminal
06 · Issues, not noise

Recurring failures become one evolving issue.

Group matching execution failures, preserve their evidence, and see when the same problem recurs or starts behaving differently.

Without grouping

Every failed execution becomes another alert, row, or log search.

38 signals → 1 issue
FOV-218 · recurring regression

Payments complete technically but resolve to a declined outcome

Open
3 days agofirst seen2m agolast seen38occurrences↑ 41%since release

Shared evidence

root: payment provider: card_network outcome: payment.failed reason: declined release: payments-api@1.24.0
07 · .NET first

Built specifically for .NET.

Instrument the frameworks and boundaries already inside your applications, then keep one execution context as work crosses them.

Start with ASP.NET Core and HttpClient. Add Worker Services, Serilog, RabbitMQ, and Hangfire continuations as the workflow grows.

01ASP.NET Core02HttpClient03Worker Services04Serilog05RabbitMQ06Hangfire01ASP.NET Core02HttpClient03Worker Services04Serilog05RabbitMQ06Hangfire
Service 01 · ASP.NET Core

Checkout API

builder.Services.AddFoveus("..."); app.UseFoveus(); POST /checkout └─ outbound POST /payments
HttpClient contextoutbound becomes downstream incoming
Service 02 · ASP.NET Core

Payments API

builder.Services.AddFoveus("..."); app.UseFoveus(); POST /payments └─ parent: POST /checkout

SerilogLogs from both applications attach to the same execution.EXE-8F2A

Program.csCurrent setup API
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddFoveus("YOUR_API_KEY");

var app = builder.Build();

app.UseFoveus();
app.MapControllers();
app.Run();
Start with one service. Follow one real workflow. Expand when the evidence becomes useful.dotnet add package Foveus.SDK
“The hardest production failures rarely lacked evidence. The evidence was scattered across requests, jobs, queues, workers, and provider histories, with no single place showing what the operation was trying to accomplish or how it actually ended.”
TU
Tobby UmohFounder, Foveus
Foveus private beta

Stop debugging fragments.See the execution.

Follow the operation from its first boundary to the business outcome that mattered.