Skip to content
finn.
Integrations Datadog

Integration · IT and identity

Datadog + Finn.

Datadog integration with Finn. Datadog collects application and infrastructure metrics, logs, and traces to help teams investigate service health.

Discuss this integration Explore the workflows

The work behind the connection

What you can do with Datadog.

Datadog collects application and infrastructure metrics, logs, and traces to help teams investigate service health.

Resolve an alert with the service runbook

Finn investigates a service alert, executes the authorized repair, and checks whether the customer-facing behavior recovers.

Typically handled bySite reliability engineer

Starts when

A Datadog monitor reports a condition covered by the service's response runbook.

What Finn handles

  1. Read the monitor, recent logs, affected service, and the runbook's conditions.
  2. Invoke the designated Datadog workflow or connected operations job for the accepted repair, obtaining incident approval where required.
  3. Follow the execution result and check both the service monitor and the affected application behavior.
  4. Update the connected PagerDuty incident with the completed action, recovery evidence, and any remaining problem.

The result

The alert has a recorded repair and observed recovery result, with unresolved work clearly identified.

Investigate and roll back a bad release

Finn connects a new service problem to release evidence and follows the team's accepted rollback through recovery.

Typically handled byOn-call release engineer

Starts when

Error or performance monitors deteriorate after a deployment.

What Finn handles

  1. Read the alert window, logs, and connected GitHub release history to identify the suspected change.
  2. Collect the incident owner's rollback decision and invoke the designated rollback workflow through GitHub Actions or Datadog Workflow Automation.
  3. Read the workflow result and verify the affected service's behavior in Datadog.
  4. Update PagerDuty and create the GitHub correction issue with the release and recovery evidence.

The result

The incident records the rollback's actual effect and the permanent repair work is linked to the release.

Diagnose a customer's technical failure

Finn uses the customer's request evidence to find the service failure and completes the corresponding repair or accurate resolution.

Typically handled bySupport engineer

Starts when

A Zendesk case reports a failed transaction or recurring application error.

What Finn handles

  1. Read the customer-provided reference and narrow the Datadog log search to the affected request and time.
  2. Connect the observed error to its owning service and determine the specific repair or customer correction needed.
  3. Execute the routine repair through the designated workflow or complete the reviewed code fix through GitHub.
  4. Verify the request's behavior and respond through Zendesk with the resolution and case reference.

The result

The customer receives a verified resolution based on the service evidence and completed corrective work.

Correct a noisy or misleading monitor

Finn investigates why a monitor is producing unhelpful alerts and implements the service owner's selected correction.

Typically handled byMonitoring engineer

Starts when

A service owner reports that a monitor's behavior does not match the condition it should detect.

What Finn handles

  1. Read the monitor query, recent alerts, service behavior, and the owner's intended detection criteria.
  2. Identify the specific scope, threshold, or timing mismatch and get the service owner's decision on the change.
  3. Validate and update the monitor configuration in Datadog.
  4. Observe the monitor against the service behavior and complete the maintenance issue with the change and verification result.

The result

The monitor reflects its accepted detection purpose and the owner has evidence of the corrected behavior.

Set up monitoring for a new service

Finn turns the team's service checks into working Datadog monitors and completes their operational handover.

Typically handled byObservability engineer

Starts when

A service is ready to enter the team's supported production environment.

What Finn handles

  1. Read the service's accepted health criteria, existing telemetry, owner, and incident-routing requirements.
  2. Create the monitors with the agreed queries, thresholds, and notification destinations.
  3. Validate the configuration and use the service's test procedure to check the monitor and notification path.
  4. Publish the monitor links and response instructions in connected Confluence and finish the readiness issue.

The result

The service has working health checks and a documented response owner and procedure.

Complete incident communications with current facts

Finn maintains the operational timeline and sends stakeholder updates based on the evolving service evidence.

Typically handled byIncident communications coordinator

Starts when

An incident owner starts the team's communications process for an active service disruption.

What Finn handles

  1. Read Datadog alerts and logs together with the incident owner's confirmed impact and response decisions.
  2. Publish the accepted status message through the connected Slack channel or status communication system.
  3. Update the incident record as repair workflows finish and new verification evidence becomes available.
  4. Send the recovery message after the owner accepts the restoration evidence and retain the final timeline.

The result

Stakeholders receive consistent incident updates and the record preserves the response and recovery facts.

Improve the runbook behind a recurring alert

Finn turns an accepted repeat-incident correction into a tested operational workflow and updates the team's instructions.

Typically handled byReliability automation engineer

Starts when

Repeated alerts reveal a specific manual runbook step the service owner accepts for automation.

What Finn handles

  1. Read the recent incident evidence and the exact action and decision conditions to automate.
  2. Update the existing Datadog workflow or its connected GitHub-owned execution code for the accepted repair.
  3. Test the response in the designated nonproduction service path and complete the owner's review.
  4. Publish the accepted workflow, observe its intended execution result, and update the Confluence runbook.

The result

The recurring response has a tested automation step and current instructions tied to its owner.

Deliver the service reliability review

Finn assembles a factual reliability review and completes the reporting and follow-up records for the service owner.

Typically handled byReliability operations analyst

Starts when

The service's regular reliability review is due.

What Finn handles

  1. Read the agreed review period and collect the monitor history, log evidence, and connected PagerDuty incidents.
  2. Summarize the recorded failures, recovery actions, and recurring conditions without asserting causes the evidence cannot establish.
  3. Publish the review in connected Confluence and record the service owner's accepted corrective tasks in Jira.
  4. Complete Finn-owned documentation or monitoring corrections and link their results to the review.

The result

The service owner receives a sourced reliability review with accountable corrective work and completed administrative follow-through.

Connection setup

Set up the connection around your work.

Contact Finn to discuss the records your workflow needs and the actions you want it to perform.

Your team chooses what Finn can access, what agents can change, and when a person must approve the work. The connection needs the appropriate account access and permissions from Datadog.

The Finn platform

Finn Agents

Help customers. Work with your team. Finish the job.

Explore Agents

Finn Systems

Business apps for the work behind the conversation.

Explore Systems

Finn AI Gateway

Control connected AI apps, models, access, and spending.

Explore AI Gateway

Meet Finn

Put your Datadog integration to work.

Tell us which records, actions, and teams the connection needs to support.

Discuss your workflow Get started