Skip to content
Scalpels home

Scalpels is officially launching on October 31, 2026. Special early adopter pricing is available now.

Muster

Any stack MIT licensed Experimental

A nightly backup that quietly stopped running three weeks ago is not an incident anything reports. Muster gives every scheduled task an expected rhythm and complains when a run does not arrive — late, then missed, by email or webhook — on hardware you already pay for, with no per-monitor pricing.

Work in progress. Available to teams with Unlimited.

Replaces
Hosted cron monitoring
Runs on
Your Laravel Cloud account
Needs
Compute · Database · Queue · Scheduler
Muster, watching a schedule Placeholder — the launch recording replaces this

What it watches

One question, answered honestly: did the thing report in on time?

  • Monitors with a rhythm

    A cron expression or a plain period, plus a grace window, is the whole definition — a job that usually takes four minutes gets a grace period longer than four minutes.

  • Registers itself

    Connect a Laravel app and every scheduled command becomes a monitor on its first run, using the command's real cron expression and timezone.

  • Starts, finishes and exits

    Muster tracks runs that started and never finished, runs that exited non-zero, and runs that were skipped, not just the silence between them.

  • Late, then missed

    Two thresholds, evaluated every minute. A monitor can pass through late into missed in a single pass when both are already behind it.

  • Alerts per failure type

    Email and webhook are independent channels, and you choose which failures each one carries. One alert per incident, and one when it recovers.

  • A weekly digest

    Every Monday, the previous UTC week's failures to every active account user — including a clean week, which sends an all-clear rather than nothing.

  • It is not a log store, and that is the point

    Muster never reads or stores your task's output. No stdout, no stack traces, no payloads — just whether the run reported in and how it ended. Nothing sensitive crosses the boundary, the database stays small, and there is exactly one question to answer when it goes red.

  • Your whole schedule, on its first run

    SDK

    The Laravel client subscribes to the framework's own schedule events, so a command you added this morning is a monitor this evening without anyone registering it. A cron job on a box that is not Laravel checks in with one authenticated HTTP request instead.

Muster vs. the incumbents

We rebuilt one row of their feature matrix

Healthchecks.io, Cronitor and Oh Dear are good products, and Muster is not trying to replace them. It does one slice of what they do — notice when a scheduled task stops reporting in — on infrastructure you own, and deliberately does not do the rest. The question is not which product is better. It is which slice you are actually using.

Muster feature comparison
Feature Muster Self-hosted, MIT Healthchecks.io Hosted, or self-host Cronitor Hosted Oh Dear Hosted
Check-in history on infrastructure you own the row we rebuilt Does this well:Your Cloud account Partly, or with a caveat:Self-host available Not built:Hosted only Not built:Hosted only
A Laravel schedule registering itself the row we rebuilt Does this well:Every command, first run Not built:Register by hand Partly, or with a caveat:Generic integrations Partly, or with a caveat:Laravel package
Start, finish and exit-code tracking Does this well:All four states Does this well:Included Does this well:Included Does this well:Included
Capturing the task's output we did not build this Not built:Never stored Does this well:Included Does this well:Included Partly, or with a caveat:Limited
Uptime, SSL and broken-link checks we did not build this Not built:Schedules only Not built:Schedules only Does this well:Included Does this well:Their core strength
SMS, phone, Slack and pager routing we did not build this Not built:Email and webhook Does this well:Many channels Does this well:Many channels Does this well:Many channels
On-call rotations and escalation we did not build this Not built:Not built Not built:Not built Works, but on their terms:Higher plans Partly, or with a caveat:Via integrations
Where your check-in history lives Does this well:Your own database Partly, or with a caveat:Theirs, or yours Works, but on their terms:Their cluster Works, but on their terms:Their cluster
Cost of the next monitor Does this well:A database row Works, but on their terms:Per check, by plan Works, but on their terms:Per monitor Works, but on their terms:Per site, by plan
Who is on call for the tool itself Partly, or with a caveat:You are Does this well:They are Does this well:They are Does this well:They are
  • Does this well
  • Partly, or with a caveat
  • Not built
  • Works, but on their terms

The honest test

Ask what the cron monitor is actually for on your team. If these are all true, you are paying per monitor for a suite to use one row of it.

  • The question you ask it is "did last night's job run?"
  • Email or a webhook into the channel you already watch is enough.
  • You would rather own the check-in history than rent it.

Then you lose very little by moving. Muster is experimental today, so start by pointing one noisy schedule at it; the history stays in your own database either way.

Keep paying them if

These are the parts we chose not to build, and we are not going to pretend otherwise.

  • You want the failing task's output stored alongside the alert.
  • You want uptime, SSL expiry and broken-link checks in the same tool.
  • You need SMS, phone calls, Slack or a pager rather than email and webhooks.
  • You need on-call rotations, escalation policies or an SLA from a vendor.

Small, sharp tools are a deliberate scope, not an unfinished roadmap. Muster will not grow into an observability platform.

Be honest about it

You don't need us to run Muster

The repository is public and MIT licensed. These are the steps, and you are welcome to spend the afternoon doing them by hand.

  1. 1

    Fork the Muster repository into your own GitHub organisation.

  2. 2

    Deploy the fork to Laravel Cloud with its own compute, Postgres, a managed queue and the scheduler enabled, then point it at a mail transport that really delivers.

  3. 3

    Install the client in your Laravel app and let its schedule register itself, or check in from anything else with one authenticated HTTP request.

Or buy Unlimited once. Scalpels forks it, provisions exactly what it needs on your Laravel Cloud account, and deploys it. The app and the infrastructure are yours either way — the only question is who spends the afternoon.

Deploy Muster with Unlimited

Muster pairs with the rest of the suite

Muster tells you a scheduled job stopped reporting in; Hone tells you what it was doing when it was still running. Bobbin is the same question pointed at the requests arriving from outside, and Capstan is the schedule an agent ecosystem keeps.