Service states
This page lets you determine which destination condition to inspect when verification or delivery does not proceed.
Before you start
- Have access to the destination in the dashboard.
- Know the configured public IP and UDP port.
- Have receiver and firewall telemetry for the same destination.
Use conditions, not invented dashboard labels
The product facts define behaviors around paid, configured, verified, changed, expired, and retained destinations. They do not currently specify a formal state enum or exact dashboard label set. Use the visible dashboard state as the interface authority and map it to the conditions described here.
Do not automate against a state name that appears only in this explanation. A destination API, webhook, and machine-readable state transition contract are not currently specified.
Paid but not configured
A purchase provides one destination for ${TERM_DAYS} days. Before configuration, the slot does not have a customer IP and UDP port pair ready for proof. The exact term-start event is not currently specified, so consult the expiration displayed in the dashboard.
Next action: prepare a public receive path, enter the IP and port, and save the pair. Allow UDP from ${SOURCE_IP} before moving to verification.
Possible symptom: the receiver has no traffic because no verified delivery target exists. Do not investigate shred decoding in this condition.
Configured but not verified
The dashboard has an IP and UDP port, but proof of control has not completed. Streaming starts only after the customer receives a challenge token at that pair and submits it in the dashboard.
Every challenge originates from ${SOURCE_IP}. Start the socket and allow that address through every firewall. Request the challenge only after the path is ready.
The exact label used for this condition is not currently specified. Treat a prompt to verify, an absent proof, or an outstanding challenge as evidence that normal delivery is not ready.
Challenge pending
A challenge request sends one UDP datagram whose payload begins with SHRED-FANOUT-VERIFY/1, followed by a destination ID and token. The token can be submitted for ${CHALLENGE_TTL_SECONDS} seconds.
Keep the receiver and capture active during this window. Request a resend when the packet is lost or the window closes. The number of resends and resend pacing are not currently specified.
Do not reuse a token from an earlier request. Token structure and reuse semantics beyond the stated window are not currently specified.
Verified with a paid term
Successful token submission proves control of the configured pair. With a paid term, this is the condition expected before normal streaming. The exact delay from verification acceptance to the first stream packet is not currently specified.
Keep the receiver bound and retain the ${SOURCE_IP} firewall rule. Verification records proof; it does not create a persistent UDP connection or monitor receiver health.
Confirm stream arrival with tcpdump and application counters. If the dashboard appears ready but packets do not arrive, inspect the network path independently.
Address changed and awaiting new proof
Changing either the IP address or UDP port requires another challenge. The new pair should be treated as unverified until its token is accepted. Each destination permits three address changes per day.
Prepare the new receiver, NAT mapping, and firewall before saving the change. Provider-side parallel delivery to the old pair is not currently specified.
When a token is accepted, confirm traffic at the new pair before removing obsolete customer rules. A rollback guarantee is not currently specified.
Expired with retained address
After expiration, the destination keeps its verified address for ${EXPIRED_RETENTION_DAYS} days. Renewal in this period does not repeat verification when the address is unchanged.
Address retention is not a statement that stream traffic continues after the paid term ends. Delivery behavior while expired is not currently specified. Renew before relying on ongoing delivery.
Use the dashboard's expiration timestamp because the exact time-zone presentation, grace period, and renewal event are not currently specified.
Beyond address retention
Behavior after ${EXPIRED_RETENTION_DAYS} days of expiration is not currently specified. The product facts do not define whether the slot, destination ID, address, or verification record is deleted, disabled, or recoverable.
Do not promise reactivation without proof after this point. Consult the dashboard and contact support with the destination ID when the behavior affects an expired slot.
Conditions not defined by the contract
Paused, suspended, canceled, deleted, payment-pending, degraded, maintenance, and disabled states are not currently specified. An operator may see an interface message, but these documents cannot assign transition rules absent from the source of truth.
Availability incidents and receiver-side outages are also not destination states. A customer socket can be closed while the destination remains verified. A firewall can block traffic while the paid term remains active.
Diagnose by condition
- Read the destination's visible dashboard state.
- Record the displayed expiration.
- Compare the configured public IP.
- Compare the configured UDP port.
- Confirm the receiver binding.
- Confirm the ${SOURCE_IP} firewall rule.
- Capture traffic from ${SOURCE_IP}.
- Compare the application packet counter.
Keep one action per diagnostic observation and record UTC timestamps. Do not change the address before preserving the current evidence because destination changes are capped.
If the challenge is absent from tcpdump, inspect routing, NAT, and firewalls. If tcpdump sees it but the application does not, inspect the local socket path. If the token is rejected, request a fresh challenge. If verified stream traffic reaches tcpdump but not the application, inspect receive capacity and bindings.
Monitor state and delivery separately
Track dashboard expiration and verification status as control-plane observations. Track packet capture, interface counters, kernel UDP errors, socket health, and application counts as delivery observations.
The product does not currently specify a monitoring API, state-change webhook, status page, polling interval, or alert threshold. Build customer alerts from available dashboard and receiver evidence without representing them as product guarantees.
Parameters
When it goes wrong
A configured destination does not stream. Example error: `verification required`.
Cause. The pair has not completed the current proof-of-control challenge.
Fix. Open the UDP path from 64.130.40.90, request a challenge, and submit its token within 600 seconds.
A verified destination has no application packets. Example error: `receiver idle: 0 datagrams`.
Cause. The destination state is ready but the customer firewall, NAT, socket, or receive path blocks delivery.
Fix. Compare a source-filtered capture with the receiver binding and counters over one UTC interval.
An expired destination is inactive. Example error: `destination expired`.
Cause. The paid term ended; retained verification does not document continued stream delivery.
Fix. Renew the unchanged pair within the documented retention period when avoiding another challenge.
Questions
- What state must a destination reach before streaming?
- The destination must have a paid term, a configured IP and UDP port, and accepted proof of control. The exact dashboard state label and activation delay are not currently specified. Keep the receiver bound and firewall open, then confirm actual stream packets rather than treating a control-plane label as receiver health.
- Does a verified state mean my receiver is healthy?
- No. Verification proves that a challenge reached the configured pair and its token was submitted. A later firewall change, NAT change, closed socket, full queue, or process failure can stop receipt without changing that proof. Monitor packets from ${SOURCE_IP}, kernel UDP errors, and application counters separately.
- What is retained after expiration?
- The verified destination address is retained for ${EXPIRED_RETENTION_DAYS} days. Renewal during that period does not require another challenge when the pair is unchanged. Stream behavior while expired and destination behavior after the retention period are not currently specified. Use the dashboard state and expiration as the current operational record.