Issues

An issue is an observed recurring failure pattern that Foveus groups from executions. It describes what was observed; it is not a confirmed root cause. Instead of treating every failed request as a separate problem, Foveus groups related failures so you can focus on what needs investigation. For example, if the same endpoint repeatedly returns HTTP 500, Foveus can group those failed executions into one issue:

HTTP 500 in orders-api

Why issues matter

Executions show individual units of work. Issues show patterns. Use issues when you want to answer:

What is failing?
Where is it happening?
How often is it happening?
Which execution should I inspect first?
Is this active, resolved, or recurring?
Who owns the follow-up?

How Foveus creates issues

Foveus groups failed executions per service by failure signature. The signature is built from:

route (endpoint or operation)
HTTP status code
exception type
throw location, when present
outbound dependency

Each matching execution is one occurrence of the issue. The exact grouping depends on the telemetry captured for the execution. Failures that become issues include failed executions and exceptions logged through ILogger with the Foveus logger provider. Exceptions logged only through the Serilog sink are not turned into issues. Inbound 4xx responses without other failure evidence are not turned into issues.

Issue lifecycle

An issue moves through these states.

State	Meaning
`new`	The issue was just created from its first occurrence.
`active`	The issue has occurred again since it was created or reopened.
`resolved`	Someone marked the issue as resolved, individually or in bulk. Resolving is always manual.
`reopened`	An occurrence happened after the issue was resolved. Foveus reopens the issue automatically and clears the resolution.

After a reopen, the next occurrence moves the issue back to active. Reopening depends on when the occurrence happened, not when Foveus received it. An occurrence from before the resolve that arrives late is counted, but does not reopen the issue.

Failure types

Failure type explains the kind of problem Foveus observed. Each issue has one failure type:

Failure type	Meaning
`exception`	An exception was thrown or logged.
`http_error`	The execution returned an HTTP 5xx response.
`timeout`	The failure was reported as a timeout.
`business_rule`	A business-level or validation failure, such as a rejected request with an outcome code.
`execution_error`	The execution failed without a more specific classification.
`dlq`	The reported error describes a message routed to a dead-letter queue.
`retry_exhausted`	The reported error describes retries that were exhausted.
`sla_breach`	The operation exceeded its expected latency.

Foveus does not capture dead-letter queues or application retry attempts directly. dlq and retry_exhausted are assigned only when the reported error describes them.

Issue detail

Open an issue to inspect its evidence. An issue detail page can include:

failure pattern
hypothesis and suggested fix
common factors
representative execution
linked executions
recent activity
lifecycle
comments
activity history
technical metadata

The hypothesis and suggested fix are rule-based text, chosen from templates by failure type and the evidence available. They are a starting point for investigation, not an analysis of the root cause. The representative execution is usually the best place to start. It gives you a concrete failed execution to inspect.

Linked executions

An issue can have one or more linked executions. Linked executions show the individual requests, BeginExecution jobs, or other executions that matched the issue pattern. Each one is an occurrence. Use linked executions to inspect:

request context
response context
timeline
logs
status
duration
failure evidence

Representative execution

When available, Foveus highlights a representative execution for the issue. This is the execution you should inspect first. A representative execution helps you move from:

This issue happened.

to:

This is the exact execution that shows what happened.

Common factors

Common factors explain what Foveus found across related executions. Examples:

Endpoint: POST /orders
Status code: 500
Failure type: http_error
Source: web

Common factors help you understand why executions were grouped together.

Comments

Use comments to record triage notes. Good comments include:

root cause
next step
owner
expected fix time
decision
deployment note

Example:

Next step: inspect the downstream inventory provider response for failed order creation requests.

Activity history

The activity tab shows changes made to the issue. This can include:

comments
assignment changes
status changes
resolution
reopening

Use activity history when you need to understand what changed and when.

Search issues

Use the Issues page to find active or historical issue patterns. Common searches:

service:orders-api

status:active

Issue states are new, active, resolved and reopened.

failureType:http_error

issueId:313

You can combine filters when supported:

service:orders-api status:active

Issues vs executions

Issues and executions answer different questions.

Use	Go to
Find a specific request, job, or operation	Executions
Search by customer ID, request ID, or business value	Executions
Investigate a repeated failure pattern	Issues
See all executions linked to a failure pattern	Issue detail
Record triage notes and ownership	Issue detail

When to use issues

Use issues when:

several executions fail in the same way
a failure keeps recurring
you need to assign ownership
you want to track resolution
you want to move from a pattern to evidence

Use executions when:

you are investigating a single support complaint
you know a business identifier such as customerId
you know a request ID, trace ID, or execution ID
you need request or response context

What to do next

Learn about executions: Executions
View your first execution: View your first execution
Investigate a user complaint: Investigate a user complaint
Debug an HTTP 500: Debug an HTTP 500

Start here

Get started

Core concepts

Guides

SDK

Security and data

API reference