A safe incident loop for Sentry, Slack and Tomosu

Teams often want a simple outcome from incident automation: handle the routine failures without waking a senior engineer, and escalate the rest with enough context to act. Sentry, Slack and Tomosu can each play a role in that workflow. They do not, on the facts available, form a turnkey automated remediation system.

The useful distinction is between detecting, prioritizing and changing production. Sentry can provide error and alert signals. Slack can carry notifications and handoffs. Tomosu evaluates code, dependencies, infrastructure and runtime signals, then produces a Production Reliability Index (PRI) to help prioritize fixes. Its documented product capabilities do not say that it executes production fixes or directly connects to Sentry or Slack. Build the workflow around that boundary.

Define the tiers before wiring tools together

Start by writing down what your team means by L1 and L2. These labels vary between organizations. For this workflow, L1 should mean a known, bounded issue with a tested runbook and a low-cost rollback. L2 should mean the issue needs investigation or a more consequential change. Make those definitions explicit in the incident policy, not implicit in an automation prompt.

For example, a runbook might permit one retry or a reversible restart for a specific, recognized failure. It should stop after a fixed number of attempts, on unexpected symptoms, or when customer impact crosses a threshold. An L2 case should gather evidence and notify the responsible engineer rather than apply an unreviewed change. These are policies your team implements; they are not Tomosu features.

Build the signal and context path

1. Detect in Sentry. Configure alerts around actionable errors and include the service, environment, affected release and a link to the relevant event. Reduce duplicate notifications before sending them to an incident channel.
2. Route in Slack. Use a dedicated channel or existing incident process to separate notification from decision-making. The message should identify the alert, its severity, the runbook and the owner. Slack is the communication path, not the source of truth for whether a remediation is safe.
3. Bring reliability evidence into view. Tomosu evaluates runtime signals as well as code, dependencies and infrastructure, and uses the context it receives to produce a PRI and findings. Check whether the telemetry and incident context your team wants to use are available to Tomosu in your environment. Do not assume a native Sentry connector or automatic Slack handoff; the documented facts do not establish either.
4. Keep action in your controlled runbook. If your existing incident tooling can invoke an approved action, make it conditional on the alert identity, environment and runbook limits. Record the action and its result. Tomosu can inform prioritization; your automation and authorization controls determine whether anything changes in production.

Make L1 automation narrow and L2 escalation useful

A practical L1 policy allows only a small list of deterministic actions. Require a matching alert signature, a healthy dependency check and a known deployment state before the runbook proceeds. Stop on a second failure. Send the outcome to Slack, including what ran, what changed and whether the service recovered. If any prerequisite is missing, route to a person.

For L2 incident remediation, favor evidence collection over automatic changes. Put the Sentry event, recent release, relevant runtime observations and any Tomosu reliability findings in the handoff. A PRI can help rank weaknesses; it is not by itself an incident severity score or permission to modify a running service. Keep the engineer responsible for deciding whether a code change, rollback or infrastructure action is appropriate.

This is the honest version of automated L1 incident resolution: automate a tightly bounded runbook around a known failure, not open-ended diagnosis and repair. Slack incident automation should make the handoff faster and more legible, not turn a notification into blanket approval. For teams considering the larger boundary between signals and action, the case for closing the runtime loop is a useful framing.

Test the workflow before relying on it

Exercise the path with a staging alert or a controlled test. Confirm that the alert reaches the right Slack destination, that the context is sufficient to identify the runbook, and that the runbook halts when a safety condition fails. Test duplicate alerts, missing telemetry and a failed remediation. Verify who receives the escalation and where the action history is recorded.

Then review real incidents. Did the signal arrive early enough? Did the L1 rule avoid unnecessary pages without hiding a worsening issue? Did Tomosu’s findings help prioritize a durable fix? Adjust thresholds and runbooks based on evidence, and keep changes to production subject to the controls your team already trusts.

The stack’s value comes from clear boundaries: Sentry detects, Slack routes, Tomosu evaluates reliability context, and your runbooks govern operational actions. That can reduce routine toil. It does not justify claiming a direct Sentry-Tomosu integration or hands-off L2 repair unless those capabilities are verified in the deployment you operate.