> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/operate/monitor-and-troubleshoot/diagnostics-logs.md).

# Diagnostics and logs

Use operational diagnostics, logs, and OnePortal Validation Checker output safely during Dialogue Cloud Neo troubleshooting.

Use diagnostics and logs to collect evidence before escalating a Dialogue Cloud Neo operational issue. OnePortal can also provide validation output that helps identify configuration or dependency issues for a Service or Contact Center.

{% hint style="info" %}
Diagnostics are decision support, not a replacement for the current support process. Interpret results together with customer impact, monitoring data, and the affected component's administration guidance.
{% endhint %}

## Prerequisites

* You have access to the affected customer in OnePortal.
* Your OnePortal role permits viewing diagnostics or validation results for the affected object.
* You know the affected Service, Contact Center, feature, or integration.
* You have permission to collect and share diagnostic evidence according to the customer process.

## Start With the Symptom

Use [Report a Dialogue Cloud Neo incident](/operate/support-and-escalation/incident-reporting.md) for the relevant routing/hunt, provider, audio-quality, login, or secondary-function investigation. Follow the client and telephony collection steps that apply to your deployment; a Connect SBC trace is not a universal requirement for every Unify incident.

Record recent configuration changes as evidence. Only revert a change when you are authorized to do so under the customer's incident and change process. If authorization or the impact is unclear, use the support route rather than changing the live configuration.

## Hosted-cloud log collection

AnywhereNow manages the Dialogue Cloud Neo back end.

If required back-end logs are unavailable to you, record which evidence you could not collect and include the available details from [Evidence to capture](#evidence-to-capture). Use [Support responsibilities](/operate/support-and-escalation/support-responsibilities.md) to identify the applicable support route. For the partner operational support model, authorized partner staff submit the case to AnywhereNow through the support portal; see [Partner operational support](/operate/support-and-escalation/support-responsibilities/partner-operational-support.md).

## When to use Validation Checker

Use **Validation Checker** when you need a structured OnePortal check of a Service, Contact Center, or related operational setup before escalation or after a change.

Validation Checker is useful when:

* A newly provisioned Service or Contact Center does not appear to behave as expected.
* A feature or integration looks enabled but is not working for users.
* A request completed, but the operational state still needs validation.
* You need evidence for support that shows which checks passed or failed.
* You want to confirm the current state before or after a planned operational action.

Do not use Validation Checker as proof that every dependent system is healthy. Some issues require component logs, tenant-side checks, or support-side investigation.

## Run and review validation

The exact objects and checks available in OnePortal depend on the customer environment and your permissions. At a high level:

1. Open OnePortal and select the affected customer.
2. Open the relevant Service or Contact Center context.
3. Start **Validation Checker** where it is available for that context.
4. Review the returned checks and statuses.
5. Capture failed or warning checks, messages, timestamps, and the affected object.
6. Compare the result with any recent **Requests** or **Scheduled** entries.
7. Escalate through the current support process when the result indicates a failed dependency, an unexpected state, or an issue you cannot safely resolve.

{% hint style="warning" %}
Do not rerun, retry, or change operational actions only because a validation result is unexpected. First confirm whether a request is still in progress, whether a scheduled action is pending, and whether the customer has an approved change or incident process for the next step.
{% endhint %}

## Interpret validation results safely

Use validation output as a troubleshooting signal:

| Result type                    | Operational meaning                                                                                      | Recommended follow-up                                                                          |
| ------------------------------ | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Passed or successful check     | The checked item did not report a problem at the time of validation.                                     | Continue with other evidence if users still report impact.                                     |
| Warning or informational check | The checked item may need attention or may depend on environment-specific setup.                         | Review the message, recent changes, and related administration guidance before acting.         |
| Failed check                   | The checked item reported an issue that may affect the Service, Contact Center, feature, or integration. | Capture the details and escalate or remediate through the approved process.                    |
| Missing or unavailable check   | The checker did not return the expected validation item, or the item is not available in your context.   | Confirm permissions, selected object, and whether the feature is enabled for that environment. |

Avoid broad conclusions such as "the Service is healthy" or "the integration is down" from a single validation result. State what the check reported and when it was run.

## Evidence to capture

When escalating a diagnostics or validation issue, include:

* Customer name or identifier used in the support process.
* Affected Service and Contact Center.
* Feature or integration involved.
* Validation Checker result, including failed or warning messages.
* Request or scheduled item details if a recent action is related.
* Time of the check and time zone.
* User-facing symptoms and when they started.
* Screenshots or exported evidence where allowed.

For call-specific incidents, also capture the UCC, caller and callee identifiers, call direction, UTC timestamp, affected agent, impact, and recent changes. Include correlation identifiers when available. Review browser/HAR files, logs, and screenshots before sharing: remove credentials and authorization tokens, and protect personal data while retaining the identifiers needed for investigation through the authorized support channel.

Use [File a support case](/operate/support-and-escalation/case-filing.md) for submission requirements. If the root cause remains unknown after the documented L2 Intermediate investigation, follow the [Support service definitions](/operate/support-and-escalation/support-service-definitions.md). Include the completed investigation even if the root cause is still unknown.

## Related operational views

For Service, Contact Center, Requests, and Scheduled views, see [Service health](/operate/monitor-and-troubleshoot/service-health.md).

For provisioning tasks, see [Provisioning](/platform-administration/provisioning/provisioning.md).

After collecting evidence, use [Support responsibilities](/operate/support-and-escalation/support-responsibilities.md) to choose the applicable escalation path.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/operate/monitor-and-troubleshoot/diagnostics-logs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.