Kintaba Help & Documentation

Kintaba Documentation

Welcome to the Kintaba's documentation hub. You'll find comprehensive guides and documentation to help you start working with Kintaba as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Incident Lifecycle

Kintaba's process is based on well published and researched SRE incident management guidelines and includes the following cycle

Incident Initiation

The decision to start a new incident is most easily made by first determining whether or not the incident in question would benefit from the Kintaba process. Incidents are not just high priority tasks, they're active high-severity situations that generally require a group of people to mitigate and can impact the company publicly.

Incidents responders are expected to responded to in minutes, not hours, depending on the severity of the incident itself.

At initiation, an incident includes

  • Title - A short description of the incident (this may change as the incident is investigated)
  • Severity - A scale of SEV1 - SEV3
  • Owner - Defaults to the creator, and should be handed off to the point of contact who can actually fix the issue at hand.
  • IMOC - a senior and trained individual who is available to orchestrate the incident process when the owner is unable.

Incident Management

Once an incident as been created, Kintaba creates an Incident page where responders can collaborate quickly and stakeholders can monitor progress. The incident event log is a flexible space and can include operational discussion or high level updates depending on the needs of your organization.

Anyone with a Kintaba account can subscribe to the incident to be kept up to date.

Incident Mitigation

Once the symptoms of the issue have been mitigated, the incident changes status and remains in the Mitigated state until it is determined that the issue has been fully fixed.

Post Mortem

After an incident is closed, Kintaba will schedule a post mortem review automatically based on the organization's post mortem review cycle.

A post mortem is meant to determine the root systemic cause of the incident and is not meant to assign blame to individuals. Kintaba includes a default template for helping you write blameless post mortems, and you can create your own as well. See our Postmortem walkthrough for more details on writing an effective post mortem.

At least 24 hours before this meeting, the incident owner should complete the draft Post Mortem so it can be distributed before the meeting itself.

Post Mortem Review

Kintaba will automatically send out post mortem review meeting invites if there have been any incidents within the past review cycle.

At this meeting, followup tasks should be agreed upon and the post mortem itself should be finalized and closed for future reference.

Updated 10 months ago

Incident Lifecycle


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.