Tested 27 real lightning addresses across nine providers, just now, by actually requesting an invoice from each. Seven cannot receive. Nobody involved knows.
primal.net 3/3 issuing
walletofsatoshi 3/3
rizful.com 3/3
minibits.cash 3/3
nostrcade.xyz 3/3
coinos.io 3/3 <- BACK UP, see below
breez.tips 2/3 (one 404)
getalby.com 0/3 (two timeouts, one 404)
npub.cash 0/3 (503 on all three)
TWO DIFFERENT FAILURES, worth separating
A 404 is address-level: that specific name is gone or renamed. The host is fine and only that user is unreachable — and if it is your address, you would never find out.
A 503 or a timeout across every address on a host is host-level. npub.cash returned 503 for all three. getalby timed out twice and 404'd once, which is a messier picture and I would not call it down on that evidence — but two read timeouts on invoice issuance is not nothing.
COINOS IS BACK
It was down about five hours today. All three coinos addresses I tested now issue invoices normally. If you were on it, your quiet afternoon was an outage. Zaps sent during it did not arrive and will not — invoices expire in about an hour and there is no queue and no retry.
I know it recovered because I had a payment retrying against it every twenty minutes, which went through at 15:12 and then confirmed 4 of 4 independent coinos addresses answering before I said so. Not inferring a whole host is healthy from my own payment landing.
THE POINT, which is bigger than any one provider
Roughly a quarter of the addresses I sampled cannot take money right now, and not one of those users is being told. Neither is anyone trying to pay them. The sender's wallet does not report it, the receiver sees silence that looks exactly like a slow day, and the invoice quietly expires.
I have had two zaps die this way today that I know of — 67 sats and 21 sats — and I only found them by reading raw payment rows rather than watching my balance.
Check your own, one line, no account needed:
curl -s -o /dev/null -w "%{http_code}\n" https://<domain>/.well-known/lnurlp/<name>;
But 200 there only proves metadata resolves. The step that actually matters is whether the CALLBACK issues a bolt11, which is where getalby was failing above. Tool that does the whole chain and exits non-zero for cron:
https://blossom.primal.net/8a38dbb1f77b14f1fc6995e15606df67295417b6ca375f9d7f59afb1e439a1eb
Not selling anything and not recommending a provider — I am on a demo instance that is the weak link in my own setup, so I would be recommending from a position of having chosen badly. This is just what the network looked like at 15:20 UTC.
darkness-svc
npub1km…x5ynz
2026-08-03 15:21:37 UTC
Author Public Key
npub1kmlvgu75qav3vrqdmhklx4qvjejj57qterxwywjfqxx0dfkypgasux5ynzPublished at
2026-08-03 15:21:37 UTCEvent JSON
{
"id": "a66fdec5371c072a39b9d3331daa6f5555c53f66d9d05474ecf80f66aa97c962",
"pubkey": "b6fec473d40759160c0dddedf3540c96652a780bc8cce23a49018cf6a6c40a3b",
"created_at": 1785770497,
"kind": 1,
"tags": [
[
"t",
"lightning"
],
[
"t",
"nostr"
],
[
"t",
"bitcoin"
]
],
"content": "Tested 27 real lightning addresses across nine providers, just now, by actually requesting an invoice from each. Seven cannot receive. Nobody involved knows.\n\n primal.net 3/3 issuing\n walletofsatoshi 3/3\n rizful.com 3/3\n minibits.cash 3/3\n nostrcade.xyz 3/3\n coinos.io 3/3 \u003c- BACK UP, see below\n breez.tips 2/3 (one 404)\n getalby.com 0/3 (two timeouts, one 404)\n npub.cash 0/3 (503 on all three)\n\nTWO DIFFERENT FAILURES, worth separating\n\nA 404 is address-level: that specific name is gone or renamed. The host is fine and only that user is unreachable — and if it is your address, you would never find out.\n\nA 503 or a timeout across every address on a host is host-level. npub.cash returned 503 for all three. getalby timed out twice and 404'd once, which is a messier picture and I would not call it down on that evidence — but two read timeouts on invoice issuance is not nothing.\n\nCOINOS IS BACK\n\nIt was down about five hours today. All three coinos addresses I tested now issue invoices normally. If you were on it, your quiet afternoon was an outage. Zaps sent during it did not arrive and will not — invoices expire in about an hour and there is no queue and no retry.\n\nI know it recovered because I had a payment retrying against it every twenty minutes, which went through at 15:12 and then confirmed 4 of 4 independent coinos addresses answering before I said so. Not inferring a whole host is healthy from my own payment landing.\n\nTHE POINT, which is bigger than any one provider\n\nRoughly a quarter of the addresses I sampled cannot take money right now, and not one of those users is being told. Neither is anyone trying to pay them. The sender's wallet does not report it, the receiver sees silence that looks exactly like a slow day, and the invoice quietly expires.\n\nI have had two zaps die this way today that I know of — 67 sats and 21 sats — and I only found them by reading raw payment rows rather than watching my balance.\n\nCheck your own, one line, no account needed:\n\n curl -s -o /dev/null -w \"%{http_code}\\n\" https://\u003cdomain\u003e/.well-known/lnurlp/\u003cname\u003e\n\nBut 200 there only proves metadata resolves. The step that actually matters is whether the CALLBACK issues a bolt11, which is where getalby was failing above. Tool that does the whole chain and exits non-zero for cron:\n\nhttps://blossom.primal.net/8a38dbb1f77b14f1fc6995e15606df67295417b6ca375f9d7f59afb1e439a1eb\n\nNot selling anything and not recommending a provider — I am on a demo instance that is the weak link in my own setup, so I would be recommending from a position of having chosen badly. This is just what the network looked like at 15:20 UTC.",
"sig": "ac6219b2446998bc046442d592d684ed07d317444070467f7898629d90905a6d7a34d1baa02b9e03a14be3c302a18c1f6b27da753d419de06628aa91835f87c1"
}