Status & SLA

Where to check TronSave service status, how to report incidents, and what to know about uptime expectations.

This page tells you where to check whether TronSave is up, how to report a problem, and what to expect during incidents. It covers both the website and the API (Mainnet and the Nile testnet).

Service status

TronSave does not publish a dedicated status/uptime page. To check whether the service is up, test the relevant environment directly (see below) or ask in the community channel (TronSave | Energy Service Group).

Without a status page, you can confirm whether a specific environment is reachable with a lightweight request against a read endpoint:

cURL

# Mainnet
curl -s -o /dev/null -w "%{http_code}\n" https://api.tronsave.io/v2/user-info -H "apikey: YOUR_API_KEY"

# Nile testnet
curl -s -o /dev/null -w "%{http_code}\n" https://api-dev.tronsave.io/v2/user-info -H "apikey: YOUR_API_KEY"

JavaScript

A 200 confirms the API is reachable and your key is valid. A 5xx or a connection timeout points to a service-side problem rather than a problem with your request. For the meaning of individual status codes, see Errors & Rate Limits.

What "status" covers

TronSave has several independently operated surfaces. An issue on one does not necessarily mean the others are affected:

Surface	Endpoint / URL	What it serves
Website (Mainnet)	https://tronsave.io	Buy/sell UI, account dashboard
Website (Nile)	https://testnet.tronsave.io	Testnet UI
API (Mainnet)	https://api.tronsave.io	Production API
API (Nile)	https://api-dev.tronsave.io	Testnet API
TRON network	Mainnet / Nile	On-chain delegation & settlement

Order fulfilment and delegation ultimately depend on the TRON network itself. If the underlying chain is congested or experiencing issues, orders may settle slowly even when TronSave's own services are fully operational.

See Environments for full details on each environment.

Reporting an incident

If you believe TronSave is down or degraded:

1. Confirm the scope — test the affected surface using the request above and note the HTTP status code or error message.

2. Capture details — record the timestamp, environment (Mainnet or Nile), affected endpoint or page, and any requestId/order ID returned.

3. Report it through an official support channel — Support/refunds: t.me/wantingtrx; Community: TronSave | Energy Service Group.

For non-outage problems (a stuck order, a failed transfer, an unexpected error), start with Troubleshooting and Transfer Recovery before reporting an incident.

Service level expectations

TronSave does not publish a formal, contractual Service Level Agreement (no uptime guarantee, support-response commitment, or service credits). Use of the service is governed by the Terms of Service.

If you operate at scale and need uptime guarantees or a support response commitment, reach out via t.me/wantingtrx to discuss enterprise terms.

Building for resilience

Whether or not a formal SLA applies, treat the API as a remote dependency and design defensively:

• Retry with backoff on 5xx and timeout responses; do not retry on 4xx. See Errors & Rate Limits.

• Make order creation idempotent where possible so a retried request does not place a duplicate order.

• Poll order status rather than assuming a request succeeded — confirm fulfilledPercent before relying on the delegation.

• Have a fallback for time-critical transactions (e.g., let TRX burn) if an order cannot be filled in time.

Next steps

• Errors & Rate Limits — status codes and retry guidance

• Troubleshooting — common problems and fixes

• Environments — Mainnet and Nile endpoints

• Terms of Service