Lightning Network node: why payments don't go through
Payments on a Lightning Network node rarely fail because of "the network as a whole." In most cases, failed payments are a local problem: a route exists on the map, but the required amount cannot be sent through a specific channel.
The node returns a routing error, the wallet makes several attempts and gives up—from the outside it looks like "Lightning doesn't work."
The first bottleneck is outbound liquidity. Funds in a channel are split between two parties, and you can send exactly the amount that sits on our side. If channels are opened and funded only on one side, the node can receive but cannot pay. One-sided channels do not balance themselves, and part of the capacity sits idle.
The second is "dead" channels and counterparties. A peer has gone offline, fixed a minimum reserve, or has not responded for a long time: the channel remains on the route map but carries zero.
Such channels are identified by failed-attempt statistics and closed; otherwise they pull traffic toward themselves and worsen the node's metrics.
The third is route selection. The path is built based on capacity, successful payment history, and fees, and is rebuilt on failure. An outdated graph and unfavorable fee policies make the node "invisible" or drive the flow into the weakest channels. Channel balancing and log analysis provide an accurate picture—we explain how this is configured.
What a properly configured node delivers: effect in numbers
The main metric of a properly configured node is the share of payments that go through on the first attempt.
On a node assembled "according to the instructions," it stays around two-thirds: routing tries paths that no longer exist because the graph is outdated, and channels are opened to nodes without real throughput.
After rebuilding the graph, selecting counterparties by actual throughput, and setting priorities, the payment success rate reaches 95% and above—and stops depending on the time of day.
The second effect is predictable channel throughput. The cause of failures is almost never the channel size, but a balance skew: liquidity moves to one side, and the channel stops carrying payments in the needed direction.
Periodic rebalancing, limits on outbound and inbound parts, and control of channel fill provide a steady flow without manual intervention.
The third is node downtime and channel recovery. With correct state backup and a debugged recovery scenario, the node gets back online in minutes instead of a day and does not lose open channels.
Node monitoring covers the rest: alerts about a counterparty disconnecting, liquidity exhaustion, and connection loss arrive before a customer notices the failure.
We work with Lightning Network as payment infrastructure: we configure it not just "so it starts," but so these metrics hold under load.
Node operating modes: comparison of approaches
A Lightning Network node can be hosted on your own hardware, on a rented server, or fully handed over for managed support—and this is only the first dimension of the choice.
The second is the node's operating mode: a routing node with public channels carries third-party payments and earns on fees; a private one serves only your operations.
These two decisions determine the node requirements, the amount of operational work, and how much time it will take from your team.
| Option | When it fits | Limitations | What is required from the customer |
|---|---|---|---|
| Own hardware, own support | Full control over keys and channel policy is needed | Connection failure or an update leads to disputed channel closures | Facility, backup communication channel, on-call duty, backups |
| Own hardware, support by us | Keys remain with you; there is no one to operate the node on your own | We work remotely—access and agreed update windows are needed | Access to the node and an on-call procedure |
| Rented server under our management | A public routing node is needed without your own facility | The physical perimeter does not belong to you | Approval of channel policy and limits |
Switching between modes
The requirements for the node are the same in all modes: constant network access, regular backup of channel state, and monitoring that notices a connection loss before the partner initiates a force close.
Therefore, changing the option is planned in advance, not after the fact: moving a node to a new site means closing channels and re-accumulating liquidity, whereas a second node raised in advance with the same routing policy migrates without loss of payments.
Channel and routing configuration: stages of work
First, we record the current state: where the node is hosted, which channels are open, how liquidity is distributed between inbound and outbound, and which peers generate real traffic.
Without this step, routing configuration becomes guesswork: the node formally works, but payments flow in only one direction.
- Liquidity audit. We take a snapshot of channels: the share of local and remote balance, "one-sided" channels, peers without traffic, cost of holding versus routes generated. The output is a map of where the node loses pass-through capacity.
- Opening channels. We rebuild the set for the expected flow: size and number of channels, reserve for unexpected operations, connection to nodes with stable connectivity instead of random peers. Channels that only drain liquidity are closed or moved to passive mode.
- Routing configuration. We set node policies: base and proportional fee, amount bounds, confirmation delay, splitting of large payments. Policies differ by network region and demand periods—one set for everything works poorly.
- Rebalancing. We return liquidity in the needed direction using circular payments or manual operations, controlling that the cost of restoration does not exceed income from routes.
- Load testing. We run the flow, look at the share of successful routes, response time, behavior during peaks and peer loss. We adjust parameters before the market does.
- Node handover. We hand over access, configurations and policies, monitoring with alerts, procedures for failures and updates, and instructions for changing policies without unbalancing channels.
What remains with you: configurations and procedures
A node without documentation survives only until the first failure or change of on-call engineer.
Therefore, we deliver not a "working service on a server" but a set of artifacts: using them, the node can be raised again on a clean machine and maintained without our involvement.
- Configuration files with line-by-line explanations: channel size limits, fee rules, network parameters, paths to storage and logs, connection count limits.
- Channel diagram: with which counterparties channels are open, what share of liquidity is on each side, who is the initiator, where reserve for rebalancing is left, and what to do if it is insufficient.
- Channel state backup: a snapshot of keys and channel list separate from operational backups, creation frequency, storage location, and recovery verification procedure.
- Access policies: roles, who has access to keys and secrets, how rotation works, what to do when an engineer leaves, and how rights are transferred.
- Maintenance procedure: what is checked and how often—counterparty availability, liquidity depth, successful route share, scheduled updates.
- Node documentation: addresses and entry points, set of extensions, startup and shutdown procedure, where to look at logs when investigating an incident.
- Recovery instructions: step-by-step procedure for server loss—from restoring from backup to checking routing and balances.
We accept the work together: we raise the node on a clean server strictly according to the instructions and verify that channels, liquidity, and routing have returned to working values, not just "approximately similar."
Case study: growth in payment success rate after configuration
A payment acceptance operator came with a Lightning Network node that had been running for a long time and without channel review. Liquidity gradually leaked to one side: some channels received noticeably more than they sent, while others stood empty and only occupied capacity.
The share of completed payments stayed around 70%; large amounts went into stuck payments and returned to the sender.
We captured the routing picture from logs: calculated which channels send more than they receive and where the reverse flow is already overflowing.
Then we rebuilt the topology—closed channels to small nodes without return traffic, opened high-capacity channels to hubs that have return flow, leveled the balance of existing channels with circular rebalancing, and set the routing fee so that other nodes were more willing to route payments through ours.
After rebuilding channels and enabling automatic liquidity maintenance, the payment success rate reached 95–97% and stays there without manual intervention.
Stuck transactions in daily statistics dropped to isolated cases, average payment time fell by a factor of three, and repeat payments almost disappeared.
We left monitoring with thresholds on channel balance and failure rate: the engineer receives an alert before the problem shows up in reports. This node configuration case is reproducible—before-and-after metrics are calculated from routing logs, not taken on faith.
Managed liquidity or manual balancing?
Manual balancing cannot be eliminated entirely, but reducing it to exceptions is realistic.
A channel does not stay in balance for long: the payment flow is asymmetric, the outbound part goes to one side, inbound liquidity runs out—the node stops accepting payments along that route.
That is why liquidity management in Lightning Network is a process, not a one-time setting when launching the node.
With manual balancing, the engineer tracks skews, opens channels, performs circular transfers through their own route, and pays fees for passage. With a few channels this is tolerable; with dozens, it turns into constant watch with delayed reaction.
| Option | When it fits | Limitations |
|---|---|---|
| Automatic balancing by rules | dozens of channels, changing flow | thresholds and monitoring are needed; rules require review |
| Inbound liquidity provisioning services | fast start of payment acceptance | dependence on the provider and a fee for each provisioning |
| Manual balancing by the team | 2-5 channels, predictable flow | linear growth of labor costs, human factor |
Automation does not eliminate the engineer but changes the nature of the work: rules trigger redistribution when a channel crosses a threshold, the team watches alerts and intervenes only on deviations.
Up to ten channels, manual mode is justified; beyond that, the team's labor costs grow linearly with the channel fleet, whereas automatic balancing keeps that growth many times slower.
A workable compromise is automation across the entire fleet and manual actions for large load peaks.
Technical concerns and frequently asked questions
Engineering objections to Lightning nodes are not about features but about risks: key safety, behavior during failures, and moving an already running node to managed support. Below are short answers to the ones most often raised during evaluation.
What happens to keys and channels if the node is lost?
Keys are stored encrypted and restored from the mnemonic phrase; channel state is restored from a backup file that is updated on every change. Without a fresh backup, channels are force-closed, so it is stored separately from the node, and its freshness is checked by procedure.
How does the node survive a connection loss and process failure?
In LND, the process starts automatically; a short connection loss does not close channels—payments simply do not go through.
A long loss of connection gives the counterparty the right to force-close the channel, so monitoring watches the process and network connection, and alerts about liquidity drawdown and node downtime arrive before irreversible consequences.
Can a running node be moved to managed support?
Yes, without recreating channels: inventory the configuration, transfer keys and the channel file to a prepared node with the same public key, then switch connections. Payments pause for minutes; channel reputation and routing history are preserved.
How private are payments?
In the public network, intermediaries see the fact of a transfer and the amount within the route.
Private channels and your own relay nodes hide the recipient from outside observers; we do not promise full anonymity—the goal is to prevent third parties from collecting the link between payer and recipient.
Let's discuss your task and come back with a plan
Come with a specific pain point, not a ready-made technical specification: a Lightning Network node does not carry payments, channels sit with one-sided liquidity, connections break after a restart, and there is no monitoring or clear rollback.
A description of how the node is currently set up and what result is needed is enough—by number of channels, payment volumes, and availability requirements.
What we will need from you: access to the server or an export of the configuration and logs, a list of counterparties with already open channels, and your deadline priorities. This is enough to avoid guessing on a call and immediately estimate the scope.
- Discuss the task — clarify the topology, participant roles, and what we consider success.
- Audit the current node: configuration, channel state, liquidity distribution, behavior on restart.
- Come back with a scope estimate: list of work, team composition, timelines by stage.
- Agree on the work plan: sequence of changes, checkpoints, rollback procedure at each step.
- Configure and bring the node into operating mode — with routing and liquidity control.
- Take the node under support: monitoring, channel rebalancing, incident response.
Describe the task in two or three paragraphs or leave your contacts—we will come back with an estimate, work plan, and a list of questions to close before the start.