Operational failures are already confusing. The system that coordinates the response should reduce that confusion, not add a second incident inside the incident.

We are building Firewatch around a few direct ideas:

the current owner of an alert should always be clear;
schedules and escalation behavior should be inspectable before they matter;
responders should have context, runbooks, and a useful timeline in one place;
self-hosting should provide the complete product rather than a deliberately limited edition;
the managed cloud should operate the same product, not introduce an incompatible workflow.

Open and managed are deployment choices

Firewatch can run in your infrastructure with Docker Compose. Firewatch Cloud is for teams that want us to operate the application, persistence, storage, and notification delivery. The incident workflow remains the same.

That boundary matters. Teams should be able to begin with the deployment model that fits today without creating a future migration project just to change who operates the stack.

Calm is a product requirement

An incident tool is used when attention is fragmented and time is expensive. That means predictable routing, restrained interfaces, explicit ownership, and useful defaults are not polish. They are part of reliability.

We will use this blog for product decisions, implementation notes, and practical incident-response guidance. The documentation is the durable source for installing and operating Firewatch.