Waterline Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. An operator console for workflow health, history, queues, retries, and repair is classic "undifferentiated heavy lifting" — every team on a durable runtime eventually builds one. This package lets you buy that time back and redirect the engineering weeks toward product surface area instead.
• Roadmap weighting between reliability and features. The UI makes retry volume, queue depth, and stuck-workflow counts visible. That's the evidence base for arguing a reliability sprint, a queue-scaling investment, or a workflow-design cleanup before it becomes a customer-facing incident trend.
• Scoping "repair" as an internal vs. customer-facing capability. The package draws a clean line between observe (health, history, queues) and act (retries, repair). That framing supports a phased rollout: internal-only operator actions first, customer-facing self-service replay/retry later, with the associated authz and audit requirements made explicit up front.
• Support-tier and on-call design. If support engineers can triage a stuck workflow or a retry storm without paging a backend engineer, you can commit to a tighter SLA or a cheaper support tier without adding headcount proportionally.
• Incident-response investment case. History and repair views shorten mean-time-to-resolution and produce a post-incident artifact. Useful for justifying SRE tooling spend, and for compliance/audit stories where "who repaired what workflow, when" needs a record.
• Adoption-risk framing for the runtime itself. Whether you standardize on Durable Workflow as your orchestration layer is a bigger decision than this UI; but a credible operator experience is a real input to that decision, not an afterthought.

When to Consider This Package

Adopt / evaluate when:

• You are already running the Durable Workflow runtime (or are close to committing to it). This is leverage on an existing bet, not a reason to make one.
• You have on-call rotation, runbooks, or an SRE/support function that currently escalates workflow issues to engineers.
• You are actively spending sprint capacity on a homegrown admin dashboard, job-inspection page, or "requeue this thing" button.
• You need auditability around manual intervention — repair actions are a write path into production state, and having them centralized and attributable beats ad-hoc tinker sessions.
• You can absorb one more deployable: an operator UI is a service with its own auth, network placement, and upgrade cadence, not a composer line item you forget about.

Look elsewhere, or treat as a spike only, when:

• You are on plain Laravel queues. Horizon, Telescope, and Pulse already cover the observe-and-retry loop, are first-party, and have far deeper community support. Do not introduce a second runtime just to use its UI.
• You need vendor-backed support, an SLA, or a security review you can point at. MIT plus a small maintainer surface means you are the support contract.
• The adoption signals are thin — modest stars and effectively zero downstream dependents mean the integration path is largely untrodden. Budget for reading source, pinning a version, and potentially forking.
• You need a customer-facing embedded console. This is an operator tool; multi-tenant isolation, white-labeling, and end-user authz are your problem, not the package's.
• Repair actions cannot be constrained. If you cannot gate write access behind your own RBAC and audit logging, the UI is a liability regardless of how good the read views are.

How to Pitch It (Stakeholders)

To executives: We already depend on a durable workflow runtime, and today the only way to understand or fix a failing workflow is to interrupt an engineer. This is a free, MIT-licensed operator console that gives support and on-call staff read access to workflow health, history, and queue state, plus controlled repair actions. The business case is MTTR and engineering interruption cost, not license cost — the investment is a small amount of deployment and access-control work we'd have to do for any internal tool. The risk is maturity: adoption is early, so we should pilot it behind our own auth, pin the version, and keep the option to fork. Recommend a scoped 2–3 week evaluation against the alternative of building the same views ourselves.

To engineering: This replaces a dashboard we would otherwise build and maintain. It gives you history and retry introspection without writing one-off queries, and it centralizes repair actions that currently happen through ad-hoc scripts — which is both a safety and an auditability win. Costs: one more service to deploy, an auth/proxy layer in front of it, and a read of the source before we trust the write paths. We should treat it as vendored code we own operationally: pin it, wrap it, and be ready to fork if upstream stalls.