louislam

How we monitor websites and servers before problems reach customers Short answer We monitor websites and servers on several levels: whether the site responds from the outside, how loaded the server is, what the logs say and whether backups exist. The goal is to learn about a problem from our own monitoring, not from a client calling to say the site won't load. We use Uptime Kuma for external website checks, aaPanel's built-in monitoring for a quick look at the server, and Prometheus with Grafana for external service checks, metric history and alerts. None of them is enough on its own. Together they answer different questions. What "before it reaches customers" means When we say customers, we also mean our clients' customers. The person who can't complete an order. The enquiry that never reaches anyone. The page that takes 15 seconds to load, so the visitor closes the tab. Some problems appear suddenly. Many others give warning signs. A disk fills up over weeks. An SSL certificate has an expiry date. Load grows gradually until one day the server can't keep up. If those signs are visible in time, there is room to react calmly instead of in a rush. What we monitor Does the site respond from the outside This is the first level, and we handle it with Uptime Kuma. It checks websites at regular intervals from an external point in the network, not from the server itself, and raises a signal when one stops responding. That is not the same as a real visitor with a browser, but it shows whether the site is reachable from the outside. There is one important detail here. A site can return an "everything is fine" response and still show an error page, a blank page or a hosting notice. So the check can also look for specific text on the page, not just whether the server answered. Uptime Kuma also tracks SSL certificates. An expired certificate stops visitors just as effectively as a server outage, and it is completely predictable. Mail and service certificates The website is not the only service that has to work. Mail has certificates too, often on several ports at once. For those we use Blackbox Exporter together with Prometheus. It connects to the services from the outside and checks which certificate each one actually presents. The example further down shows why that matters. How the server is doing For a quick look at VPS servers we use aaPanel's built-in monitoring: load, CPU, memory, disk. It is the first place we open when something looks off. We wrote more about why we work with the panel in Why we use aaPanel for VPS servers. A snapshot is not enough, though. That is why we also run Prometheus, which collects metrics at regular intervals and keeps their history, and Grafana, which shows them on dashboards. History answers questions a snapshot can't: - Is the disk filling up gradually, and when will it run out of space?- Is this load normal for this time of day, or is it new?- When exactly did the problem start, and what changed at that moment?### What the logs say A site can work for most visitors and still throw errors on specific pages or for specific actions. Web server and application logs often show the problem before anyone notices it. When there is a signal, they are the first place we look for the cause. Are there backups Backups are not monitoring in the narrow sense, but they are part of the same care. Having a backup job is not enough. It has to be clear what is backed up, where the copies are stored and whether a restore has been tested. A backup nobody has tried to restore is an assumption, not a safety net. Alerts worth reading Monitoring without alerts means someone has to watch the dashboards all the time. Alerts without restraint mean that a week later nobody reads them. So we set up alerts around a few principles: - A signal for something that needs action. A short load spike that clears on its own is not a reason for concern.- Thresholds with duration. A site that fails one check may be network noise. A site that fails several checks in a row is a problem.- A warning before the failure. A disk at 85% is a warning. A disk at 100% is already an outage.- Checking the signal itself. Sometimes the problem is in the check, not the service, for example a DNS timeout during the check itself. Monitoring that raises false alarms often teaches people to ignore signals. So we also keep an eye on how reliable the monitoring is.Both Uptime Kuma and Grafana have their own alerts. Grafana Alerting lets you write rules on the same metrics you see on the dashboards. That way the alert and the chart you use to check it are talking about the same thing. Example: a certificate the checks caught In mid-October our external checks flagged a mail problem on one of the domains we look after. The ports used for sending mail (465 and 587) were failing the TLS check, while IMAP on port 993 worked normally. The cause was a wrong SNI configuration in Postfix. SNI is how the server tells which domain a connection is for and which certificate to present. The certificate itself was fine, but the service was presenting the wrong one. We corrected the configuration and the checks passed. This kind of problem stays invisible if you only watch whether the site loads, or only when the certificate expires. That is why we check from the outside which certificate each service actually presents. How we get to the cause An alert tells you there is a problem. It doesn't tell you why. When a signal comes in, we look at when it started, what the metrics show around that moment and what the logs say. The metric history we review in Grafana often gives the answer: a deployment, growing traffic, a process eating memory, a scheduled job that started at the wrong time. For part of the diagnosis we are building our own tool, WebComa Infrastructure MCP. It uses the Model Context Protocol to give an AI assistant a set of predefined tools: information about servers, system services, logs, network connectivity and Prometheus metrics. For example, when a service is reported as unreachable, it helps us bring together the state of the server and the relevant system service, the available logs and the related metrics in one place. Instead of a series of separate manual checks, we use predefined tools with limited access. What exactly is available depends on the permissions and the checks enabled for each environment. This is not open access to the servers. The tool works with limited permissions and approved sources. Operations that change anything are the exception, they are tightly scoped and require explicit approval. We are developing it step by step. New capabilities go through a test environment before we use them in real work. The roles stay clear: monitoring detects the deviation, the tool helps gather context, and a specialist decides what to do. What technical monitoring cannot see Every dashboard can be green while the business is losing money. The site responds, the server is calm, but: - the enquiry form doesn't send emails;- card payments fail on the payment provider's side;- the integration with a courier or warehouse has stopped;- after a change on the site, tracking has stopped collecting data.Technical monitoring sees the infrastructure. It doesn't see whether orders and enquiries are coming in. For an online store or a site that generates enquiries, it makes sense to check business signals separately, for example whether orders have arrived within a normal period or whether a key event is still being recorded. That is a setup for the specific project and business, not something standard monitoring provides on its own. There are other limits too. When a site is hosted by the client and we have no access to the server, we can only monitor it from the outside. Monitoring also doesn't prevent problems. It shortens the time between when they appear and when someone reacts. What an owner can check You don't need to be technical to ask the right questions of whoever maintains your website: - Who finds out first if the site goes down: you, your customer or someone who is watching it?- When do the SSL certificate and the domain registration expire, and who renews them?- Are there backups, where are they, and when was a restore last tested?- Is there a history of server load, or does anyone only look at the moment something happened?- Who checks that forms and orders actually reach you?If the answer to most of these is "I don't know", now is a good time to find out. Some of them are also covered in Before launch: technical foundation, SEO and maintenance. Conclusion Monitoring is not one program but several layers that answer different questions. Uptime Kuma tells you whether the site is reachable. aaPanel gives a quick view of the server. Blackbox Exporter checks services and their certificates from the outside, Prometheus keeps the results and metrics over time, and Grafana displays them and raises alerts when something drifts. Logs and our internal tools help us get to the cause. This monitoring is part of our website maintenance subscription and online store support. If you want to know where your website or server stands, we can start with a hosting and infrastructure review. Originally published on the WebComa blog.

Uptime Kuma Docker Setup: What I Change Before Trusting It I found out a client's site had been down for six hours the way nobody wants to: the client told me. A WhatsApp message at breakfast, one line, no greeting. The server was fine. A certificate renewal had failed quietly, the browser was throwing a full-page warning, and my only monitoring was me occasionally opening the site and thinking "looks okay." That was the week I stopped treating monitoring as a someday task. I wanted something I could host myself, that cost nothing per monitor, and that I could set up in an evening. Uptime Kuma fit. It is also very easy to install badly, which is the part most tutorials skip. Short version for the impatient: the default Docker setup works, but I change four things before I trust it with a client's name on the status page. Where it runs, who can reach port 3001, how I get alerted when the monitor itself dies, and what I do with the data folder. The rest of this post is those four, in the order I get bitten by them. What the default compose file gives you The project's README shows the fastest path: make a folder, download a compose.yaml, run docker compose up -d. I checked the file as it stands today and it is short. services: uptime-kuma: image: louislam/uptime-kuma:2 restart: unless-stopped volumes: - ./data:/app/data ports: - "3001:3001" That's the whole thing. One container, one bind mount for state, one port. It pins to the major version 2 tag, so you get minor updates when you pull but not a surprise jump to a different major release. I like that default. I have been burned by latest before, and not only with this tool. What you get on first launch is a pleasant surprise if you have used paid monitors. HTTP and keyword checks, TCP, ping, DNS, a push monitor for cron jobs, and a Docker container monitor. Check intervals go down to 20 seconds. Notifications can go to Telegram, Discord, Slack, email and, according to the README, more than 90 other services. Multiple status pages, each mappable to its own domain. That covers what most small agencies pay a monthly fee for. The setup is fine for a laptop. It is not fine for a VPS with a public IP, and the reason is on the ports line. Port 3001 is open to the world Writing "3001:3001" in a compose file binds the port on every network interface. The README says as much: Uptime Kuma is now running on all network interfaces. On a home machine behind a router, nobody cares. On a Hetzner box with a public address, you have just put an admin login on the internet at a predictable port, and the first thing the setup screen asks you to do is create the admin account. I have seen people leave that screen open for a day. Whoever loads it first becomes the admin. That is a bad race to run. The README mentions the fix itself: limit exposure to localhost. In compose terms that is one extra prefix. ports: - "127.0.0.1:3001:3001" Now the container only answers on the loopback interface. To reach the dashboard you need something in front of it. I use a reverse proxy with automatic certificates, and if you are choosing between the common options, I wrote up how Caddy and nginx compare on a small VPS. The Caddy config for this is two lines: the hostname, then a reverse_proxy 127.0.0.1:3001. Done. If you would rather open no inbound ports at all, a tunnel works too. I covered that route in the Cloudflare Tunnel post. Either way, the dashboard belongs behind a hostname with TLS, not an IP and a port number. One more thing on the first-run screen. Create the admin account immediately, pick a long passphrase, and turn on two-factor auth. The README lists 2FA as a built-in feature, so there is no excuse. It takes a minute and it removes the most likely way someone else ends up owning your monitor. The monitor cannot watch itself die This is the mistake I made first, and it is the one that matters most. If Uptime Kuma runs on the same server as the sites it watches, then a dead server takes out both the sites and the thing that was supposed to tell you. Your phone stays silent. Silence looks exactly like "everything is fine." I only noticed my version of this because a test outage produced zero alerts, which was embarrassing, since I had caused the outage on purpose. There are two fixes, and I use both. The first is location. Run Uptime Kuma on a different provider or at least a different machine from the thing it watches. A cheap second VPS in another datacenter is enough. It does not need much: the process is a single Node app with a small database behind it, so it will sit comfortably on the smallest plan most providers sell. If your sites are on one host, put the monitor somewhere else. That is the entire rule. The second is a heartbeat going the other way. Uptime Kuma has a push monitor type: instead of the tool calling out to a URL, something calls in to a URL it generates, and if the call stops arriving, the monitor goes red. I point a tiny cron job at it from the box that runs Uptime Kuma, and I watch that push monitor from a free external ping service. Now if the monitor machine dies, something else notices. It sounds like turtles all the way down, but you only need one level of it. A free tier at an outside service is plenty for a single check. A smaller version of the same mistake: alerts that go to an email address on the domain you are monitoring. When the mail server is down along with everything else, the alert never lands. Send to Telegram, or a personal address on a different domain. I use a Telegram bot for anything urgent because the notification arrives on my phone within seconds and I cannot sleep through it as easily as an email. Tuning the checks so you trust the alerts A monitor that cries wolf gets muted. A muted monitor is worse than none, because you think you have coverage. My first week I left every check at the lowest interval and every alert on the first failure. A single dropped packet paged me at 3 a.m. The fix is dull. Set retries to 2 or 3 before a monitor flips to down, and keep the interval at a minute for client sites, longer for anything internal. A 20-second interval is available, and I use it for exactly one thing, a payments endpoint where thirty seconds of downtime has a price. Check what the monitor actually checks, too. An HTTP monitor that accepts any 2xx will happily report "up" for a site that now serves a blank page or a maintenance banner. For client sites I switch to a keyword monitor and look for a string I know sits in the footer or the page title. If the string disappears, the page broke, even when the server still answers 200. That one change caught a broken deploy for me before the client noticed, which made up for the six hours of embarrassment. Certificates deserve their own monitor. Uptime Kuma shows certificate info and can alert before expiry. Turn it on for every HTTPS check. It would have saved me that breakfast message. Backups and updates for the data folder Everything the tool knows lives in the ./data directory from the compose file: the database, your monitors, your notification settings. Lose it and you rebuild by hand from memory. The README also warns that network file systems like NFS are not supported for this path, so keep it on local disk or a normal volume. I back that folder up with the same job that handles the rest of my small servers, a nightly copy off the machine. If you have not set one up, the Docker Compose services reference is where I would start for understanding how the bind mount and restart policy fit together. The unless-stopped policy in the default file means the container comes back after a reboot, but it will stay down if you stopped it on purpose. That is the behavior I want. For updates I do it manually and on a schedule. Pull the new image, recreate the container, look at the dashboard, done. The project keeps update instructions on its wiki, and I read the release notes before any major jump. Because the compose file pins to the major tag, a routine pull stays inside version 2. Do one restore test, even a rough one. Copy the data folder to a scratch machine, start a container against it, and confirm your monitors show up. Mine took ten minutes and found that I had forgotten to include the folder in the backup job at all. I would much rather learn that on a Tuesday afternoon than during an outage. What I would do this week If you run client sites and have no monitoring, set up Uptime Kuma on a machine that is not the one hosting those sites. Bind it to localhost, put it behind a hostname with TLS, and create the admin account with 2FA before you do anything else. Add one keyword monitor and one certificate check per site, then route alerts to Telegram. Then break something on purpose. Stop a site, wait for the alert, and time how long it takes to reach your phone. If it never arrives, you just found the real work. I do this kind of setup for small teams as part of my freelance engineering work, and the failed test alert is the single most common thing I find on day one. --- Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Your monitor is reporting its own network problems There is an issue in Uptime Kuma with 106 comments. It was opened in August 2021, the project has since passed 93,000 stars, and the label is still bug. > Lots of 'timeout of 48000ms exceeded' during the day, but the site is still up? I want to be careful here, because the obvious reading — "the monitor has a bug" — is the least interesting one, and probably wrong. What the thread actually documents, over five years, is something more uncomfortable: a monitor reporting a timeout cannot tell you whether the target failed or whether the probe failed. Those are different events. They arrive as the same string. The 48 seconds First, where the number comes from, because it is not arbitrary. In server/model/monitor.js: if (!this.timeout || this.timeout <= 0) { this.timeout = this.interval * 0.8; } The default check interval is 60 seconds, so an unset timeout becomes 48 — 80% of the monitoring window. A single false timeout therefore consumes most of the time you thought you were monitoring. There is a second timer too, ten seconds later: signal: axiosAbortSignal((this.timeout + 10) * 1000), So the request is killed by axios at 48s and by an abort signal at 58s. Whichever fires first names the error. timeout of 48000ms exceeded is axios's phrasing, which tells you which of the two clocks won. Three ways a connection fails, and only one of them is noisy I went looking for why a monitor would report 48 seconds when the site answers in under one. Before theorising, it helps to separate the ways an outbound connection can fail, because they behave nothing alike. Measured on a Linux host, socket.connect() with a 5-second timeout: | Target | Elapsed | Result | |---|---|---| | 127.0.0.1:9 — closed port | 0.00s | ECONNREFUSED, immediately | | 2001:db8::1 — no route at all (inside a default Docker container) | 0.00s | ENETUNREACH, immediately | | 198.51.100.1 — routed, packets dropped | 5.00s | timeout, no error | | 2001:db8::1 — routed via default gateway, packets dropped | 5.00s | timeout, no error | The distinction that matters is between the first two rows and the last two. A refused connection and a missing route both return an error. The kernel knows immediately and says so. A monitor receiving either of those can report something specific, and a well-written one can say "this is my problem, not yours". A blackholed path is different. There is a route. Packets leave. Nothing comes back, and nothing tells you they were dropped. TCP will retransmit into the void until something above it gives up. The only thing that ever happens is the clock running out. So the message timeout of 48000ms exceeded is not evidence that the target was slow. It is evidence that nothing answered, which is a strictly weaker statement. Why IPv6 is the usual suspect here The thread has an unusually good summary comment from raabmar in June 2025, pulling together four years of reports. The recurring factor: > Cloudflare has definitely something to do with it. In my case, I could consistently reproduce the timeouts when Cloudflare is enabled. Pausing Cloudflare immediately solved it. And a root cause offered by Buco7854 in June 2026: > The fix for me was to add this to the Uptime Kuma service in my docker compose: sysctls: - net.ipv6.conf.all.disable_ipv6=1 > > The theory is that Cloudflare proxied sites return both IPv4 (A) and IPv6 (AAAA) records. Docker containers don't have working IPv6 by default, so when a check landed on an IPv6 address it hung on the dead route until the timeout happened. That is a plausible mechanism, and the plumbing supports it. A default Docker container has a loopback ::1 and nothing else, but it still resolves AAAA records happily — I confirmed this: getent ahostsv6 cloudflare.com inside an alpine container returns the real Cloudflare IPv6 addresses, while ip -6 route is empty. DNS answers a question about the outside world. The routing table answers a question about this machine. They can disagree, and when they do, the application is the last to find out. The part that makes it hard to fix Here is where I would push back gently on the comment above, and where the thread's five years of frustration starts to make sense. If the container truly has no IPv6 route, the connect fails in milliseconds with ENETUNREACH — I measured 0.00s. Node's autoSelectFamily (Happy Eyeballs) is enabled in the current source: const httpsAgentOptions = { maxCachedSessions: 0, rejectUnauthorized: !this.getIgnoreTls(), secureOptions: crypto.constants.SSL_OP_LEGACY_SERVER_CONNECT, autoSelectFamily: true, ...(agentFamily ? { family: agentFamily } : {}), }; and it would fall back to IPv4 within 250ms. A route that is missing fails fast; a fallback that exists gets used. That combination does not produce a 48-second wait. A blackholed route does. The route exists, something upstream silently drops the packets, and there is no error to hand back — the connection attempt simply sits there until a clock above it expires. So I built the three scenarios and timed them, using a local listener as the known-good address and a routed-but-dropped address as the blackhole: | Addresses returned | Result | |---|---| | IPv6 blackholed + IPv4 working | connected in 259 ms | | IPv4 working + IPv6 blackholed (other order) | connected in 2 ms | | IPv6 blackholed only, no IPv4 | timeout at 48,048 ms | That table is the interesting part, because it undercuts the simplest version of the theory. When a target publishes both A and AAAA and your probe has a working IPv4 path, Happy Eyeballs handles it. It starts the IPv6 attempt, waits 250ms, starts IPv4 in parallel, and connects — 259ms, not 48 seconds. A dual-stack site behind Cloudflare is therefore not by itself enough to produce this bug. For the 48-second case you need the probe to have no working alternative to fall back to: an IPv6-only target, or an IPv4 path that is also broken, or a monitor pinned to ipFamily: "ipv6" — which the code supports: if (this.ipFamily === "ipv6") { agentFamily = 6; } Which is why I suspect the thread contains more than one bug wearing the same error message. Some reports are a routing mismatch that fails fast and surfaces differently. Some are a genuinely blackholed path. Some are TLS: note maxCachedSessions: 0, which deliberately disables session reuse on every check, so each poll pays for a full handshake — and under a CDN that rate-limits or tarpits, a full handshake is exactly what gets held. And some are the site genuinely being slow. Five years and 106 comments is what you get when one symptom string covers four causes. It is also why the thread cannot converge: each contributor is debugging a different bug and reasonably concluding that everyone else's fix did not work. The general shape Step back from Uptime Kuma and this is a pattern that shows up wherever infrastructure reports on itself: A signal that reports the probe's view of the world, labelled as a fact about the target. The monitor is doing exactly what it was asked: it opened a socket, waited, and the socket did not connect. It is not lying. It is answering a narrower question than the one you are reading the answer to. I hit the same class of thing in a completely different tool last week. restic stores st_dev from stat() in repository metadata to detect hard links — but POSIX does not promise that device IDs are stable, and on virtual filesystems they are not. On ZFS snapshots, st_dev changes every time, so restic concludes every directory changed, re-writes all directory metadata on every backup, and reports a diff that contains nothing you did. That issue is open since 2020 with 111 comments. As kakra put it there: > inode and devid are not stable IDs, they should not go into the metadata storage of the repository — never ever. Same shape. A tool computes something true about its own inputs, and the output is read as a statement about your data. What actually helps If you run a monitor, the useful question is not "did it time out" but "which of the three failure classes was that". A few things worth doing, in order of cost: Distinguish the error classes in your alerting. A connection refused is a target that is up and not listening. ENETUNREACH is your probe. A timeout is unknown until you investigate further. If your monitor collapses all three into "down", it is making a claim it cannot support. Check that your probe can reach the family it prefers. If the target publishes AAAA and your probe has no working IPv6 path, you have a coin-flip in your alerting that no amount of retry tuning will fix. Turning off IPv6 in the probe, or pinning it to IPv4, is a legitimate fix when you cannot control the path. Watch the ratio, not the incident. One timeout among a hundred checks is noise. Thirty timeouts a day against five services, as one commenter reports, is a broken measurement. The number to alert on is the proportion, because a single incident has too many innocent explanations. Time the failure modes against each other. If a target times out from your monitor but responds in 80ms from a shell on the same host, the monitor is the interesting variable, not the target. What I am doing about it I keep running into this from the other side, because I build a small server audit tool that answers "is anything about to break" and "did last night's backup actually run". Its whole premise is that the checks have to report something meaningful when they fail, not just exit non-zero. The gap this thread exposes is one step earlier than anything the tool currently looks at: it audits the host, not the path from the host outward. So I am adding an eleventh check to it, called alert path verification. Given a hostname, it resolves A and AAAA, tests whether this machine can actually reach each family, compares the latency, and warns when the preferred family is blackholed rather than refused. The point is not to detect outages. It is to tell you whether your monitoring could have detected one. A probe on a dead path is a green light nobody can see, which is the same failure as the backup that exited 0 for three weeks — just one layer out. --- The Uptime Kuma issue is #275 and remains open. The restic one is #3041. Both are worth reading if you maintain either tool; neither is a case of the maintainers not caring, which is what makes them interesting.

Monitoring Scheduled Imports Safely — A Practical Health Check Decision Guide Short answer: the top tools for backend task monitoring and health check APIs split the job three ways. Use a task monitor for “did the import run?”, an HTTP monitor for “is the service reachable?”, and metrics for “is it behaving normally?”. For a marketplace, rollback safety matters more than one dashboard. Keep the import’s last successful result separate from the deployment that produced it. The choice matrix for scheduled imports | Tool | Best fit | Boundary | | --- | --- | --- | | Healthchecks.io | Missing cron or background-task heartbeats | Not general HTTP uptime or metrics | | Upptime | Open-source HTTP uptime checks | Not task-level result quality | | Uptime Kuma | Self-hosted HTTP and service checks | Not metrics analysis | | Prometheus + Grafana | Metrics, alerting, and visualization | Requires instrumentation and operations | | Infrai | Querying logs and metrics through one REST surface | No alert or heartbeat route | My default is a combination: Healthchecks.io for the scheduled import heartbeat, Prometheus and Grafana for throughput and latency, and an HTTP monitor for the public health endpoint. Add Infrai when one plain REST surface for backend services is useful and you want import evidence queried beside other telemetry. This is an operating decision, not a leaderboard. That division fits a one-person SaaS. I want to ship weekly and outsource undifferentiated plumbing where it removes work without hiding the failure mode. Revenue per hour is the useful lens. A silent import failure can consume more attention than the monitoring subscription, but a monitor that cannot be rolled back is its own production risk. What must the monitor prove? An HTTP 200 from /health proves that a process answered. It does not prove that yesterday’s seller catalog was imported, that the result was non-empty, or that the expected schema was used. For each run, emit an import identifier, scheduled time, completion time, row count, source version, and result status. Distinguish four states: no run before the deadline; a run started but did not finish; a run finished with zero or unexpectedly few rows; and a successful result that downstream code can use. Healthchecks.io is the right specialist for the first state. A task checks in after success, so a missing check-in exposes a silent failure. It does not explain why the import stopped. The application log and metrics should answer that. Prometheus and Grafana suit the second layer. Export counters for completed and failed imports, a gauge for the latest row count, and a duration metric. Prometheus can evaluate metric-based rules and Grafana can show the trend. The trade-off is setup: someone must own metric names, labels, retention, and rule behavior. Upptime is a good fit for a source-controlled public uptime workflow. Uptime Kuma is useful when self-hosted HTTP or service checks match the operating model. Both cover the external boundary. Neither proves that a background import produced correct data. The distinction is easy to miss. It is the first thing I test. Which tools should I use for backend task monitoring and health check? Use four inputs: a known import fixture, a deadline, a deployment version, and a last-known-good result. Give each run a unique ID. Then run the same sequence for every candidate: 1. Run a successful import and save its metadata. 2. Deploy a deliberately incompatible importer in a disposable environment. 3. Let the run miss its deadline and inspect the signal. 4. Roll back the importer while leaving monitor configuration intact. 5. Run the known-good importer and distinguish its evidence from the failed run. Pass means the missed run is detectable, the last successful result is identifiable, rollback does not create a duplicate success signal, and monitor configuration can itself be reverted. Fail if the candidate only reports liveness, erases diagnostic evidence during rollback, or requires an unreviewed production edit. For a solo founder, this is small enough to repeat before a major observability choice. It is more honest than a dashboard screenshot. A dashboard can look complete while measuring only that a container still has a socket open. That is the trap. I first separate the evidence by failure mode: a missing heartbeat belongs to the task monitor, a reachable endpoint belongs to the HTTP check, and a falling row count belongs to metrics. Only then do I compare integrations. This avoids the common rollback mistake where the application and its monitor are deployed together, the rollback removes the evidence, and the operator is left proving a negative from a green process check. For the query leg, Infrai offers a plain REST surface with one key and one bill for backend services. That keeps the import worker, metrics poller, and related backend calls from collecting separate credentials and invoices. Its public discovery surface is self-describing and documents runnable examples across 10 languages. That can reduce integration work, but it is not a heartbeat replacement: there is no alert or notification route for thresholds, phone calls, SMS, or webhooks. Healthchecks.io remains the better tool for “the task did not run”. const apiKey = process.env.INFRAI_API_KEY; if (!apiKey) throw new Error("INFRAI_API_KEY is required"); let delayMs = 500; for (let attempt = 1; attempt <= 4; attempt += 1) { const response = await fetch("https://api.infrai.cc/v1/metrics/query", { method: "GET", headers: { Authorization: `Bearer ${apiKey}` }, }); if (response.ok) { console.log(await response.json()); break; } const body = await response.text(); if (response.status !== 429 || attempt === 4) { throw new Error(`Metrics query failed (${response.status}): ${body}`); } const retryAfter = Number(response.headers.get("retry-after")); await new Promise((resolve) => setTimeout(resolve, Number.isFinite(retryAfter) ? retryAfter * 1000 : delayMs)); delayMs *= 2; } This is a query loop, not an alerting product. The current discovery documentation is the authority for request fields; I would not invent filters or enumerate routes. Record the query time and import ID in structured logs so a rollback can be reconstructed. When should a specialist win? Choose Healthchecks.io when the decisive requirement is “tell me that this scheduled job did not check in.” Choose Upptime for reviewed, source-controlled public uptime. Choose Uptime Kuma for self-hosted HTTP and service checks. Choose Prometheus and Grafana when rates, distributions, and history drive decisions; their metrics model is better for “row counts fell for three hours” than a heartbeat alone. I recommend the unified REST option to a solo SaaS team that already has a heartbeat and notification path, but wants import metrics and logs queried through the same backend surface. I would not use it as the only scheduled-import monitor. That boundary is explicit. The decision rule is simple: use the specialist that detects the failure mode, then add a unified query surface only where it reduces integration work without hiding ownership. A rollback-safe monitor has configuration, evidence, and notification paths that can return to a known-good state. If that boundary fits your system, start with the Infrai documentation and verify the current discovery schema before wiring the polling client. References - Infrai official documentation - OpenTelemetry: Logs signal concepts - healthchecks.io - Upptime - Uptime Kuma - Prometheus - Grafana

30 projetos GRÁTIS do GitHub para trabalhar melhor com IA Descubra 30 projetos gratuitos do GitHub para usar IA, criar conteúdo e organizar seu trabalho. Veja ferramentas de vídeo, produtividade, segurança, marketing e servidores, com os links organizados por assunto abaixo. Conheça o Bora Criar com IA: boracriarcomia.com.br CAPÍTULOS 00:00 Apresentação e inteligência artificial 00:35 Segurança 00:47 Vídeo e conteúdo 01:10 Negócios e marketing 01:30 Produtividade 01:46 Servidores e infraestrutura 02:23 Projetos para explorar 02:38 Antes de instalar INTELIGÊNCIA ARTIFICIAL 1. Dify — langgenius/dify 2. Taskosaur — Taskosaur/Taskosaur 3. OpenWork — different-ai/openwork 4. Agent Browser — vercel-labs/agent-browser 5. Emdash — generalaction/emdash SEGURANÇA 6. PasteGuard — sgasser/pasteguard 7. Claude Code Safety Net — kenryu42/claude-code-safety-net VÍDEO E CONTEÚDO 8. OpenReel — Augani/openreel-video 9. BridgeClip — bridge-mind/bridgeclip 10. Recordly — webadderall/Recordly 11. Textream — f/textream 12. FFmpeg Skill — kajisho5/ffmpeg-skill 13. Presenton — presenton/presenton NEGÓCIOS E MARKETING 14. Deskcomm CRM — melgarafael/DeskcommCRM 15. Open SEO — every-app/open-seo 16. Cogsend — deepakness/cogsend PRODUTIVIDADE 17. Handy — cjpais/Handy 18. Kept — ericerkz/kept 19. Excalidraw MCP — excalidraw/excalidraw-mcp 20. ezBookkeeping — mayswind/ezbookkeeping SERVIDORES E INFRAESTRUTURA 21. Dockge — louislam/dockge 22. OpenObserve — openobserve/openobserve 23. LogDeck — AmoabaKelvin/logdeck 24. WebSSH — bifrost0x/webssh 25. Breakscale — xevrion/breakscale 26. SQLit — Maxteabag/sqlit 27. Mailflare — hieunc229/mailflare 28. Open Archiver — LogicLabs-OU/OpenArchiver PROJETOS PARA EXPLORAR 29. Vibecraft — Nearcyan/vibecraft 30. God's Eye View — bilawalsidhu/gods-eye-view Confira licença, requisitos, custos de hospedagem e manutenção de cada projeto antes de instalar. “Gratuito” pode depender de serviços externos. Referência de pauta: Hallen Tech — youtube.com Qual ferramenta você vai testar primeiro? Deixe nos comentários e inscreva-se para conhecer mais recursos de IA. #InteligenciaArtificial #GitHub #OpenSource

After setting up Pi-hole, I was worried about its availability. Since it runs on a single Raspberry Pi, it's a single point of failure for the entire network. Claude suggested installing Uptime Kuma to monitor it, which looks very promising. louislam/uptime-kuma

Yo lo pondría para vigilar la web, el formulario de contacto y la fecha en que caduca el certificado. Se instala en un servidor pequeño, así que no depende del mismo hosting que vigila. louislam/uptime-kuma

Usterka Internetu od 13 dni, co robić dalej? Siema, nie wiem już gdzie się wyżalić odnośnie żałosnego łącza z vectry, więc pomyślałem, że zapytam tutaj co robić dalej. Mieszkam na Śląsku, w bloku, i od dobrych wielu lat borykam się ze słabymi dostawcami Internetu. Apogeum osiągnęła VECTRA: począwszy od robienia z klienta durnia, przez bezużyteczne testy i techników, aż po wmawianie klientowi, aby nabrał trochę więcej cierpliwości -- co powiedzieli mi po 12 dniach ciągłych przerw w dostawie Internetu. Podpisałem z nimi umowę we wrześniu 2023 i od grudnia tamtego roku, co miesiąc lub dwa, przechodzę przez dokładnie ten sam rytuał upokorzenia. Dzwonię na infolinię lub zakładam skargę przez formularz kontaktowy, wysyłam bezwartościowe testy (pokazujące, że gdy usługa działa to jest idealna, a jak nie no to wykazują 100% packet loss), oni wysyłają technika i finalnie usterka sama z siebie się naprawia, kilka dni po tym jak zamknęli sobie ticket. Wyjątkowo, od 13 dni usterka się nie traci, tak jak dotychczas... i to dlatego piszę ten post. Żeby dalsza część miała trochę więcej sensu to przytoczę jak wygląda moja sieć. Router od VECTRA jest w trybie mostka i jest podłączony do koncentryka z klatki oraz do mojego routera (TP-LINK Archer C64), który zarządza całą lokalną siecią. Przewodowo podłączony jest komputer i laptop (który dubluje jako web serwer). Reszta, w tym telefony; dekodery smart i drukarka, są podłączone po Wi-Fi. Chciałbym zaznaczyć, że sieć lokalna działa bez problemu. Przez usterki z łączem od vectry wymieniałem wszystkie skrętki, sprawdzałem zapory ogniowe, kupiłem kartę sieciową na PCI-E, przywracałem urządzenia do ustawień fabrycznych i tak dalej. Jestem w stanie bez problemu połączyć się ze swoim laptopem za pomocą SSH, hostować witryny, serwery do gier itp. itd. Usterki (których od momentu zawarcia umowy było osiem) charakteryzują się, przynajmniej z tego co mogę sprawdzić u siebie, brakiem "bezpiecznych" połączeń. To znaczy, monitoruję swoją sieć przy pomocy Uptime Kuma, który co minutę wysyła zapytania do różnych witryn internetowych i oczekuje na odpowiedź. Mierzę różne witryny, w tym reddit, cloudflare, google, wikipedia i tak dalej i za każdym razem jak sypie się łącze, to wszystko jest na czerwono. Nie są zwracane żadne błędy, tylko łącze po 48 sekund się poddaje i jest koniec. Dotyczy to wszystkich połączeń po TCP, TLS, SSH, HTTPS et cetera. Jeśli gram w jakąś grę na serwerze hostowanych po UDP, albo jestem na czacie głosowym na Discordzie, to nawet nie zauważę, że w tym momencie trwa usterka. Podobnie z domownikami oglądającymi telewizję. Sypnie im się dopiero gdy spróbują zmienić kanał. Do teraz, od 14tego października, Internet sypie się średnio co 10-20 minut (chociaż były przypadki, gdzie działał 5 minut a przerwa trwała po 45 minut) i ściśle rzecz ujmując nie wymaga ode mnie żadnych czynności. Mogę przyśpieszyć powrót prawidłowego działania łącza poprzez ręczne wyłączenie i włączenia routera od ISP, wypnięcie i wepnięcie kabla WAN z mojego routera do ich routera oraz reboot mojego Archer'a. Dzięki temu jestem w stanie ograniczyć przerwę do 2-5 minut, co nie zmienia faktu że mam ~60% uptime przez ostatnie 13 dni, a były dni gdzie przez 24h miałem ~7%. Co do dostawcy, no to kontaktowałem się z ich wsparciem klienta mailowo oraz telefonicznie chyba z 20 razy. Starałem się być kooperatywny i wyrozumiały wobec konsultantów, ale gdy słyszę po raz n-ty i że mam być cierpliwy bo nie są w stanie nic zrobić, że nie znają przyczyny problemu (bo najwyraźniej technicy nic nie piszą w notatkach ticketa), no to nie ciężko o palpitacje. Boli mnie to w szczególności dlatego, że to już ósmy raz, gdy dokładnie ten sam schemat i objawy usterki mają miejsce, i to wyłącznie pod moim adresem. Technicy uświadomili mnie, że jest 15 innych klientów vectry w mojej klatce, a tylko i wyłącznie ja zgłaszam jakiekolwiek problemy z łączem. Z desperacji udałem się do Rzecznika Praw Konsumentów, ale realnie nie będę w stanie wywalczyć dobrego łącza, jeśli VECTRA sama w sobie takiego nie położy. Przypomnę, że nie mam światłowodu (znaczy, są inni dostawcy, którzy go dostarczają, ale nie VECTRA), a tylko w ostatnim tygodniu technik był już pod moim mieszkaniem 4 razy. Z konkurencją również nie jest zbyt dobrze, przynajmniej ja dobrych doświadczeń z PLAY'em nie miałem a lokalny, mały dostawca, zatrzymał się w 2007 roku i dostarcza jedynie do 20 mbps down i 1 mbps upload po skrętce. Rzecznik też mnie poinformował, że najwięcej zgłoszeń/skarg jest u nich właśnie z VECTRA i na drugim miejscu PLAY, także wpadłem z deszczu pod rynne i zbyt dużego wyboru nie mam. Co do robienia z klienta idioty, to wielokrotnie sugerowali, że winą jest łącze bezprzewodowe i zakłócenia po Wi-Fi. Szkoda, że urządzenie na którym mierzę sieć jest połączone kablem, o czym wspominam na samym początku każdego zgłoszenia czy rozmowy. Pytają się "jakie mam oczekiwania"; no nie wiem, na przykład żeby Internet działał? Czy to naprawdę aż takie wysokie wymagania? Wiele razy wmawiali mi, że z ich punktu widzenia wszystko jest na zielono i parametry łącza są idealne -- oczywiście w trakcie gdy mi nie ładowały się żadne strony i wszystkie serwery wyrzucały kod błędu. Próbowali też mnie zniechęcać do dalszego drążenia usterki poprzez wykonywania bezużytecznych testów łącza przy pomocy mtr w trakcie usterki, po 30 minut każdy. Kto próbował, ten wie, że przy kompletnym braku Internetu 30 minutowy test mtr będzie trwał 2 godziny, a to tylko jeden test. Chcieli, żebym sprawdzał ten sposób wszystkie witryny jakie chciałem odwiedzić, co by trwało ~16 godzin. Koniec końców, wysłałem im te testy... kilka razy. Technik później mi powiedział, że nawet ich nie widział i sam ma wrażenie, że były bez sensu. Podobnie z głupotą o proszenie o speedtest, gdy ja nie mogę nawet wejść na żadną stronę. Wisienką na torcie jest pytanie o zgłoszenie skargi przy pomocy Strefy Klienta (na którą nie mogę wejść bez Internetu) lub pocztowo. Dostawca Internetowy, który sugeruje wysłanie pocztą skargi na ich łącze, nie wiem co powiedzieć... Technicy też tego łącza nie naprawili. Od konsultanta słyszałem, że sygnału już bardziej się wzmocnić nie da, a technik mi dzwoni, że założył tłumik i wzmacniacz, i teraz łącze będzie idealne. Standardowo, po godzinie/półtora od telefonu, łącze doświadcza tych samych problemów, ale oni zamykają ticket i dostaję SMS że usterka naprawiona. Byłem w salonie Orange i gdy chciałem zadać parę technicznych pytań to mi powiedzieli, że muszę najpierw podpisać umowę a dopiero potem pytać montera, który przyjdzie zamontować łącze. Fakt, że mogę w ciągu dwóch tygodni zrezygnować bez żadnych skutków czy kar, ale mimo wszystko trochę to podejście mi śmierdzi. Z tego co mi wiadomo, to ich Funbox nawet nie wspiera trybu mostka, więc musiałbym chyba montera błagać o ONT albo pogodzić się z tym, że będę musiał korzystać z ich softu. Z UPC łącze było nawet okej, ale po migracji do PLAY wszystko się zgównowaciło i musiałem się bardzo długo męczyć z ich wsparciem klienta i finalnie zrezygnować, bo usterki były jeszcze gorsze niż obecnie. Już serio nie wiem co robić. Rzecznik polecił napisanie skargi do Urzędu Telekomunikacji Elektronicznej, ale trochę jednak stresuje mnie pisanie do takiej instytucji na własną rękę. Macie pomysł co mogłem przeoczyć i co mogę jeszcze zrobić? edit: literówki

5 GitHub Projects That Feel Too Good to Be Free 🔥 5 GitHub Projects That Feel Too Good to Be Free! What if you could edit PDFs, monitor websites, back up your photos, and transfer files between devices — without paying for expensive software? In this video, we're exploring 5 amazing open-source GitHub projects that offer powerful features for free. Whether you're a developer, student, content creator, or tech enthusiast, these tools are worth checking out! 🚀 THE 5 PROJECTS: ✅ 1. Excalidraw – Create diagrams, flowcharts, and sketches. 🔗 excalidraw/excalidraw ✅ 2. Stirling PDF – Merge, split, compress, and manage PDF documents. 🔗 Stirling-Tools/Stirling-PDF ✅ 3. Uptime Kuma – Monitor your websites, APIs, and services. 🔗 louislam/uptime-kuma ✅ 4. Immich – Build your own photo and video library. 🔗 immich-app/immich ✅ 5. LocalSend – Transfer files between nearby devices without relying on cloud uploads. 🔗 localsend/localsend #GitHub #OpenSource #FreeSoftware ☺ Thanks For Watching! ☺ If you find this helpful, 💙Like and ✅ Subscribe

@portertech 可再加 Keyword／JSON Query 內容檢查，避免首頁回 200、內容卻變成維護頁還亮綠燈。Uptime Kuma 官方列有這兩種監控。配置後用測試服務停啟一次，確認故障與恢復通知都能到 Telegram，再把相同檢查加到關鍵業務入口。 louislam/uptime-kuma