Source: https://joinfinn.com/integrations/datadog

# Datadog

## Datadog + Finn.

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

Business function: IT and identity.

## 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 by:** Site 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 by:** On-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 by:** Support 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 by:** Monitoring 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 by:** Observability 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 by:** Incident 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 by:** Reliability 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 by:** Reliability 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

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.

## Explore Finn

- [Agents](https://joinfinn.com/agents): Help customers. Work with your team. Finish the job.
- [Systems](https://joinfinn.com/systems): Business apps for the work behind the conversation.
- [AI Gateway](https://joinfinn.com/ai-gateway): Control connected AI apps, models, access, and spending.

[All integrations](https://joinfinn.com/integrations)

[Discuss this integration](https://joinfinn.com/contact)

[Discuss your workflow](https://joinfinn.com/contact) · [How it works](https://joinfinn.com/demo/app/#/w/borough/overview) · [Get started](https://joinfinn.com/app/#/signup)