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

LayerExample scope question
SourceIs one venue, platform source, provider session, or instrument group affected?
Pricing feedIs a specific client feed or pricing process affected?
Delivery endpointIs the primary, backup, or a regional connection path affected?
DestinationIs the client bridge, platform, FIX consumer, or its network path receiving?
Management surfaceIs 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.