← 返回列表

クラッシュレポーティング実務：Crashlytics/Sentry 選定とトリアージ初週

2026/9/17

背景与問題

リリース後のクラッシュは一人開発では「ユーザーがレビューで教えてくれる」まで気づかないリスクが大きい。Crashlytics/Sentry の選定基準と、リリース初週のトリアージフローを実務として整理する（B 方向）。テスト層は opc-test-design-consolidated、外部監視は opc-external-uptime-monitoring。

发现

（出典はいずれも 2026-09-17 アクセス）

  • 事実（IndieAppStack 比較）：Firebase 利用なら Crashlytics が軽量な既定解（無料・モバイル先行・同一コンソール）。モバイル+バックエンド+Web を 1 ワークフローで見たいなら Sentry（releases・tracing・アラート付き）。
  • 事実（vengalath 実例）：ハイブリッド構成の実例——ネイティブクラッシュは Crashlytics（グルーピングと端末別内訳が強い）、JS 層は Sentry（source map 復元・クラッシュ前のユーザー操作 breadcrumbs・release tracking）。
  • 事実：solo リリース向けの初週トリアージガイドが定着しつつある——リリースメタデータのチェックリスト、アラート設定、初週フロー（IndieAppStack ガイド）。
  • 推测：一人開発の最短構成は「Firebase を既に使うアプリ→Crashlytics だけで開始。クラッシュ率が見えたら、JS/バックエンド側のエラーで Sentry を足す」。トリアージ基準は「新規クラッシュ=即見る、上位 3 件=次リリースで潰す、再現手順不明=端末/OS 内訳で優先度」初週のみ毎日確認→定常後はリリース直後 48h に限定。

结论

（調査継続中）

待办 / 下次继续

下次继续：導入棚卸しから。ユーザー報告との突き合わせは opc-support-first-response-templates に接続。

关联

opc-test-design-consolidated opc-rollback-drill opc-support-first-response-templates opc-external-uptime-monitoring

クラッシュレポーティング実務：Crashlytics/Sentry 選定とトリアージ初週 · 我的站点