Alerts for self-hosted customer deployments

TL;DR: Distr is an Open Source platform to distribute applications to on-prem, BYOC, and air-gapped customers. It now supports alerts so you get notified about failed updates, crash loops, or unreachable deployments before your customers do.

The Visibility Gap

For your own application, you’ve got this figured out. Grafana alerts, PagerDuty, whatever. Something breaks in production, you know about it in minutes.

For self-hosted customer deployments? Nothing. Radio silence unless they open a ticket.

You have all this sophisticated monitoring for your own infrastructure, but the moment your software crosses over to customer-controlled environments, you’re flying blind. You find out things are broken when your customer tells you they’re broken. Sometimes days later.

You can’t SSH into every customer deployment and tail logs. That doesn’t scale, and frankly, your customers probably wouldn’t let you even if you wanted to.

What We Built

Alerts in Distr work for both sides:

Distr lets you configure alerts in the Vendor portal. Set them once, they apply everywhere. Or get granular if you want.

For customers that manage and update the deployments themselves, you can enable alerts for them as well so they can configure their own alerts in the Customer portal.

This dual approach matters because not all customer relationships look the same. Some of your customers want you monitoring their deployments—they’d rather you catch issues first and fix them proactively. Others prefer to run their own ops and want full control over who gets notified when.

For example, you’ll get alerted if an update fails or gets stuck looping, if we lose contact with a deployment (network issues, dead instance, whatever), or if your app’s in a crash loop. We filter out normal restarts from successful updates though—no point spamming you about routine operations.

The details on setting this up are in the alerts documentation.

How It Helps

The main thing is you catch issues before your customer does. That’s worth a lot.

We had one customer who didn’t realize their deployments were in a crash loop for two days because the app was restarting fast enough that it looked “up” when they checked. With alerts, that would’ve been caught in the first 10 minutes.

Getting Started

If you’re already using Distr, alerts are available now. Vendor settings for your side, customer portal for theirs. Takes about 30 seconds to configure.

If you’re not using Distr yet and you’re dealing with software distribution to on-prem or customer-controlled infrastructure… well, we should probably talk.

Let us know what you think, we would love to hear from you or support us by leaving a star:

⭐ distr-sh/distr ⭐

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

Roadmap Planning In Software Development: Ultimate Guide

Next Post

Build a TikTok Sound Trend Analyzer to Find Viral Audio Before Everyone Else

Related Posts
arkui-x平台差异化

ArkUI-X平台差异化

跨平台使用场景是一套ArkTS代码运行在多个终端设备上,如Android、iOS、OpenHarmony(含基于OpenHarmony发行的商业版,如HarmonyOS Next)。当不同平台业务逻辑不同,或使用了不支持跨平台的API,就需要根据平台不同进行一定代码差异化适配。当前仅支持在代码运行态进行差异化,接下来详细介绍场景及如何差异化适配。 使用场景 平台差异化适用于以下两种典型场景: 1.自身业务逻辑不同平台本来就有差异; 2.在OpenHarmony上调用了不支持跨平台的API,这就需要在OpenHarmony上仍然调用对应API,其他平台通过Bridge桥接机制进行差异化处理; 判断平台类型 可以通过let osName: string = deviceInfo.osFullName;获取对应OS名字,该接口已支持跨平台,不同平台上其返回值如下: OpenHarmony上,osName等于OpenHarmony-XXX Android上,osName等于Android XXX iOS上,osName等于iOS XXX 示例如下:…
Read More