> ## Documentation Index > Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt > Use this file to discover all available pages before exploring further. # Manage General Service > Find and access general services in Siverse, view running workloads, and perform routine actions such as bringing services online or offline, restarting, sharing, or deleting. After a general service is created, you can find it in the service list and view its endpoints, workload details, logs, and monitoring information on the details page. You can also bring it online, take it offline, restart it, configure scheduled tasks, share it, or delete it as needed. ## Find Services 1. Go to **Inference > General Service**. 2. Select a **Region**, **Cluster**, and **Project Group**. 3. Find services by service name, project group, or other filter criteria. 4. View services under the **Personal Services** or **Shared Services** tab. When locating a service, focus on its service status, endpoint, resource configuration, desired replicas, ready replicas, and public access scope. If the service has not entered the **Running** state, first check the workload details, events, and logs. ## Access Services Go to the **Overview** tab on the service details page. Under **Endpoint**, click **View Details**. In **Endpoint Information Details**, view the link addresses and authentication information by port. | Access Method | Description | | - | - | | Shared Gateway | Obtain the link address for access from outside the cluster in **Endpoint Information Details**. The page provides two types of links: **Hash Security Mode** and **Plaintext Mode**. If the service is configured with multiple ports, view and use the corresponding link based on the actual port. | | In-cluster Access (VPC) | Access the service through the address displayed on the page from within the same Kubernetes cluster or VPC internal network. This is suitable for invocation by other workloads or debugging within a Pod. | | Dedicated Gateway | Access the service using a custom domain name and ingress path. If a service includes multiple ports, requests can be forwarded to the corresponding ports through different ingress paths under the same domain name or through different domain names. | When calling the service, use the protocol, port, path, and authentication method consistent with the service configuration. For the complete validation procedure after initial creation or an update, see [Create General Service](/siverse/inference/create-general-inference-services.md#4-verify-access). When a service runs with multiple replicas, requests are not distributed to each replica strictly in round-robin order. Instead, overall traffic is balanced through probabilistic random distribution or connection-level load balancing. When troubleshooting an issue with a single replica, use instance logs and the request time range to identify the problem. ## Update Standalone Gateway When modifying only the standalone gateway domain name or access path, you do not need to update the service's runtime configuration, such as its image or resources: 1. In **Inference > General Service**, locate the target service and click **More > Update Domain** in the Actions column. 2. Add, modify, or delete an independent gateway, and confirm the mapping between domain names, entry paths, and service ports. 3. Click **Save**. After the configuration takes effect, go to the **Overview** tab on the service details page. Under **Endpoint**, click **View Details**, then use the link for the corresponding port to send a request for verification. Updating the gateway configuration through **Update Domain Name** does not restart the Pod. If you also need to modify the image, environment variables, resources, or ports, use the service update entry; after submission, the workload may be redeployed. ## View Load Details On the service details page, view workload details to confirm whether service instances are running as expected. | Item to Check | Suitable for Troubleshooting | Recommended Actions | | - | - | - | | Workload version and replicas | The service is not ready, or the desired and ready replica counts are inconsistent. | First confirm changes to the version and replicas, then determine whether to continue waiting, scale out, or roll back. | | Events | Instance scheduling, image pulling, storage mount, or health check failures. | First identify the failure stage based on the events, then view the logs of the relevant instance. | | Instance logs | Application startup failures, ports not listening, missing dependencies, or request errors. | First check the real-time logs of the affected instance. After the instance restarts, view the logs from the previous run. | | Monitoring metrics | Abnormal CPU, GPU, memory, network, or business metrics. | Compare the request time range with resource usage curves to determine whether the bottleneck is in service resources or application logic. | | Storage information | Local logs, cache, or temporary files are growing too quickly, or disk usage on the node hosting the instance is abnormal. | On the **Storage** tab, check the usage of **Pod Ephemeral Storage** and **Node Disk**. Data that needs to be retained or continues to grow should be written to a mounted Volume to avoid affecting service instance stability. For details, see [Best practices for ephemeral storage](/siverse/best-practices/use-ephemeral-storage.md). | ## Manage Services After locating the target service in **Inference > General Service**, you can perform the following actions as needed. | Action | Purpose | Considerations Before the Action | | - | - | - | | **Bring Online** | Starts an offline service so that it can begin accepting requests. | After bringing the service online, wait for it to enter the **Running** state before verifying the endpoint. | | **Take Offline** | Stops the service and releases its runtime resources. | Migrate or stop business traffic before taking the service offline. | | **Restart** | Restarts service instances using a rolling upgrade approach. Suitable for handling temporary issues or applying configuration changes. | If new instances cannot be scheduled due to insufficient resources, instances of the earlier version can continue serving requests. The platform will complete the restart when resources become available. | | **Scheduled Task** | Configures scheduled bring-online, take-offline, or restart operations using Cron expressions. | Confirm the execution time, resource availability, and business impact. Scheduled tasks may be delayed or fail when resources are insufficient or scheduling errors occur. | | **Share** | Shares the service with other users. | Confirm that the service configuration, endpoint, and data dependencies are suitable for sharing. | | **Delete** | Deletes the service record and associated resources. | Before deletion, confirm that no callers depend on the service, and save any required configurations or logs. | ## Frequently Asked Questions > **Why is the standalone gateway still inaccessible after it has been saved successfully?** > > Check whether the domain name has been resolved to the gateway endpoint of the current cluster, whether the domain certificate and HTTPS policy have taken effect, whether the service is **Running**, whether the ingress path matches the access URL, and whether the corresponding service port is correct. If the configuration has just been saved, wait for it to take effect and then verify again. > **Can a domain name be bound to multiple services?** > > You can use different entry paths under the same domain name to bind multiple services. However, within the same cluster, the same combination of domain name and entry path cannot be reused by multiple services. ## Related Documentation * [Release and Roll Back General Services](/siverse/inference/release-and-rollback-general-inference-services.md) * [Advanced Inference Operations](/siverse/inference/advanced-inference-service-operations.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.