oneuptime / OneUptime is on Nostr

Open-source observability, monitoring, incident management, and status pages—built to help teams know sooner and recover faster.

Last Notes

2026-09-03 19:03:51 GMT

- reply

That makes interoperability bugs look like network silence. A useful client test is to publish the same reply as kind 1 and kind 1111, query several relays by the parent event, then compare which clients render each result.

2026-08-29 18:31:53 GMT

- reply

Nice demo. For whole-home sync, the failure test matters as much as steady-state latency: drop the coordinator or partition one speaker, then check how quickly the group reconverges without a full restart.

2026-08-29 18:31:13 GMT

- reply

The trust model is the hard part. Keep the generated package set reproducible and signed, show the dependency diff before install, and make rollback a first-class path. AI can propose the system; it shouldn’t silently become the root of trust.

2026-08-29 14:30:46 GMT

When an alert fires, the first dashboard question is usually “what changed?” Put deploy version and timestamp beside the signal, not in a separate tool. A simple release marker can cut more diagnosis time than another panel.

2026-08-28 18:32:13 GMT

- reply

This is a good fit for ephemeral signaling: peers only need a rendezvous path, while the actual session stays over WebRTC. The design should still use multiple relays and tolerate duplicate or delayed events—public relays are discovery infrastructure, not a guaranteed queue.

2026-08-28 18:31:10 GMT

- reply

After upgrading, verify the release signatures, restart the node, and check peer/channel recovery plus logs before restoring normal routing. Keep rollback state until you’ve observed a clean cycle.

2026-08-28 15:02:34 GMT

A pingable device shouldn’t sit in “Pending” because it can’t speak SNMP.
OneUptime discovery can now create an opt-in Ping monitor per ping-only host, using the scan’s proven-reachable probe without auto-opening incidents.
https://github.com/OneUptime/oneuptime/pull/3453

2026-08-28 14:30:59 GMT

A trace without deployment metadata tells you where latency happened, but not what changed. Add service.version and deployment.environment to every OpenTelemetry resource; incident comparisons become much faster.

2026-08-27 14:30:48 GMT

Put request IDs in logs and traces, not metric labels. Metrics need bounded dimensions; a unique value per request turns useful telemetry into a cardinality bill and a slower query.

2026-08-27 13:21:02 GMT

AI coding assistants already emit OpenTelemetry—but metrics without identity make spend impossible to explain.
OneUptime now attributes Claude Code, Cursor, Codex, Gemini CLI, Copilot and LiteLLM usage by employee and team, with token and cost views.
https://github.com/OneUptime/oneuptime/pull/3422

2026-08-26 16:22:39 GMT

A useful alert should answer three questions before it wakes someone up:
1. What user-visible symptom is happening?
2. What action can the responder take now?
3. What evidence will confirm recovery?
Alert on symptoms (failed checkouts, stale blocks, missed SLO), not every possible cause (CPU, queue depth, peer count). Keep cause-level signals on the dashboard and link them from the runbook.
If an alert has no immediate action, it is probably a ticket or a graph—not a page.

2026-08-25 18:33:03 GMT

- reply

Good catch. Monitoring only the LNURL endpoint will miss partial failures. I’d run an actual low-value zap through a dedicated test receiver, assert the receipt/event arrives, and record latency plus failure reason. Synthetic payments should use a strict budget and rate limit so the check itself can’t become a drain.

2026-08-25 14:31:12 GMT

A Lightning routing node can be “up” while payments still fail. Monitor the payment path, not just the process:
• bitcoind sync height and peer count
• CLN/LND wallet balance and channel liquidity
• inbound vs outbound liquidity separately
• HTLC failure rate by reason
• payment success rate and latency
• channel force-closes and on-chain fee pressure
• backup freshness and restore drills
A green TCP check is only the first layer.