OpsGuard.
Structure behind
every response.
An operations management platform being built to connect organizations, teams, services and incidents. Clear relationships and explicit rules form the foundation for operational visibility.
An incident needs
its context.
When teams and services multiply, disconnected records make simple questions harder: which service is affected, who owns it, and who is responding?
OpsGuard starts with the relationships behind those questions. People belong to organizations, membership connects them to teams, and services have an owning team. Each incident references an organization, an affected service and its creator.
Response assignment is separate from service ownership. An incident may be assigned to a team, then to a user who belongs to that team.
Clear domains.
One application.
The modular-monolith approach gives the backend distinct areas of responsibility within one Spring Boot application. Domain logic, API handling and persistence have defined places in the code.
Keeping these areas together makes development and deployment manageable at this stage. The structure gives future capabilities a place to grow without requiring independently deployed services from the outset.
The operational context
People within an organization
Responsibility and ownership
The connection between people and teams
Systems with an owning team
A structured response to an affected service
Every transition
has a rule.
The backend exposes explicit lifecycle actions. Each action requires the previous state, so an incident cannot jump directly from open to closed.
A record of the response
Lifecycle changes also create timeline events. The current implementation rejects out-of-order transitions and prevents assignment changes after closure.
- 01
Open
Created with an affected service and a creator.
- 02
Acknowledged
Acknowledge the incident; record the time.
- 03
Investigating
Start investigation after acknowledgement.
- 04
Mitigated
Mark mitigation after investigation.
- 05
Monitoring
Start monitoring after mitigation.
- 06
Resolved
Resolve after monitoring; record the time.
- 07
Closed
Close after resolution; record the time.
Rules carried through
the whole workflow.
A useful API needs more than endpoints. Input constraints, domain decisions and stored relationships need to agree, with predictable errors when a request cannot proceed.
- 01
Validate the request
Request DTOs define required fields and constraints before input reaches the application workflow.
REST APIs · DTO validation - 02
Apply the domain rules
Application services coordinate organization-scoped lookups, lifecycle actions and transactional changes.
Java · Spring Boot - 03
Keep the data explicit
PostgreSQL stores the operational relationships. Flyway migrations version the schema, including foreign keys and uniqueness constraints.
PostgreSQL · Flyway
Consistent error responses
A shared API error structure covers validation failures, missing resources and conflicts, including invalid lifecycle transitions.
- Status
- Code
- Message
- Field errors
- Path
- Timestamp
A recorded development milestone. This is a historical checkpoint, not a live test count or a production reliability metric.
Check the valid path.
Challenge the rest.
Automated tests give the domain rules concrete examples to hold against as the backend evolves. The source includes checks for more than successful requests.
- Lifecycle order and invalid transitions
- Records outside the requested organization
- Team membership and incident assignment
- Request validation and API error behavior
A foundation still taking shape.
OpsGuard remains pre-release. The current work establishes the backend model and operational rules as a foundation for further capabilities. The diagrams on this page explain that engineering; they do not represent a released product interface.