Build Instatus
KINDAback to the verdict
Before step 1
you will need
- A host that is not the infrastructure you are reporting on, ideally a different provider entirely
- A separate domain or subdomain on separate DNS
- A transactional email provider with a verified sending domain, e.g. Resend or Postmark
- Somewhere to store subscribers that survives a reboot
Delivery order
Scaffold the smallest runnable application and document its commands.
done whenThe project starts from a documented command in a clean checkout.
Implement the primary data model and core workflow.
done whenThe main object can be created, read and changed end to end.
Add validation, safe failure states, and persistence.
done whenBad input is refused with a readable message and nothing is left corrupted.
Cover the critical path with automated tests.
done whenThe highest-risk behavior fails the suite when it breaks.
Exercise a clean install from the README and fix every missing step.
done whenA fresh clone reaches the first successful workflow using only the README.
That is the whole plan for Instatus. What it deliberately does not cover is below · check the gaps before you call it a replacement.
- Deliverability someone else warms up and monitors: your first incident email is also your first send reputation test
- Notification channels beyond email: SMS, Slack app, Teams, Discord, native webhooks, RSS, all of which Instatus ships out of the box
- Per-component subscriptions, unsubscribe handling, and double opt-in that you do not have to think about
- The polish: scheduled maintenance windows, incident templates, timezone handling, embeddable widgets, public API
- Real independence, unless you actually do the work to host the page away from your own stack
Need the files? The project pack on the verdict page hands your agent the whole brief · more uptime.