Skip to content

100 days since last 'why is my server down' panic

Dedicated Servers by RAJ 28 replies 4.2K views
#21
frank1 said:
What provider

1984.is in Reykjavik for primary, a small German host for secondary. Not naming the German one because they're not taking new customers and I like it that way.

The script runs from a third location entirely. Paranoia? No, just saw too many "both datacenters in the same flood plain" incidents in my career.

#22

Late to this but I want to push back on the "status pages are a scam" thing. I run fiber installs in rural areas and my clients are not technical. They see "server error" and they panic-call me at 6am because they think I cut their internet.

A real status page with actual incident history saves me maybe 10 calls per outage. That's worth more than the hosting cost.

#23
fiberpaul said:
My clients are not technical

Different world kiddo. My clients are resellers who know what SSH is. They don't need a pretty page telling them what they already saw in their own monitoring.

But fair, different strokes.

8 #24

Has anyone actually white-labeled Gatus successfully? I see the config for it but the docs are thin on the multi-tenant part. Need this for three different client brands and don't want to run three instances.

#25
frank36 said:
White-labeled Gatus successfully

Not yet, that's why I asked in the first post. From what I can tell it supports custom CSS and page title per endpoint group, but true multi-tenant with separate domains needs a reverse proxy layer. Traefik or nginx with subpath routing.

Might just run three instances on the same $5 box, honestly. It's Go, memory footprint is tiny.

your margin is my opportunity
6 #26

Three instances on one box defeats the purpose of redundancy though. If the watcher dies, all three status pages die.

#27
Key31 said:
Three instances on one box defeats the purpose

The status pages aren't the watchers. Uptime Kuma does the actual monitoring from separate boxes. The status pages are just the display layer.

But you're right, I should host the status pages on different infra than the watchers. Currently my Cachet is on the main server, which is exactly the problem if main server goes down.

your margin is my opportunity
7 #28
RAJ said:
Status pages on different infra than the watchers

Now you're getting it. The full stack should be:

  • Watchers: external, multiple, cheap
  • Status page: external, static or minimal
  • Alerting: external path to you
  • Your infrastructure: the thing being watched, not hosting the watch tools

I saw too many "the monitoring server went down so we didn't know everything else was down" tickets.

#29

Old thread but I just found it. For anyone still looking: I switched from Cachet to a fork called CachetHQ that's actually maintained. Same clunky UI but at least the dependencies install without fighting Python 2 vs 3.

Also re: HostHatch, their Zurich location is in Interxion ZUR1. I get 3ms from my office. Solid for EU monitoring.

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft