Sigabrt.dev 拆解报告：把 cronjob 心跳监控塞进一个 SSH 端口

【这是什么】

Sigabrt.dev 是一个反向心跳式（dead man's switch）的 cronjob / 脚本监控服务。工作方式和 Pingdom 这类"主动探测你的服务"正好相反：你为每个任务创建一个 pulse endpoint，任务成功时主动 ping 一下，一旦超过预期周期没有收到 ping，服务就通过邮件或 ntfy 通知你。

接入成本是一条 curl：

0 * * * * ./script.sh && curl -fsS https://sigabrt.dev/pulse/<id>/beat

产品形态上它有两个部分：

1. 核心功能：pulse 端点 + 超时判定 + 通知分发。这是所有 dead man's switch 工具的通用骨架。
2. SSH TUI：ssh sigabrt.dev 直接进入一个只读的终端界面，在账户设置里添加 SSH 公钥即可使用。作者自己在 Show HN 里明说这是"实验性的、只读的"，并且不确定它到底有用还是只是个噱头。

本质上是托管型 SaaS，freemium + 订阅定价（评论区有人把它归类为"有价格的 freemium SaaS 产品"），而不是一个开源仓库——所以没有 GitHub Star、语言分布这类数据可看，它交付的是服务本身。作者对它的定位也说得直接：与同类服务相比，这个是极简的。

【背景 / 谁做的】

• 一个人，为自己的痛点做的。作者在帖子里第一句就是"我做这个主要是为了监控我自己托管的东西"，并主动说"我知道这没什么太令人兴奋的"。这是典型的一人公司路径：先解决自己运维里真实存在的问题，再顺手产品化。
• 没有团队、公司、融资背景披露，也没有开源仓库。作者身份就是 HN 上的独立开发者。
• 作者对项目的期望值管理得很低。帖子里的自嘲（"不太令人兴奋""不确定 SSH TUI 是噱头还是有用"）是 Show HN 上很有效的一种姿态——降低了推销感，也让评论区的批评火力明显减弱。
• 技术受众属性明确：示例代码是 crontab 一行、通知渠道选了 ntfy（而不是 Slack / PagerDuty），说明作者自己就是自托管 / 小规模运维人群中的一员，产品口味也是冲着这批人去的。

【怎么获客】

目前能看到的获客手段基本只有一条，但用得比较到位：

• HN Show HN 冷启动。这是唯一可见的曝光入口。标题直接就是"Show HN: Sigabrt.dev – 带 SSH TUI 的 cronjob 监控器"。
• SSH TUI 是钩子，不是功能。ssh sigabrt.dev 这个动作在 HN 上有稳定的注意力红利——同一批相关帖子里，krnl.duetbrowser.com 的 SSH TUI 浏览器反复以多个不同标题冲上首页（"your website as a TUI, over SSH"、"a TUI browser with its own layout engine"），paint.dn.ht 也是同类实验。这个形式的技术受众匹配度高、体验有新奇感、传播成本几乎为零。作者把它放在标题里，说明他清楚这是话题点。
• 接入摩擦接近零。一条 curl、一个 pubkey，没有 SDK、没有 agent、没有 dashboard 强制注册流程。这本身就是营销信息。
• 通知通道借用现成的。直接对接 ntfy 这个开源推送工具，不用自建 App，省开发也省用户教育成本。
• 没看到的手段：SEO / 内容营销、与自托管生态（Docker、Home Assistant、自托管社区）的集成、目录站提交、付费投放。也没有看到任何推荐机制或增长回路。
• 需要留意评论区这个"负向流量"。帖子里有读者直接甩出竞品链接（healthchecks.io、heartbeats.dorianmarie.com），并围绕"该不该在 Show HN 里贴竞品"吵了一轮。对作者而言这既是免费的市场调研，也是公开的定位压力——有评论者的原话是：看 Show HN 第一件事就是想搞清楚"这个项目相比已有的成熟项目到底提供了什么"。

【验证情况 / MRR】

• 没有公开任何 MRR、付费用户数、注册量或留存数据。评论区只提到它是个"有价格的 freemium SaaS"，没有任何数字。
• 已确认的验证信号：
• 真实的自用需求（作者在自己托管的东西上跑）。
• 有 HN 首页级的曝光。
• 产品闭环完整：endpoint → 超时判定 → 邮件 / ntfy 双通道通知 → SSH 查看。
• 尚未验证的部分：
• 付费意愿。核心功能（"漏 ping 就告警"）在评论区被普遍认为是低复杂度能力，且有大量替代方案（crontab 自带邮件、systemd timer + systemctl --failed -t service、Prometheus + Grafana 对"last success"指标告警、healthchecks.io 的免费额度）。
• 长期存续信任。有评论者直接质疑"sigabrt.dev 两年后还会存在吗？五年后呢？"——监控服务本身是基础设施，卖的是可信度，这个质疑对转化率的杀伤力比功能对比更大。
• 所以目前的状态准确说是曝光型验证，不是收入型验证。

【对一人公司的可复制性】

可以直接抄的部分：

1. 技术栈极轻，一人几天能出 MVP。三个组件就能跑通：接收 beat 的 HTTP 端点、周期性扫描 last_seen 的 scheduler、通知分发器（SMTP + ntfy）。没有分布式系统、没有 agent 要维护。一个人完全撑得住。
2. "SSH 作为交付界面"是一个高性价比的获客技巧。它同时解决了三件事：零注册摩擦的现场演示、天然筛出技术受众、在 HN / Reddit 这类地方自带话题性。实现成本就是一个 SSH 监听端口加一个 TUI，维护成本远低于做一套前端。相关帖子里 SSH TUI 项目反复获得展示位，说明这个红利在一段时间内是可持续的。但作者自己都承认它可能只是噱头——所以把它当流量入口，不要当护城河。
3. "先给自己做"作为选题方法。这个项目的起点不是市场调研，是作者自己托管的东西需要监控。一人公司最稳的产品来源就是这种自带使用场景的工具型需求——你既是用户又是维护者，需求不会跑偏。
4. 不自建通知通道。接 ntfy，省掉 App 开发、推送证书、用户教育三块成本，直接把精力放在可靠性上。
5. freemium 是这类工具的默认形态，可复制性高：免费层覆盖少量 pulse，付费解锁更多 pulse、更短检查间隔、更多通知渠道、更长历史保留。

不容易复制的部分：

• 一次性的 HN 首发红利。这类曝光不可重复，第二个做同样事情的人拿不到同样的注意力。
• 品类免费层已经被锚定得很低。healthchecks.io 在评论里被多个用户主动推荐，加上 crontab 和 systemd 的原生方案，定价空间是被压着的。想收钱必须靠细分切口（SSH-first、ntfy-native、极简），而不是靠功能覆盖面比拼。

【风险与机会】

风险：

1. 品类拥挤，且替代方案是"免费且已装好"的。评论区列出的免替代包括：crontab 直接发邮件、systemd timer 配 systemctl --failed -t service、Prometheus 采集 last-success 指标 + Grafana 告警。healthchecks.io 作为成熟竞品被反复点名。作者自己也承认"已经有类似的服务了"。
2. 价值主张讲得不够锋利。这是最实质的问题。评论里有一条切中要害：外部心跳监控的真正价值不是"提醒你 job 失败了"，而是"当你这边的告警通道本身坏掉时（比如 SMTP 凭据配置错误、cron 发不出失败邮件），仍然有人能告诉你信号没到"。作者当前的文案（"如果你的脚本没有定期 ping 它，你就会收到通知"）并没有把这一点单拎出来讲——而这恰恰是外部服务相对本地方案的不可替代之处。定位不升级，用户就会拿它和免费的本地方案比。
3. 存续性是监控类产品的一级信任门槛。用户会公开问"你两年后还在不在"。对一人公司来说，这要么靠时间积累，要么靠透明（状态页、开源核心、数据导出、自托管选项）来提前解决。
4. SSH TUI 只读且实验性，目前不承载功能价值，长期可能变成一项纯维护负担。如果状态一直停留在"实验性"，不如要么砍掉，要么让它承担真实功能（查看 beat 历史、静默告警、暂停 pulse）。
5. 单点曝光依赖。全部获客押在一次 HN 帖子上，后续沉淀机制（邮件列表、文档站、集成目录）看不到。

机会：

1. 把"外部视角"当成核心卖点重讲一遍。评论区已经免费给出了这句话：本地系统无法可靠地告警"自己发不出告警"这件事。围绕这个重写首屏文案，能把产品从"又一个 cron 监控"抬到"你本地告警链路的最后一道保险"。
2. SSH-first 的细分人群是真实存在的。评论里那句"如果你想要 dashboard 那还挺酷"其实反向定义了一个位置：有一批人不想再开一个浏览器标签、不想装 App，只想在一个终端里看一眼。ntfy + email + SSH 这套组合正好服务这批自托管用户。
3. ntfy-native 是差异化钩子。主流监控工具的通知生态偏向 Slack / PagerDuty / 邮件，对自托管人群不友好。把 ntfy 做成一级公民（自托管 ntfy 服务器可配置、优先级、标签）能拿到一块明确的细分市场。
4. 向"基础设施最小仪表盘"延伸。只读 TUI 现在是入口，未来可以承载 beat 历史、失败时间线、静默窗口——这些是本地 crontab 和 systemd 给不了的，且都在已有数据里。
5. OPC 视角下的合理性。这类工具不需要做成一门大生意。服务器成本低、通知通道不自建、维护面窄，如果能把付费层做到几百个订阅，就是一个稳定的小现金流产品——它最大的敌人不是竞品，而是自己能否活到用户愿意把关键监控挂上来那一天。

信息来源：Hacker News、GitHub