Cachent Laravel Package

Product Decisions This Supports

• The real decision is upstream of this package: Cachet vs. a hosted status page. Cachent is a Laravel client for the Cachet status-page API. Adopting it is a downstream commitment to Cachet as your incident-communications platform, so treat "Cachet vs. Atlassian Statuspage / Instatus / Better Stack" as the actual product decision, and this package as a follow-on convenience if you pick Cachet.
• Manual vs. automated incident comms. The capability this unlocks is status updates driven by code rather than a human remembering to post: deploy pipelines flipping a component to "degraded," monitoring webhooks opening an incident, change-management records pushing maintenance schedules, post-incident metrics published automatically. That is a workflow and reliability decision, not a library decision — but the library is what makes it cheap to try.
• Build vs. buy, where both sides are cheap. The wrap surface is a thin fluent client over Cachet's REST endpoints (components, incidents, incident templates, metrics, schedules) with a service provider, publishable config, token/basic auth, and facades. The alternative is ~100–200 lines of your own HTTP client. Buy wins if you want the conventions and someone else tracking Cachet API changes; build wins if you already have an HTTP-client pattern in-house and want zero extra dependency. The cost of being wrong in either direction is small, which is the important part.
• Roadmap impact from v2.2.1: none. Patch release, one commit, "resolve bug with missing file." No new endpoints, no deprecations, no breaking changes. Treat it as a maintenance signal, not a capability signal — do not let it gate or unblock any roadmap item.
• Release hygiene as an input to the vendor comparison. A missing file in a distributed artifact points at packaging (.gitattributes / export-ignore / build artifacts), not runtime logic. That's a mild CI smell worth weighing against alternatives, and a concrete reason to constrain at ^2.2.1 rather than leave a floating range that can resolve to the broken 2.2.0.
• Adoption tier and reversibility. 9 stars, 0 dependents, single maintainer, MIT. This is a "one squad decides, no architecture review" dependency — appropriate precisely because the exit plan is "vendor the behaviour ourselves in an afternoon." Keep it off the critical path of the incident-response flow.
• Scope caution worth flagging internally. The name reads like a caching library, and prior internal write-ups have scoped it as one (cache TTLs, key namespacing, Cache::spy() smoke tests). It is not. Before anyone budgets time against it, confirm the team understands this manages status pages, not cached reads. Mis-scoped diligence is a real risk here.

When to Consider This Package

Consider it when:

• You have already chosen (or are genuinely leaning toward) self-hosted Cachet, and you run Laravel.
• You want status updates automated from deploy hooks, monitoring alerts, scheduled maintenance windows, or incident postmortems — and you'd otherwise hand-roll HTTP calls.
• API token or basic auth plus publishable config is work you'd rather not repeat per project.
• You want the framework-agnostic core as an escape hatch (the client is usable outside Laravel, which lowers lock-in to the Laravel wrapper specifically).
• You're on a Laravel/PHP version inside the 2.x support matrix — verify against composer.json, don't assume.
• You're comfortable with single-maintainer open source and have a plausible in-house fallback.

Look elsewhere when:

• You haven't picked a status-page platform yet. Most hosted vendors ship first-party integrations and webhooks; choosing a platform to justify a client library is backwards.
• You need vendor SLAs, indemnities, or commercial support — no single-maintainer package can provide them, regardless of code quality.
• Public incident communication is core to your brand promise. Then you want to own that path, not depend on a small OSS client plus a self-hosted Cachet instance.
• You need capabilities Cachet's API doesn't expose (rich subscriber segmentation, third-party status ingestion, advanced on-call routing). The client can't exceed the platform.
• Your diligence finds Cachet itself is thinly maintained. Upstream risk dominates client risk here.

Diligence checklist before adoption: confirm the file actually ships in the 2.2.1 tarball via a clean composer install in CI (empty Composer cache, no --no-scripts surprises); check release cadence over the last 12–18 months; confirm the Laravel support matrix; check Cachet's own maintenance status; and validate all writes against a staging Cachet instance before anything touches a production status page — a bad automated update is publicly visible.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating Cachent, a small MIT-licensed Laravel client for the Cachet status-page API. It lets us automate public status updates — marking a component degraded on deploy, opening an incident from an alert, publishing scheduled maintenance and post-incident metrics — instead of relying on someone remembering to do it manually. The latest release, v2.2.1, is a maintenance patch that fixes a missing file in the distributed package: no new features, no breaking changes, no migration cost. The decision is low-stakes and reversible — the worst case is we reimplement a thin HTTP client in-house. Two caveats: it's a single-maintainer project without commercial support, and it presumes we've already chosen Cachet as our status-page platform, which is the larger and more consequential decision. Keep it out of any critical path.

For engineering (one paragraph): Cachent is a fluent Laravel client over Cachet's REST API — components, incidents, incident templates, metrics, schedules — with a service provider, publishable config, API-token/basic auth, facades, and a framework-agnostic core. v2.2.1 is a patch on v2.2.0 with a single commit fixing a missing file in the published artifact; the expected action is a constraint bump to ^2.2.1 plus a clean-room composer install in CI to prove the archive is complete, with no application code changes anticipated. Before we build on it: verify the Laravel/PHP matrix in composer.json, confirm the repo's CI actually publishes and smoke-tests the dist archive (this class of bug suggests it may not), and check Cachet upstream's maintenance status. Also note the name is misleading — this is not a cache layer, so don't let it inherit caching-related requirements. Fallback if it goes unmaintained: the surface is small enough to vendor or replace with a direct HTTP client.