> 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/service-health.md).

# Service health

Use OnePortal operational views to inspect Dialogue Cloud Neo Services, Contact Centers, and operational requests.

Use OnePortal operational views to understand the current state of Dialogue Cloud Neo Services and Contact Centers, and to track operational requests that are already submitted or scheduled.

This page is for operational inspection and safe follow-up. For creating Services or Contact Centers, see [Provisioning](/platform-administration/provisioning/provisioning.md).

{% hint style="warning" %}
Operational actions can affect live customer environments. Only start an action when you have the required permissions, a confirmed customer or support request, and an agreed maintenance plan where the action can interrupt service.
{% endhint %}

## Prerequisites

* You have access to the relevant customer in OnePortal.
* Your OnePortal role permits viewing Services, Contact Centers, and request status for the customer.
* You know which customer, Service, or Contact Center you need to inspect.
* For any change or service-impacting action, you have a customer-approved change record or the current delivery/support instruction for that environment.

## View Service state

Use the **Services** view to inspect the service containers that exist for a customer. A Service is the cloud service container that hosts one or more Contact Centers.

When you inspect a Service, use the view to answer operational questions such as:

* Which Services exist for the selected customer.
* Which region or deployment context the Service belongs to.
* Whether the Service has an available state or status indicator that requires follow-up.
* Which Contact Centers are associated with the Service.
* Whether recent or scheduled requests are related to the Service.

Do not treat the Service view as the only health signal for a production incident. If the customer reports an outage, combine OnePortal state with the current monitoring, support, and incident-management process.

## View Contact Center state

Use the **Contact Centers** view to inspect the Contact Centers under a customer or Service. Contact Centers can expose configuration, feature, endpoint, and status information that helps you determine whether the expected customer-facing contact-center structure exists.

When inspecting a Contact Center, check:

* The Contact Center name and display name.
* The parent Service.
* The current status shown in OnePortal.
* Active features and integrations.
* Endpoint information where it is visible for the Contact Center.
* Whether any pending or scheduled request may explain a temporary mismatch between intended and current state.

For provisioning-level Contact Center creation, see [Set up a Contact Center](/platform-administration/provisioning/provisioning/setting-up-a-contact-center.md).

## Track requests

Use the **Requests** view to follow operational and provisioning actions that have already been submitted. The view is useful when a Service or Contact Center state does not yet match the expected result because a request is still queued, running, failed, or waiting for a later execution window.

When reviewing a request:

1. Confirm that the request belongs to the correct customer.
2. Confirm the affected Service or Contact Center before taking further action.
3. Review the request status and any available message or timestamp.
4. Check whether a related scheduled entry exists before resubmitting or escalating.
5. If the request shows an error or remains in an unexpected state, follow the current support process with the request details.

{% hint style="info" %}
Available request details and actions depend on the customer environment, OnePortal permissions, and the type of request. Do not assume that every action is available for every tenant or user.
{% endhint %}

## Review scheduled actions

Use the **Scheduled** view to inspect actions planned for a future execution window. Scheduled entries help operations teams avoid duplicate changes and confirm whether a requested Service or Contact Center operation is already planned.

Before you create, retry, cancel, or escalate an operational action, check whether a scheduled item already covers the same customer, Service, Contact Center, or change window.

For each scheduled item, confirm:

* Customer and affected object.
* Planned execution time or window, where shown.
* Action type or description.
* Current scheduled status.
* Whether the action aligns with the approved change or support request.

{% hint style="warning" %}
Do not cancel, retry, or reschedule operational actions unless the current process for that customer authorizes you to do so. If the impact or rollback path is unclear, escalate through support before changing the scheduled action.
{% endhint %}

## Safe operational action framing

OnePortal may show actions for Services, Contact Centers, requests, or scheduled items. Treat the available action list as contextual, not universal.

Before using an action:

1. Confirm that you are viewing the correct customer.
2. Confirm the affected Service or Contact Center.
3. Read the action label and any confirmation text before proceeding.
4. Confirm whether the action can interrupt live service, update configuration, or remove customer resources.
5. Confirm that the change is approved and scheduled appropriately.
6. Capture the resulting request or scheduled entry after submission.

If an action can affect production availability and no maintenance window is approved, stop and escalate instead of proceeding.

## Operational checks

Use this checklist when investigating a Service or Contact Center state:

| Check                    | Use                                                                                   |
| ------------------------ | ------------------------------------------------------------------------------------- |
| Customer selected        | Confirms that you are not inspecting another tenant.                                  |
| Service visible          | Confirms that the customer's Service container exists.                                |
| Contact Center visible   | Confirms that the expected Contact Center exists under the customer or Service.       |
| Status reviewed          | Identifies whether OnePortal shows an unexpected state.                               |
| Requests reviewed        | Identifies submitted operations that may still be in progress or failed.              |
| Scheduled items reviewed | Identifies planned actions that have not executed yet.                                |
| Support context captured | Provides the request ID, status text, timestamps, and affected object for escalation. |

## Escalation

Escalate through the current support process when:

* A Service or Contact Center is missing unexpectedly.
* A request failed or remains in an unexpected state.
* A scheduled action conflicts with an approved change window.
* The UI state and customer-reported behavior do not match.
* You are unsure whether an action is safe for the production environment.

Include the customer, Service, Contact Center, request or scheduled item details, timestamps, and screenshots where allowed by the customer process.

## Next step

If the health checks do not explain the issue, continue to [Diagnostics and logs](/operate/monitor-and-troubleshoot/diagnostics-logs.md) to collect evidence before escalation.


---

# 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/service-health.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.