Better Uptimeは30秒監視を入口に、incident対応までどう束ねたか

Better Uptimeは、WebサイトやAPIの稼働監視を入口に、incident managementとstatus pageまでをつなぐBetter Stackのmonitoring productだ。

30秒間隔のチェックやerror screenshotを提供する。出典

Juraj Masarは「We are simply engineers making the tools we always wanted to use」と語った。出典

使いたい道具を自分たちで作る

Better Stackは、既存のobservability toolsが複雑で高価で、2000年代の設計に見えるという問題意識から始まった。

Juraj MasarとVeronika Kolejakは、エンジニアが日常的に使うmonitoring・logging・incident対応を、より一貫した体験へ寄せようとした。出典

SQLを共通言語にする

転機は、開発者ならSQLを知っているという前提を製品の中心へ置いたことだった。

Veronika Kolejakは、各社固有のquery languageを覚える負担を指摘し、observabilityのquerying standardとしてSQLを使う考えを説明している。出典

Uptimeを入口に運用をつなぐ

Better Uptimeは、30秒間隔のchecks、error screenshot、multi-location monitoringを入口にした。

そこで検知した異常をon-call、incident management、status pageへつなげることで、監視を単独の通知機能から運用workflowへ広げた。出典

資金と顧客を得てstackへ広げる

2022年7月、Better StackはSeries Aで1,860万ドルを調達し、70,000人超のdeveloperと1,400社超のcustomerに利用されていると発表した。出典

その後はUptimeだけでなくincident managementやstatus pageを含むobservability stackとして製品範囲を広げている。出典

監視の後ろにある仕事を減らす

Better Uptimeの道のりは、監視を高機能化する話というより、障害を見つけた後に発生する連絡・判断・説明を一つの流れへ戻す話だ。

公開情報から確認できる現在地は、価格の安さだけでなく、developerが使いたい運用道具をまとめるという創業者の原体験にある。

Better Uptimeが刺さるのは、監視ツールを増やすより「障害を見つけた後の判断と連絡」を短くしたい小規模〜中規模のengineering teamだ。

30秒チェック、スクリーンショット、status page、on-callを同じ導線に置くため、監視と顧客対応の間にある運用の詰まりを減らせる。出典

一方で、大規模observabilityの全機能を一つの製品だけで置き換えるものではない。

Better Stack自身もloggingやtelemetryを含むstackとして位置づけており、導入価値は「深い分析」より「検知から共有までの速さ」にある。出典

最大のmoatは、監視データそのものより、検知・on-call・incident・status pageが同じ運用履歴につながるworkflowだ。

ClickHouseを使う技術基盤と、SQLをqueryingの共通言語にする思想が、別々のツールを組み合わせるより低い認知コストを作る。出典

強いnetwork effectではない。

顧客数が増えても監視サービスの価値が直接増えるわけではないからだ。

ただし、status pageを顧客との共有面、communityやcontentを学習面として使う間接効果はある。出典

主な対象は、専任SREが少ないstartup、agency、SaaSのengineering teamだ。

特に、APIやWebの異常を早く検知し、on-call担当へ通知し、顧客向けstatus pageまで自分たちで運用したいチームに合う。出典

逆に、複雑な規制要件や巨大なtelemetry基盤を既に運用している企業は、既存observabilityとの機能差を先に検証すべきだ。

第一に、uptime monitoringだけでなくincident managementとstatus pageを束ね、障害対応の文脈を切らないこと。

第二に、SQLとClickHouseを軸に、既存大手より分かりやすい価格と体験を打ち出したこと。

第三に、無料枠とcontent/communityを入口に開発者へ届く導線を作ったこと。出典

この組み合わせは、機能数の競争ではなく、運用チームの認知負荷を下げる競争として再現可能だと考えられる。

第一のリスクは、monitoring・logging・AI SREまで広げるほど、製品の境界と比較軸が複雑になることだ。

Better Uptime単体の価値を伝え続けなければ、Better Stack全体の説明に埋もれる。出典

また、70,000人超developer・1,400社超customerという数字は2022年の公式発表であり、現在のARRや継続率は公開されていない。

大手observabilityとの価格差も利用規模や機能構成で変わるため、一律の優位と断定できない。出典

無料のmonitoringとstatus pageで導入障壁を下げ、技術コンテンツと比較ページで運用課題を検索するdeveloperを取り込む。

そこからincident managementやloggingへ拡張するland-and-expandが基本線だ。出典

公式pressでは、DatadogやPagerDutyの代替として、低価格・高速・デザインを訴求している。

大手からの乗り換え支援まで掲げる一方、広いobservabilityを維持するための営業・サポートコストはトレードオフになる。出典

主要チャネル: content, community, developer-relations

監視プロダクトの差別化は、アラートの数を増やすことではなく、アラート後の仕事を減らすことにある。

検知、担当者への通知、原因調査、顧客への説明を一つの流れとして設計すると、単機能の比較から運用全体の比較へ視点を移せる。出典

ただし、公式に公開された数字のas-ofを守り、未公開のARRを成長物語へ混ぜない姿勢も重要だ。

日本で展開するなら、SaaSだけでなく受託開発・ゲーム・ECの運用チームへ、障害時の社内外コミュニケーションを含む提案にするとよい。

日本語のstatus page、国内リージョン、電話・Slack・Teamsの通知要件、監査ログの説明を前面に出せば、単なる海外monitoringの価格比較から抜けられる。出典

ただし国内市場の顧客数や適合性は要確認であり、公開情報だけで需要を断定できない。