Cachet Laravel Package

Product Decisions This Supports

• Build vs. buy vs. self-host for customer-facing incident communication. Cachet answers the "do we ship a public status page?" question with a ready-made feature set — components with grouped status, incident timeline posts, scheduled maintenance windows, subscriber notifications (email/SMS/webhook), uptime metrics, a REST API, and localization/theming. That's a credible requirements spec even if you never deploy it.
• Whether trust/transparency is a roadmap item or a sales asset. For B2B SaaS, a status page is often a procurement checkbox (security questionnaires, SLA exhibits, enterprise onboarding). This package lets you scope that work as a two-week self-host rather than a multi-quarter product bet.
• Self-hosted / data-residency positioning. If you sell to regulated, on-prem, or air-gapped customers — or you can't send infrastructure signals to a US SaaS vendor — a self-hosted status page is a differentiator, not a nice-to-have. Cachet is one of the few Laravel-native options in that lane.
• Incident-comms scope discipline. Because Cachet's model is deliberately narrow (components + incidents + maintenance), it's a good forcing function for the decision not to build on-call scheduling, alerting, or SLO analytics. Use it to draw the boundary: status page yes, incident response platform no.
• Architecture decisions upstream of the page. Deciding to adopt Cachet implies decisions about uptime probe placement, a public read-only API surface, and how much automation writes incidents (CI/CD → API) versus a human in a UI. Those are product decisions about who owns comms during an outage.
• Multi-tenancy and white-labeling. Cachet is effectively one status page per install. That single fact decides a lot: shard-per-customer (ops cost), fork to add tenancy (maintenance cost), or pick a different vendor. Surface it early — it's the most common reason this evaluation dies.
• Reference model for a thin in-house build. A status page is a small Laravel app: components table, incidents table, a scheduled probe job, a public Blade page, a mail notification. If your team already runs Laravel, the honest counter-proposal to adoption is "copy the data model, ship in three sprints, own the roadmap." Cachet is the cheapest way to price that option.

When to Consider This Package

Consider it when all of the following hold:

• You are a PHP/Laravel shop with existing hosting, CI, and on-call competence — the marginal cost of one more Laravel app is low.
• You need one or a handful of status pages, not a per-tenant white-label product.
• Data residency, self-hosting, or "no third-party SaaS in the incident path" is a real requirement rather than a preference.
• You are willing to treat it as a fork you own, not a dependency you consume. Budget for patching, PHP/Laravel version currency, and a named owner — otherwise the status page becomes the thing that's down when you need it.
• You accept the current release cadence. Last release was November 2023 and the long-promised rewrite has not landed; the codebase tracks an older Laravel/PHP generation. Verify it runs on your target runtime before you commit, and resolve the NOASSERTION license metadata with legal — ambiguous licensing is a blocker for commercial or redistributed use.

Look elsewhere when:

• You need multi-tenant, per-customer branded status pages — that's a product, not a config, and Cachet won't get you there without a fork.
• You need a supported vendor with a security SLA, SOC 2 posture, or someone to call during an outage. That's Atlassian Statuspage, Status.io, Better Stack, or Instatus.
• You need modern framework currency and don't want to own an upgrade project on day one. Evaluate statping-ng, Gatus, or Upptime for the ops-led path, or build thin in Laravel for the product-led path.
• Your team is not PHP-native. The whole economic case collapses if nobody can read the code.
• You need deep SLO/error-budget analytics or alerting — Cachet is a publishing surface, not a monitoring system. Pair it with your observability stack or don't adopt it.

Note the signal in the numbers: 15k stars but 0 Packagist dependents — because it's an application, not a library. Read the popularity as mindshare and reference value, not as production adoption you can lean on.

How to Pitch It (Stakeholders)

One-liner for executives: Cachet is a mature, zero-license-cost, self-hosted status page built on Laravel — it removes a procurement checkbox and a transparency gap cheaply, but it is a fork we own, not a vendor we depend on.

What it buys us: No per-seat SaaS fee, no infrastructure telemetry leaving our estate, and a credible public incident history within weeks instead of a quarter. Fifteen thousand stars means the data model and UX patterns are already validated — we inherit decisions we'd otherwise spend discovery cycles making.

What it costs us: Ownership. The upstream release cadence is slow (last release Nov 2023), it tracks an older Laravel/PHP generation, and the license metadata needs legal sign-off before commercial use. Realistic TCO is one engineer-week to stand up plus a standing fraction of an engineer to keep it patched and current — and an uncomfortable truth: the status page becomes a dependency of your incident comms, so it needs its own monitoring and runbook.

The recommendation to engineering: Treat this as a 90-day evaluation with an explicit exit, not an adoption. Timebox a spike on our target PHP/Laravel runtime, prove the API can be driven from CI/CD so incidents publish automatically, and confirm the license. If the spike is clean, it's a defensible stopgap and a requirements document for a future in-house build. If it isn't, we've still extracted the spec — and we go buy a vendor or write 800 lines of Laravel.

The decision we're actually making: not "Cachet or nothing," but "does customer-facing transparency ship this half, or next?" Cachet's real value is that it makes this half the cheap answer.