Export incident data using our Singer tap

Weekly Update

Incident data can be incredibly powerful - helping you to improve your processes, minimise recurring issues, and ultimately build better products for your customers.

We provide insights within our dashboard but we understand that joining incident data alongside your own can help to improve your understanding even more.

Previously the main method for extracting your incident data was to query our API. We provide endpoints for things like incidents, roles, severities, and much more.

Often though you will want to take that data regularly and store it in a data warehouse such as BigQuery, Redshift, or Snowflake. Doing so can take time to build, test, and maintain. To save you that effort we have now released a Singer tap which you can easily install and run on your own infrastructure.

We’ve built an integration with Singer (an open-source specification) to easily extract your data. The great part about Singer is that a lot of people have already built taps and targets for you - allowing you to simply put the parts together that you need.

To get started using our Singer tap see the project documentation here

We’ve also applied to have our tap approved by Stitch (a platform to run and manage your data-pipelines) who support running Singer taps and targets.

Fallbacks in expressions

You can now add fallbacks to queries in your expressions!

Often when building an expression for a custom field there is a worry that the query might return nothing. This is no longer the case! You can now easily choose what to do should the query return no result.

We use this ourselves when defining the Affected Team in an incident allowing us to safely fallback to the more general “Engineering” when we are unsure which team to involve.

Custom post-mortem names by incident type

Post-mortems come by many names whether it’s debrief, action-review, or learning document - whatever you want to call them you can define that name globally within the post-mortem settings.

Sometimes though, depending on the type of incident that’s occurred, you may want a different name entirely.

You now have the ability to customise the post-mortem name for an incident type within the incident types settings - give it a go!

🚀 What else we’ve shipped

  • 🆕 Atlassian Statuspage URLs are now available as a variable in workflows and templates
  • 🆕 You can now use a variable as the link target in our rich text editor
  • 💅 We’ve tweaked some of our status page colour palettes for better consistency
  • 💅 When creating sub-pages of a status page, there’s now better spacing the blocks for each sub-page
  • 💅 If you try to view an incident on an internal status page that has been removed, we’ll now show a more helpful error page
  • 💅 If you uninstall the Linear integration, we’ll now automatically disable any Linear export templates
  • 💅 When you export a post-mortem to Notion, the ‘Follow-ups’ section is now shorter and easier to read
  • 💅 The incident summary text box got a little design love
  • 💅 Status page maintenance events with "automated updates enabled" now have an explanatory tooltip
  • 💅 The "filters" dropdown in the timeline can now be scrolled when there are longer lists of options
  • 💅 In Saved Views, "Clear view" is now "Exit view" for clarity
  • 💅 Fixed the padding on the text we show you when your filter returns no incidents
  • 💅 The Cmd-K window now has the correct height when it gets too long
  • 💅 We now show the OpsGenie team alongside any mentions of their escalation policies
  • 💅 You can now change the incident's call link from the dashboard
  • 💅 We no longer display test incidents on internal status pages
  • 🐛 We now handle creating issue tracker templates with the same name
  • 🐛 Incidents created via our API now truncate long API key names in the sidebar to save space
  • 🐛 When declaring a new incident, we no longer include resolved incidents in list of recent incidents
  • 🐛 Automated resolved messages configured in a workflow are now shown on public status pages
  • 🐛 We fixed displaying sub-page component descriptions
  • 🐛 The notifications sidebar in the dashboard now handles empty codeblocks in timeline comments
  • 🐛 Fixed a bug where switching operators in workflow conditions did not properly clear out the current selection
  • 🐛 We no longer notify a user that a Jira field has changed in an incident ticket if it has not been set a value in the issue template
  • 🐛 Fixed a bug where text flashes when hovering over grouped affected components on a status page
  • 🐛 We no longer allow the 💥 emoji reaction to be used to create an action after an incident is closed
  • 🐛 Scrolling on the ‘create a workflow’ page now doesn’t let you scroll beyond the bottom of the page
  • 🐛 Fixed an issue where sometimes it would take two attempts to clear a rich text input
  • 🐛 The users page now correctly sorts owners and admins
  • 🐛 Fixed an issue where filtering incidents by status_category in our public API didn’t quite work as expected
  • 🐛 We've stopped sending duplicated status update messages when moving through the learning flow

Modern incident management, built for humans