Lightning Payment Failed With “No Route”? Find the Broken Side Before Retrying

A final Lightning 'no route' error means the sender could not complete a usable payment path to the recipient under the conditions of that attempt. It does not mean Bitcoin miners rejected the payment, and it is not the same as a payment that is still pending. Start by confirming the payment is finally failed. Then compare whether other recipients work, whether the same recipient can accept a smaller payment, and whether the invoice contains the routing information needed to reach private channels. Those tests usually tell you which side needs attention without exposing private channel balances.

First confirm that the payment is finally failed

Do not diagnose routing from a spinner. LND distinguishes IN_FLIGHT, SUCCEEDED and FAILED payment states, while Core Lightning exposes complete, pending and failed results. A payment that is still in flight belongs to the pending-payment workflow because existing HTLC attempts can still resolve.

A final no-route result is different from a routing timeout

Current LND documentation defines FAILURE_REASON_NO_ROUTE as a final state where all possible routes were tried and failed permanently for that payment attempt, or no routes to the destination were available. FAILURE_REASON_TIMEOUT means more routes may have existed but the configured payment timeout ended first. User-facing wallets may collapse these details into similar messages, so preserve the exact error where possible.

Core Lightning also separates no route from expensive route

Current Core Lightning documentation uses error 205 when it cannot find a way to the destination. Its older pay interface separately uses error 206 when available routes exceed configured fee or delay limits. The newer xpay interface has different presentation details, so 'route failed' should not automatically be interpreted as zero network connectivity.

Use the Route Failure Isolation Grid

Run three comparisons after the original attempt has a final failed state.

• Test A — Sender breadth: can the same wallet successfully pay a different Lightning recipient?
• Test B — Amount sensitivity: can the intended recipient accept a meaningfully smaller payment when the recipient can legitimately issue a smaller invoice?
• Test C — Route conditions: is the invoice valid, are private-route hints present when needed, and are fee or route restrictions unusually tight?

Verdict 1 — other recipients fail too: inspect the sender edge

When several unrelated Lightning destinations fail from the same self-hosted node, local outbound liquidity, inactive channels, peer connectivity, graph synchronization or restrictive routing configuration becomes more plausible. For a custodial or LSP-backed wallet, those controls belong to the provider, so the user should inspect provider status or contact support rather than trying to rebalance channels they do not control.

Outbound liquidity is the sender's ability to push value into the network

Lightning Labs defines outbound liquidity as capacity available for sending. A channel's total capacity is not the same as the amount currently spendable in the outgoing direction. As payments move through a channel, local and remote balances shift.

A wallet balance can be larger than the amount routable right now

A node can show enough total Lightning balance while the usable outbound amount is fragmented across channels, reduced by reserves or unavailable through active paths. Do not compare only the invoice amount with a top-level wallet balance and conclude that routing must work.

Self-hosted LND users should inspect active channel liquidity

For node operators, list active channels and examine local balances rather than only total channel capacity. Lightning Labs' liquidity documentation explains that local channel balance represents the side available for sending, subject to reserves and other channel constraints.

One poorly placed channel can make a well-funded node a poor sender

Opening a channel gives a node outbound capacity toward that peer, but routing quality also depends on where that peer connects and whether downstream channels can carry the payment. Core Lightning's current FAQ notes that opening more channels can increase available route diversity when route failures are persistent.

Do not open a new channel after one failed coffee payment

A single route failure can reflect temporary liquidity elsewhere in the network. Opening a channel costs an on-chain transaction and changes long-term node topology. First repeat the isolation tests and inspect existing channel activity. Channel management is justified by a persistent pattern, not one failed attempt.

Verdict 2 — other recipients work but this recipient fails: inspect the receiver edge

If the same sender can successfully pay unrelated Lightning destinations but repeatedly cannot reach one recipient, the last part of the route becomes more suspicious. The receiver may lack enough inbound liquidity, be offline or poorly connected, or depend on private channels whose routing information is absent or stale.

Inbound liquidity is the recipient's ability to accept value

Lightning Labs defines inbound liquidity as capacity available for receiving. A merchant or self-hosted receiver that has accumulated funds on its side of channels can exhaust the remote-side capacity needed for additional incoming payments even though the node still has bitcoin.

The payer cannot directly see every channel balance

Lightning routing intentionally does not publish directional channel balances. Lightning Labs explains that hidden balance distribution is a privacy feature and a primary reason route attempts can fail: a channel can advertise enough total capacity while lacking enough balance in the needed direction at that moment.

That is why a public graph cannot prove a route will carry your amount

A graph explorer can show nodes, public channels and announced capacities, but it cannot reliably prove current directional liquidity through every hop. Treat public topology as structural evidence, not a live balance sheet.

Private receiving channels need invoice routing information

LND's current receiving documentation says a node using private channels can include routing hints in a BOLT11 invoice. It explicitly notes that if the receiving node has only private channels, the invoice must include those hints or payments will not succeed. A fresh invoice can therefore matter when the recipient's private routing information changed.

Do not manually invent route hints as an ordinary payer

Route hints describe how to reach a non-public part of the recipient's topology. They should come from the receiving node's invoice or supported payment protocol. A normal user should request a fresh invoice from the recipient rather than copying channel IDs from a forum or guessing a last hop.

Verdict 3 — small works but large fails: treat amount as the bottleneck

If the same sender can pay the same recipient at a smaller legitimate amount but a larger invoice repeatedly fails, the available end-to-end liquidity for the larger amount is a strong suspect. Every route part must fit through channels with sufficient directional liquidity and policy limits.

Do not underpay a fixed invoice just to test routing

A fixed-amount BOLT11 invoice expects its encoded amount. If the merchant or recipient can issue a smaller test invoice, use that. If the invoice is amountless, enter an agreed smaller amount. Do not alter a fixed merchant invoice or assume that sending only part of it will count as payment.

Multi-part payments already solve some fragmentation automatically

Modern Lightning payment implementations can split a payment into multiple parts when the invoice and endpoints support the required features. That can combine liquidity across routes, but it does not create liquidity that does not exist. If the aggregate usable paths cannot carry the amount, the payment can still fail.

A larger payment has fewer viable route combinations

Each path has to satisfy directional balance, HTLC size and policy constraints at every hop. Increasing the amount eliminates paths that could carry a smaller payment. This is why '10,000 sats worked but 500,000 sats failed' can be meaningful evidence even when both endpoints are otherwise healthy.

Verdict 4 — check whether a fee limit is excluding routes

A route can exist but be outside the payer's allowed fee budget. Current LND SendPaymentV2 documentation warns that its API's default routing fee limit is zero unless a non-zero fee limit is set, which can cause FAILURE_REASON_NO_ROUTE because only zero-fee routes are attempted. This is mainly a node or application-integration issue; consumer wallets usually manage their own limits.

Core Lightning has explicit fee and delay constraints

Core Lightning xpay accepts a maxfee limit, while the older pay command separately documented route-too-expensive failures for fee or maximum-delay constraints. If you operate your own node or integration, record the configured fee and CLTV limits before concluding that the network has no physical route.

Do not solve a Lightning no-route error by raising the Bitcoin miner fee

A normal Lightning payment routes through existing payment channels and pays routing fees to forwarding nodes. Bitcoin miner fees are relevant when opening, closing or otherwise modifying channels on-chain, not as a direct knob for making one ordinary multi-hop Lightning invoice find a route.

Route fee and on-chain fee are different budgets

If the payment system rejects routes because its Lightning routing-fee limit is too low, adjust the Lightning fee policy only if you understand the cost. Increasing an on-chain transaction fee does not change the directional liquidity of already-open Lightning channels.

Verdict 5 — one retry later can work without anyone 'fixing' the network

Lightning liquidity is dynamic. Lightning Labs' routing documentation explains that failures caused by channel-balance distribution can resolve later as other payments move liquidity in the opposite direction or node operators rebalance. A later success does not prove the original error was false.

But repeated blind retries are weak diagnostics

A wallet's pathfinder already tries alternative routes according to its own policy. Repeatedly pressing Pay against the same unchanged conditions may only reproduce the same result. After one or two final failures, change one diagnostic variable: recipient, amount, invoice or provider status.

Mission Control learns from failed LND routes

LND's Mission Control records success and failure information from payment attempts and uses it to improve later path selection. That is another reason manual route guessing is usually worse than allowing a modern payment engine to retry and learn from failed channels.

A fresh invoice helps only when invoice state is part of the problem

Request a fresh invoice if the old one expired, the recipient changed its private-channel hints, the checkout session changed, or the recipient explicitly asks you to refresh. A fresh invoice does not manufacture outbound liquidity at the sender or inbound liquidity at the receiver.

Do not confuse no route with an expired invoice

Core Lightning documents separate failures for unable to find a route and invoice expired. If the invoice is expired, replace it through the recipient. If a fresh valid invoice again fails with no route, return to liquidity and routing diagnosis rather than generating invoices indefinitely.

Do not confuse no route with a pending payment

A final no-route failure means the payment engine has stopped trying for that payment attempt. An IN_FLIGHT or pending payment has unresolved HTLCs and can still settle. The existing pending-payment guide owns that state and specifically warns against creating a duplicate payment before final resolution.

Do not confuse no route with insufficient wallet balance

LND exposes FAILURE_REASON_INSUFFICIENT_BALANCE separately from FAILURE_REASON_NO_ROUTE in current route-estimation tooling. A custodial wallet may use less precise wording, but a self-hosted node should distinguish not enough local funds from an inability to construct a viable end-to-end route.

Do not confuse no route with destination rejection

Core Lightning and LND distinguish routing failure from permanent or incorrect-payment-details failures at the destination. A recipient that rejects the payment hash, amount or invoice details is not the same problem as pathfinding that cannot reach the recipient.

For a custodial wallet, diagnose with outcomes rather than channel commands

A custodial Lightning wallet or exchange owns its channels, peers, pathfinder and liquidity. The user usually cannot inspect or rebalance them. Record the invoice, amount, exact error and whether another Lightning recipient succeeds. That evidence is more useful to support than asking for a channel command the user cannot run.

If every payment from a custodial provider fails, check provider status

A provider-wide outage, disabled Lightning service or liquidity incident can look like repeated routing failure from the user's perspective. Use the provider's official status or support channel. Do not move seed phrases or private keys into a different app just to diagnose a custodial service.

If one merchant fails but another works, tell the merchant what the comparison proved

Give the recipient the failed invoice, payment amount, time and exact final error, and state that another Lightning payment from the same wallet succeeded. A self-hosted merchant can then inspect inbound liquidity, peer health and private route hints instead of asking the payer to raise a Bitcoin miner fee.

For node operators, EstimateRouteFee can test reachability without a real settlement

Current LND documentation describes EstimateRouteFee as a probe that searches for a viable route and estimates routing fees. For public destinations it can use a node pubkey and amount; for private destinations a BOLT11 invoice is required. A failure reason other than NONE means the probe did not find a usable route within its conditions.

A route probe is diagnostic, not a guarantee

Lightning Labs notes that channel policies or liquidity can change between a successful probe and the real payment. A successful estimate means a route looked viable at that moment; it does not reserve that route or its liquidity for the later transaction.

Use five final routing verdicts

Finish the diagnosis with one state.

• SENDER EDGE — unrelated recipients fail too; inspect outbound liquidity, active channels, provider status or sender configuration.
• RECEIVER EDGE — other recipients work but one destination repeatedly fails; recipient inbound liquidity, uptime or private route hints need attention.
• AMOUNT BOTTLENECK — a legitimate smaller invoice works while the larger one fails; end-to-end liquidity or HTLC constraints are amount-sensitive.
• ROUTE POLICY — fee, delay or route-selection limits exclude otherwise possible paths; adjust only the relevant Lightning setting.
• DYNAMIC / UNKNOWN — the route works intermittently and no stable local or receiver fault is proven; preserve evidence and retry after conditions change.

The practical no-route sequence

Use this order after the wallet reports a final failure.

• 1. Save the BOLT11 invoice or payment request, amount, time and exact error.
• 2. Confirm the payment is FAILED rather than pending or in flight.
• 3. Confirm the invoice is still valid and was not already paid.
• 4. Try a different legitimate Lightning recipient from the same sender.
• 5. If the recipient permits it, compare with a smaller fresh invoice rather than underpaying the original.
• 6. For self-hosted nodes, inspect active outbound liquidity, peers and routing limits.
• 7. For a receiver using private channels, request a fresh invoice with correct route hints.
• 8. Do not raise an on-chain Bitcoin fee as a routing fix.
• 9. Escalate to the side indicated by the comparison tests.

Why this page is separate from the pending-payment article

The pending article begins while the payment has unresolved HTLC state and asks whether it will settle or fail. This page begins only after the routing engine has produced a final no-route failure. Its success state is locating the routing bottleneck and creating a safer next attempt.

Why this page is separate from the expired-invoice article

The expired-invoice article asks whether the BOLT11 request is still valid and whether an older attempt can still settle. A valid invoice can still fail because no route has enough usable liquidity. Replacing an unexpired invoice is therefore not the default answer to a no-route error.

What can change after August 8, 2026

Wallet error labels, pathfinding algorithms, default fee limits and node RPCs can change. Core Lightning is actively moving from older pay and renepay interfaces toward xpay. The durable diagnosis remains: confirm final failure, compare sender breadth and amount sensitivity, verify receiver routing information, and separate Lightning route limits from on-chain Bitcoin fees.

Sources checked on August 8, 2026

Primary Lightning implementation and protocol documentation was prioritized over generic troubleshooting pages.

• Lightning Labs — Sending Payments — https://docs.lightning.engineering/lightning-network-tools/lnd/payments
• Lightning Labs — SendPaymentV2 — https://lightning.engineering/api-docs/api/lnd/router/send-payment-v2/
• Lightning Labs — Probing with EstimateRouteFee — https://docs.lightning.engineering/lightning-network-tools/lnd/probing-with-estimateroutefee
• Lightning Labs — Receiving Payments and private route hints — https://docs.lightning.engineering/lightning-network-tools/lnd/receiving
• Lightning Labs — Managing Liquidity — https://docs.lightning.engineering/the-lightning-network/liquidity/manage-liquidity
• Lightning Labs — Managing Channel Liquidity — https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/channel-liquidity
• Lightning Labs — LND pathfinding mechanism — https://lightning.engineering/posts/2024-04-11-pathfinding-1/
• Core Lightning — xpay — https://docs.corelightning.org/reference/xpay
• Core Lightning — pay — https://docs.corelightning.org/reference/pay
• Core Lightning — Troubleshooting & FAQ — https://docs.corelightning.org/docs/faq
• Lightning BOLTs — BOLT #4 Onion Routing — https://github.com/lightning/bolts/blob/master/04-onion-routing.md
• Lightning BOLTs — BOLT #11 Payment Encoding — https://github.com/lightning/bolts/blob/master/11-payment-encoding.md

FAQ