Service status
Service status and incident communication.
Public operational announcements and post-incident updates are published in the official CoinPriceFeeds Telegram status channel.
- One public channel for operational announcements.
- Primary and backup paths treated as separate checks.
- Client-specific escalation follows the agreed service scope.
Where current public updates appear
The CoinPriceFeeds Telegram status channel is the official public route for service announcements and post-incident information.
This page explains the communication process but does not display a live green or red indicator. Loading this static page successfully does not prove that a client feed, a market-data source, or a destination platform is healthy.
What an operational update can distinguish
A useful update identifies the affected layer as clearly as the available evidence permits.
Swipe or scroll horizontally to see all columns
| Layer | Example scope question |
|---|---|
| Source | Is one venue, platform source, provider session, or instrument group affected? |
| Pricing feed | Is a specific client feed or pricing process affected? |
| Delivery endpoint | Is the primary, backup, or a regional connection path affected? |
| Destination | Is the client bridge, platform, FIX consumer, or its network path receiving? |
| Management surface | Is pricing still running while dashboard or administrative access is impaired? |
These distinctions matter because a source interruption is not automatically a service-wide outage, and a working server process does not prove that a client destination is receiving current prices.
Primary and backup remain separate checks
Clients can keep primary and backup connections live at the same time. Each path exposes the pricing-configuration identity it loaded and can be compared for price agreement, activity, and symbol coverage.
If one connection path is impaired, the client’s bridge or platform follows the failover behavior agreed for that integration. The redundancy overview explains the public model, and the verification methodology describes useful acceptance evidence.
Incident communication and follow-up
Depending on the incident and available facts, an update may include:
- when the issue was first observed and the time zone used;
- the affected source, feed, endpoint, or product area;
- whether a backup or other connection path remains available;
- a safe client action, if one is required;
- confirmation when service is restored; and
- a later correction or post-incident explanation when that adds useful information.
Public updates do not disclose client identities, credentials, private addresses, detailed topology, or security-sensitive investigation material.
Client-specific escalation
Public status information is shared context, not a substitute for an agreed client escalation route or contractual service terms.
Alert recipients, response expectations, maintenance communication, and incident evidence depend on the client scope. Existing clients should use the written operational route agreed for their feed. Prospective clients can identify continuity and status requirements through the demo request .
A feed shaped around your setup
Need status and continuity requirements in your demo?
Start with the short form. We’ll ask by email about alert recipients, endpoint checks, escalation ownership, and acceptance evidence.