Nova Ohdear Tool Laravel Package

Technical Evaluation

• Architecture fit: This is a Laravel Nova tool, not a general-purpose Laravel package. It only fits estates already running Nova as the internal admin surface, and it inherits Nova's auth, layout, theme, and navigation for free. As a TPM, treat this as a thin display layer over an existing Oh Dear subscription — it consolidates a dashboard, it does not add a capability. If the org isn't on Nova or isn't on Oh Dear, the architecture fit is zero and the package is irrelevant regardless of its quality.

• Integration feasibility: Low effort, standard Nova tool wiring: composer require, register the FQCN in NovaServiceProvider::tools(), publish config/assets, set OHDEAR_API_TOKEN, verify the sidebar item. A Nova-fluent engineer does this in under half a day, including gating with canSee/authorize. The absence of migrations, scheduled jobs, and write-back paths keeps the blast radius small — this is a read-only viewer, which is exactly the profile a TPM wants for a first experiment in a shared admin panel.

• Technical risk: Three distinct risks, and a TPM should size each separately.

  1. Version drift (high, likely). Last release April 2021 (v1.1.4, a cosmetic "tool page title" patch, #31), built against Nova 3.x. On Nova 4/5 expect Composer constraint conflicts, Vue asset registration breakage, and requiring a fork to function. This is the primary adoption gate.
  2. Metadata/description mismatch (medium, must resolve before sign-off). Metadata says "display the application log"; README, package name, and integrations describe Oh Dear site monitoring. These have completely different security reviews — log contents and local file paths vs. an API token scoped to a monitoring account. A TPM should not approve adoption until engineering confirms from source which capability ships.
  3. Token handling and API drift (medium). The Oh Dear token grants read access to the monitoring account; it belongs in a secret manager and config/services.php, never committed in the published config. Oh Dear API changes since 2021 are unaddressed by upstream.

  Favorable: MIT license means forking and internal patching is legally and practically frictionless — the risk is ownership cost, not lock-in.

• Key questions to close before committing:

  • Which capability actually ships — Oh Dear monitoring, log viewer, or both? Confirm by reading the tool class and Vue component, not the metadata.
  • Which Nova / Laravel / PHP versions are supported by composer.json constraints, and what does our upgrade horizon look like?
  • If log viewer: how is authorization, redaction, and local-file access handled? Multi-node or remote logs?
  • If Oh Dear: which team is the token scoped to, how is it rotated, and does the tool cache API responses (rate limits, cold-load latency)?
  • Who owns the fork if upstream stays dormant, and what's the exit if a Nova upgrade breaks it?

Integration Approach

• Stack fit: Adopt only when all hold: Nova 3.x-era stack (Laravel 8 / PHP 7.x) with no near-term major upgrade, Oh Dear already the source of truth for uptime/SSL/broken-link/schedule checks, and an internal audience of engineers and PMs with Nova access. The value proposition is "one fewer tab during incident triage and post-deploy confirmation" — a real but modest win. If any of those conditions fails, a first-party Nova card backed by Oh Dear's API is comparable effort with better long-term fit.

• Migration path: There is essentially nothing to migrate — no schema, no data, no background processes. Adoption is additive and reversible: register the tool, gate it, confirm it renders, and remove the registration if it doesn't. This is the strongest argument for a bounded trial: the rollback cost is one line in NovaServiceProvider.

• Compatibility: This is where the integration either succeeds or quietly becomes a fork project. Sequence the compatibility check first, in a throwaway branch:

  1. Read composer.json constraints against our locked Nova/Laravel/PHP versions.
  2. Attempt install in a staging Nova instance; capture constraint conflicts.
  3. If the install fails or assets don't register, stop and re-decide — do not sink time into patching before the fork decision is made explicitly. Also verify the Oh Dear API responses the Vue component expects still match current Oh Dear payloads; a 2021 client against a 2025 API is a plausible empty-state failure.

• Sequencing:

  1. Resolve the capability question (log viewer vs. Oh Dear monitor) — blocks everything, including the security review.
  2. Compatibility spike in staging, time-boxed to one day; output is a go/fork/no-go decision.
  3. Fork-and-pin decision. If go, pin the version and vendor the fork; if no-go on install, evaluate the ~50-line first-party card alternative before abandoning the capability.
  4. Security and access review matched to the confirmed capability (token scope and rotation, or log redaction and file access).
  5. Gate and pilot with canSee restricted to ops/on-call, plus environment-aware registration so staging and production point at different Oh Dear teams and the tool simply doesn't register where no token exists.
  6. Promote to the broader Nova audience only after a full on-call cycle with no rendering failures.
  7. Explicit non-goal: do not wire this into deploy pipelines, paging, or SLA reporting. It is a viewer; Oh Dear's native Slack/email alerting remains the paging path.

Operational Impact

• Maintenance: The dominant ongoing cost. Upstream velocity is negligible — a single cosmetic patch in the last release and zero dependents means no third-party guidance, no community fixes, and no expectation of timely patches. Plan for fork-and-own from day one: vendor the code, pin the version, and assign an owner. The realistic maintenance surface is small (a tool class, a Vue component, a config file) but the upgrade tax against Nova and Oh Dear's API recurs at every major bump. Budget it as "internal tool with a maintainer," not "dependency."

• Support: No vendor support, no SLA, no security patching commitment. Internal support is limited to two knobs — the published config (token, cache TTL) and canSee/authorize. Anything richer (filtering, per-check detail pages, alerting hooks) means forking the Vue component. Set stakeholder expectations accordingly: this is a convenience artifact, not a platform bet, and it should not appear on a roadmap that spans more than a year without a fork owner named next to it.

• Scaling: Two scaling axes, both modest.

  • Sites and API load: the tool calls Oh Dear's API on render. With many monitored sites or no caching, page loads get slow and you approach Oh Dear's rate limits. If the package exposes a cache TTL, tune it; otherwise add caching in the fork. This is the most likely day-two operational complaint.
  • Users: cost is near-zero per additional viewer since it's read-only, but every Nova user sees the tool by default — so scale the audience deliberately via canSee rather than letting a monitoring dashboard appear for PMs who can't act on it.

• Failure modes to document in the runbook:

  • Blank or empty tool page — most commonly a stale cached config or missing/expired token. Check config:clear, token validity, then Oh Dear's status page, then storage/logs/laravel.log. The package tends to render API errors as an empty state rather than a clear message, so the failure is silent and needs a documented triage path.
  • Sidebar item missing after deploy — tool not in tools(), canSee/authorize returning false, or assets not re-published (nova:publish --force).
  • Silent blanking under config:cache — caused by reading env() directly inside tool config instead of config/services.php; standardize the token as a named service config key.
  • Nova upgrade breakage — a Vue/asset incompatibility that manifests as a missing or broken page after a platform bump. Detect in staging, not production; this is why the fork needs an owner.
  • Oh Dear API drift or outage — degraded or empty display; the operational mitigation is procedural: the tool is a first-glance surface, so on-call falls back to Oh Dear's own UI and Sentry/Telescope/Horizon for the app-level dive.

• Ramp-up: Very low for end users — a new sidebar entry that lists monitored sites and drills into uptime, SSL, broken links, and scheduled jobs; no training beyond "scan for red, click through." Engineering ramp-up is also low (small, permissively licensed, readable source) but front-loaded on the two discovery items: the capability discrepancy and the compatibility spike. The highest-leverage adoption pattern is to put a dashboard card in front of the tool so health is glanceable on /nova before anyone thinks to open the tool — that is the change that alters day-to-day behavior, and it's the one thing worth insisting on during the pilot.