Fluidify Regen — Product Walkthrough

A complete guide to setting up and running on-call management with Regen

Regen is Fluidify AI's open-source, self-hosted on-call management platform. It handles alert ingestion, on-call scheduling, escalation paths, and incident handling end-to-end — with AI post-mortems, summaries, and handoff digests layered on top, using your own AI provider keys. Everything below is available in the free, open-source (AGPLv3) edition unless explicitly marked Pro.

Watch the complete walkthrough tutorial here

Under the hood, Regen runs on a Go backend, PostgreSQL for storage, Redis for queues and caching, and a React/TypeScript frontend — packaged as a single set of Docker images or a Kubernetes Helm chart. None of that is required reading to use the product, but it's part of why the platform behaves the way it does: predictable performance, a small operational footprint, and the ability to run entirely inside your own infrastructure with no calls out to a Fluidify-hosted backend.

This walkthrough follows the natural setup order: deploy the platform, connect your tools, configure AI, set up login, define alert routing, build your on-call schedule, set escalation policies, then move into the day-to-day incident lifecycle and AI features — closing with user management, migration tooling, and the underlying architectural guarantees that make the audit trail trustworthy.

1. Deployment

Before any configuration happens, Regen has to run somewhere — and because it's self-hosted, that "somewhere" is entirely yours.

• Docker Compose — the fastest path for a single-server deployment or evaluation. Brings up the Go backend, PostgreSQL, Redis, and the frontend together with one command.
• Kubernetes (Helm chart) — for production deployments that need to scale or run highly available. The Helm chart includes the Deployment, Service, Ingress, a Horizontal Pod Autoscaler, a migration Job that runs schema migrations automatically on upgrade, ConfigMap, and Secret resources.
• High availability — Regen is designed to run with multiple backend replicas behind a load balancer, PostgreSQL in an HA configuration (primary/replica), and Redis with Sentinel for failover, so the on-call platform itself doesn't become the single point of failure for your incident response.
• Zero-downtime upgrades — schema migrations are designed to run ahead of a rolling deploy, so upgrading Regen doesn't require taking on-call coverage offline.
• Data residency — because everything runs on infrastructure you control, alert payloads, incident content, Slack/Teams transcripts, and AI prompts/responses never leave your environment except to the AI provider you explicitly configure.

2. Initial Configuration

Regen is built to sit alongside the tools you already use — not replace them. The configuration screen is where every external connection lives.

2.1 Alert Source Integration

Connect whichever monitoring or alerting tool is emitting your alerts. Prometheus (via Alertmanager webhooks) is the example used most often — configured directly via webhook URL and a signing key, so Regen can verify incoming payloads are genuinely from your monitoring stack and not spoofed. Once connected, alerts from that source flow straight into Regen's ingestion pipeline.

Each incoming alert is stored with a full structured record, not just a notification string:

Beyond Prometheus, Regen ships generic webhook support, plus dedicated handlers for Grafana and AWS CloudWatch (via SNS), so multi-source environments don't need a translation layer in between.

2.2 Chat Tool Integration (Bidirectional)

Connect your team communication platform so incidents live where your engineers already work:

• Slack — connect a Slack app directly (bot token + signing secret, with optional socket-mode app token). The integration is fully bidirectional: any status change, timeline note, or AI-generated update made in Regen posts to the linked Slack channel automatically, and relevant activity inside that Slack channel — replies, slash commands like /incident new, status updates from the bot — reflects back into Regen's timeline in real time. A channel is auto-created per incident, so each incident gets its own dedicated thread of record.
• Microsoft Teams — the same bidirectional behavior as Slack, included in the free, open-source tier, with a few Teams-specific mechanics worth knowing about:
  • Channel creation and message posting run through two separate paths: standard Microsoft Graph API calls for channel management, and Bot Framework Proactive Messaging for posting — which gives Teams the same responsiveness as the Slack integration without requiring elevated delegated permissions.
  • The Teams bot understands direct commands (@Bot ack, @Bot resolve, @Bot status, @Bot new) and posts an Adaptive Card on incident creation and on every status change.
  • UI timeline notes sync to the Teams channel automatically, and non-command replies posted in Teams sync back into the Regen incident timeline — so a team using Teams gets full parity with a team using Slack, not a stripped-down version.
  • Known platform limitation: Microsoft Graph API doesn't support true archiving of standard Teams channels, so a resolved incident's channel is renamed with a [RESOLVED] prefix rather than archived outright. True archiving would require moving to Teams' private-channel model.

2.3 On-Call Notification Channels

For actually reaching the on-call engineer (calls, pages, push notifications) — separate from the team-wide visibility that Slack/Teams provides:

• Telegram — included free. Connect your Telegram account and on-call notifications and messages reach you there directly, independent of whether you're watching Slack.
• Fluidify Mobile App (Pro) — available on both the Play Store and the App Store, with native push notifications for incoming alerts, designed so the person actually being paged doesn't have to be staring at a desktop.
• Additional notification and voice-calling channels are available in the Pro tier beyond Slack/Teams/Telegram, for teams that want phone-call escalation as a fallback to chat-based notification.

2.4 AI Provider Configuration

Regen's AI features are bring-your-own-key — your incident data goes to the AI provider you choose, on your account, not to any Fluidify-operated AI backend. To configure:

1. Go to the AI configuration section.
2. Choose your model provider and paste in your API key. Supported providers include:
   • OpenAI
   • Anthropic (Claude)
   • Google (Gemini)
   • Self-hosted / local models
3. Select the specific model you want to use for generation (summaries, post-mortems, and handoff digests can all use the same configured provider).

Once a key is added, every AI feature in Regen becomes active — at no additional licensing cost from Fluidify. You only pay your model provider directly for the tokens you use. If no key is configured, Regen continues to function as a complete on-call and incident platform — AI is additive, never a dependency for core functionality.

2.5 Login & SSO

Team members can log in two ways:

• Email + password, created at account setup, backed by Regen's own auth layer (session handling, login page, logout).
• Single Sign-On (SSO/SAML 2.0) — if your organization already runs Google Workspace, Microsoft Entra/Azure AD, or Okta as an identity provider, connect it directly. SSO supports just-in-time (JIT) provisioning, meaning a new team member's account is created automatically the first time they log in through SSO — no separate manual invite step required before they can authenticate.

SSO is completely free in the open-source tier — this is a deliberate, permanent decision, not a launch promo. The Pro tier adds support for a wider range of identity platforms, but Google, Microsoft, and Okta — the providers most teams actually run — are already covered for free. Regen does not charge a "security tax" for letting your team log in safely; gating SSO behind a paywall is treated internally as user-hostile, since SSO is a security hygiene requirement, not a premium feature.

3. Alerting Routes

Alerting routes are where raw alerts get filtered, deduplicated, and turned into something worth an engineer's attention. This is the layer that determines whether your team gets paged ten times for the same underlying problem, or once.

3.1 Creating a Route

To create a new alerting route:

1. Define the resource the alert is coming from — i.e., which connected source (Prometheus, Grafana, CloudWatch, a generic webhook) this routing rule applies to.
2. Configure regex patterns to filter alerts — match against title, labels, or annotations to decide which alerts this route should act on.
3. Set rules to ignore alerts matching specific patterns entirely — useful for known-noisy checks, maintenance-window alerts, or low-value warnings you've decided aren't worth a page.

3.2 Deduplication

Deduplication is on by default. Alerts arriving from the same or multiple sources that match the same identifying pattern (typically the source system's fingerprint, combined with label matching) are automatically clustered into a single logical alert rather than creating duplicate noise. In practice, this means:

• A flapping check firing repeatedly doesn't create a new incident every time — it's recognized as the same underlying condition.
• The same underlying failure reported by two different monitoring tools watching the same service can be correlated rather than triggering two parallel response threads.
• Only alerts that clear the dedup and filtering logic go on to become incidents — this is what keeps the incident list meaningful rather than a flood of redundant tickets.

3.3 Routing → Incident Creation

Alert routing is directly paired with incident creation downstream: once an alert clears its route's filters and dedup logic, it can automatically generate an incident (subject to the severity thresholds you configure), fully populated with the alert's labels, annotations, and raw payload already attached — so the responding engineer starts with full context rather than a bare notification.

4. On-Call Schedules

Once alerts are routing correctly, the next step is defining who's actually on call.

4.1 Calendar & Rotation

• Full calendar view of your team's on-call rotation, showing every assigned shift at a glance.
• Layer-based rotations — schedules are built from layers, where each layer has its own rotation type (daily, weekly, or custom), a defined rotation start point, a shift duration, and its own ordered list of participants. Layers let you stack multiple rotation patterns on top of each other for the same schedule — for example, a weekly primary rotation layered with a separate, slower secondary rotation.
• Primary and secondary on-call assignment, configurable by day or by week, so there's always a clear first responder and a clear backup.

4.2 Time Zones & Holidays

• Multi-timezone support — team members across different time zones are displayed together in a single unified calendar, so a distributed team doesn't need separate schedules per region.
• Holiday and leave visibility — each team member's country-specific public holidays are shown automatically in the calendar, surfacing upcoming coverage gaps before they become a problem on the day itself.

4.3 Overrides

• Shift overrides — mark any individual unavailable for a specific day directly from the schedule (e.g., for a one-off leave or a swap), without restructuring the underlying rotation layers. Overrides are tracked as their own record, separate from the base rotation, so the original schedule definition stays clean and the override is auditable on its own.

4.4 Who's On Call, Programmatically

Beyond the calendar UI, the current on-call assignment for any schedule can be queried directly — which is what powers escalation routing, AI handoff digests, and any external tool that needs to know "who do I page right now" without a human checking the calendar manually.

This combination — layered rotations, time zone awareness, holiday visibility, and clean overrides — gives you a single place to manage rotation assignment, coordination across regions, and availability exceptions for the entire on-call team, rather than spreading that logic across spreadsheets and tribal knowledge.

5. Escalation Policies

Escalation policies define what happens when the on-call notification doesn't get a response — the difference between "an alert fired and nobody noticed for an hour" and "an alert fired and was handled in minutes."

5.1 Structure

• Configure a chain of responders — when the primary on-call doesn't acknowledge a page or message within a defined window, the policy automatically escalates to the next person in line.
• Escalation paths typically mirror your reporting structure — the next person "above" the primary on-call in the org, responsible for what happens if production breaks and revenue is at risk.
• Multiple tiers of escalation can be defined, so there is always someone accountable for an unacknowledged production issue, even if the first two people in the chain are unreachable.

5.2 Timeout-Driven Escalation

Each step in an escalation policy carries its own timeout trigger — if the current responder hasn't acknowledged within that window, the system automatically moves to the next step without anyone needing to manually intervene. This is what makes escalation reliable at 3am: it doesn't depend on a human noticing that nobody replied.

5.3 Where Escalations Show Up

Escalation activity isn't a separate hidden process — every escalation step (who was paged, when, whether they acknowledged, and when it moved to the next tier) is recorded as part of the incident's timeline, so after the fact you can see exactly how the escalation chain played out, not just who eventually picked it up.

This is the safety net that ensures a missed notification doesn't mean a missed incident.

6. Incident Lifecycle

This is where alerting, scheduling, and escalation come together into day-to-day operational use.

6.1 Views

Incidents are available in two layouts:

• List view — a straightforward, scannable list of all incidents, filterable by status, severity, and assignee.
• Kanban board view — incidents organized by status column, useful for seeing what's actively being worked versus what's resolved at a glance, without opening each ticket.

6.2 The Incident Record

Every incident is tracked with a structured record, including:

• A human-friendly, sequential incident number (e.g., INC-001, INC-002) alongside a stable internal ID
• Title, slug (a URL- and channel-name-friendly identifier), and summary
• Status — triggered, acknowledged, resolved
• Severity — critical, high, medium, low
• Linked Slack channel ID/name (or Teams conversation equivalent)
• Created by — tracked as either system-generated (from an alert) or user-created (manual), with the specific actor ID recorded either way
• A designated incident commander, if one is assigned

6.3 Timestamps — and Why They're Immutable

Four key timestamps are tracked per incident: created, triggered, acknowledged, and resolved. The first two are server-generated and immutable the moment they're set — they cannot be edited or backdated by anyone, including admins, through the UI or API. This isn't a configuration option; it's a deliberate architectural decision, because the value of an audit trail collapses the moment someone can quietly rewrite when something actually happened. If your compliance or post-incident review process depends on knowing the real sequence of events, that guarantee has to be structural, not policy-based.

6.4 Creating Incidents

Incidents can be created three ways:

1. Automatically, from a routed and deduplicated alert that clears severity thresholds — the incident is pre-populated with the alert's title, labels, and raw payload.
2. Manually, via the "create incident" button in the UI — fill in severity, priority, and summary, and attach evidence files directly to the ticket (screenshots, logs, anything relevant).
3. Via webhook / API, on demand from your existing alert management tooling or scripts — a direct API call from your terminal creates the incident immediately, with all the same fields populated as a manually created one. This is the same mechanism your monitoring stack uses under the hood, just callable directly.

6.5 Incident Fields

Each incident ticket includes:

• Severity and priority
• Summary
• File attachments (evidence)
• Assignee
• Start time and resolution timeline
• Linked alerts (one or more alerts can be attached to a single incident — useful when multiple related alerts represent the same underlying event)
• AI summary panel
• AI post-mortem panel
• Handoff digest panel

6.6 The Immutable Timeline

Every incident carries its own timeline — an append-only log of everything that happened, in order. Timeline entries record:

• A server-generated timestamp (immutable, same guarantee as the incident's own key timestamps)
• The entry type — status change, message, alert linked, escalation step, AI-generated content, etc.
• The actor type and ID — explicitly distinguishing whether a human, the system, or the Slack/Teams bot performed the action
• The content of the entry itself

Timeline entries cannot be edited or deleted once created — this is treated as non-negotiable for compliance purposes. If you need to correct or add context to something, you add a new entry; the original stays exactly as it was recorded. This is also what feeds Slack/Teams sync, AI summaries, and post-mortems — they're all reading from the same single source of truth, not a separate reconstructed log.

6.7 Custom Fields (Pro)

Beyond the standard fields, Pro lets you define custom fields — category, team, custom severity tiers, or any field your workflow needs:

1. Go to the custom fields configuration.
2. Add a new field, name it, and define its type.
3. The field is automatically applied to all future incidents with a default value, and can be filled in on existing tickets retroactively.

This lets the incident structure adapt to how your organization actually categorizes and tracks work — rather than forcing every team into a fixed schema designed for someone else's workflow.

7. AI Features

All AI features run on your own provider key (configured in Section 2.4) and are free and unlimited in the open-source tier — there's no paywall gating AI usage, no per-generation fee from Fluidify, and no token cap imposed by the platform itself. Open-source ships with sensible default prompts that work out of the box; Pro adds a dedicated UI for editing and constraining those prompts directly, without needing to touch configuration files or redeploy.

7.1 AI Post-Mortems

• Define one or more post-mortem templates (e.g., an "infrastructure" template, a "customer-facing outage" template, or whatever structure your team standardizes on) suited to different incident types.
• On any resolved incident, generate a post-mortem with one click — it's built from the incident's actual immutable timeline, not from someone's memory of what happened days later. This matters: the most common failure mode in post-incident review is writing the post-mortem from a fuzzy recollection 48 hours after the fact. Regen generates it from the literal recorded sequence of events.
• The generation prompt itself is editable directly in the open-source tier — change token limits, add special directives, or adjust tone/structure instructions without needing the Pro UI.
• Once generated, the post-mortem can be edited and published — the AI draft is a starting point, not a final document; a human is expected to review and refine it before publishing.
• Action item extraction — the generated post-mortem pulls out concrete follow-up action items from the incident discussion, rather than leaving them buried in prose.
• Post-mortems can be downloaded for audit/record-keeping (currently as a structured export), so you have a permanent copy outside the live system for compliance retention or external sharing.
• A template system lets you manage multiple post-mortem templates with full CRUD (create, read, update, delete) — so different teams or incident categories can have their own standard format.

7.2 AI Summary

• On any incident, generate an AI summary of the entire conversation and action trail for that incident, at any point in time — not just at resolution.
• Pulls from the same immutable timeline that feeds the post-mortem, so the summary reflects what actually happened, including system actions and Slack/Teams replies, not just manually-typed notes.
• Useful for getting an instant, accurate picture of "what has actually happened on this incident so far" without re-reading a long thread — particularly valuable for anyone joining the incident midway, or a manager checking status without interrupting the responders.
• Also supports Slack thread summarization specifically — condensing a long back-and-forth discussion thread into a digestible summary on demand.

7.3 Handoff Digest

• Purpose-built for shift changes: if your shift ends and the incident is still open, generate a handoff digest with one click.
• The incoming engineer gets a clear, structured picture of:
  • What's already been investigated and ruled out
  • What's been tried and what the result was
  • What still needs to happen next
  • The current overall status
• This removes duplicated investigation effort across shift boundaries — the incoming engineer doesn't have to re-derive context from scratch, and doesn't waste the first 20 minutes of their shift just figuring out where things stand.
• Like the AI summary, the handoff digest is generated from the immutable timeline, so it reflects the actual recorded history of the incident rather than a verbal handoff that can lose detail.

7.4 Why BYO-AI Matters Here

Because every one of these features runs on a key you provide, your incident content, post-mortem drafts, and timeline data are sent only to the AI provider you've explicitly chosen — never to a Fluidify-operated AI service. For regulated industries or teams with strict data-handling requirements, this is often the deciding factor over a SaaS incident tool that bundles its own AI layer with no opt-out.

8. User Management & Access Control

• Invite team members directly by email from the team management tab.
• Invited users can log in immediately using their SSO credentials once accepted, thanks to JIT provisioning (Section 2.5) — there's no separate manual account-creation step blocking them.
• No seat limits — the platform supports unlimited users (the default open-source configuration ships with a placeholder limit, currently set conservatively, that can be changed or removed entirely; it is not a licensing restriction).
• Role-Based Access Control (RBAC) (Pro) — define roles such as viewer, responder, and admin (or custom roles like manager/advisor), and restrict what each role can view, including restricted access to specific on-call schedules. This is particularly relevant for larger orgs where not every employee should see every team's rotation or every incident's full detail.

9. Migration & One-Click Import

Switching to Regen from an existing on-call/incident tool doesn't mean starting from zero. Regen supports one-click import — free, in the open-source tier — from:

• Grafana OnCall (including full schedule, incident, and alert history)
• PagerDuty
• Opsgenie

This is especially relevant for teams affected by Grafana OnCall's shift away from a self-hosted model toward a SaaS-only structure — those teams no longer have a self-hosted option with that tool and need somewhere to migrate their existing schedules and history to, rather than rebuilding everything by hand.

Additional import sources — Rootly, incident.io, FireHydrant — are available, but only in the Pro tier. If you need an integration that doesn't exist yet at all, custom integration requests are typically delivered within 3 days for Pro customers.

10. Integration Summary

Out of the box, in the open-source version, Regen integrates with:

• Kubernetes (Helm-based deployment, and as an environment Regen can run within)
• Prometheus (alert ingestion via Alertmanager webhooks)
• Grafana (webhook-based alert ingestion)
• AWS CloudWatch (via SNS)
• Slack (bidirectional, full incident lifecycle)
• Microsoft Teams (bidirectional, full incident lifecycle, Bot Framework-based)

…alongside the AI provider integrations (OpenAI, Anthropic, Gemini, self-hosted) and identity providers (Google, Microsoft, Okta) covered in Section 2.

11. Security & Architectural Guarantees

A few of the lower-level decisions in Regen exist specifically to make the audit trail and access model trustworthy for production and regulated use:

• Immutable audit trail by design — as covered in Section 6.3 and 6.6, every received_at, created_at, and timeline timestamp field is server-generated and cannot be edited or backdated, by anyone, through any interface. This is enforced architecturally, not by policy.
• Webhook signature verification — incoming alert webhooks are validated against a signing secret, so Regen doesn't act on payloads that didn't actually originate from your monitoring stack.
• CORS allowlisting and HSTS — the API only accepts cross-origin requests from explicitly configured origins, with HTTP Strict Transport Security enforced.
• Rate limiting — applied across multiple tiers to protect both the ingestion endpoints and the general API surface from abuse or runaway retry loops.
• Bounded queries — list endpoints (e.g., alert retrieval) are capped to prevent unbounded queries from degrading performance under load.
• Self-hosted by default — none of the above matters as much as the underlying fact that the database, the queue, and the application logic all run inside infrastructure you control. There's no Fluidify-operated backend in the request path for your alerts, incidents, or AI calls — your data only ever leaves your environment to reach the AI provider you've explicitly configured.

12. Why Self-Hosted, Unlimited, and Free Matters

A few principles run through every part of Regen's design:

• Unlimited by default — unlimited seats, unlimited incidents and alerts, unlimited post-mortems and AI feature usage in the open-source tier. Nothing core is paywalled.
• No SaaS tax — most comparable on-call/incident tools price per seat, typically in the $20–$100/seat/month range, plus separate charges for on-call notification features and AI add-ons. For a 10-person on-call rotation, that can realistically add up to several hundred dollars a month once on-call and AI costs are layered on top of seat pricing.
• Flat-rate Pro pricing — Regen's Pro/Enterprise tier is priced as a flat fee rather than per seat, which fundamentally changes the cost curve as a team grows: the same flat fee covers a 10-person rotation or a much larger one.
• Self-hosted, BYO-AI — your incident data and your AI usage both stay under your control. Nothing about how the platform works changes between free and paid tiers — Pro adds governance, integration breadth, and configuration depth, not core functionality. The open-source community edition is meant to be a fully functional product on its own, not a stripped-down trial.

A note on the numbers above: specific dollar comparisons will vary by team size, vendor, and current pricing — always verify current competitor pricing before publishing a head-to-head cost comparison.

Regen is open source and available on GitHub — clone it, self-host it, and see the full feature set for yourself.

What's Next

Regen is the first tool in Fluidify AI's broader AI-SRE suite. Coming next:

• Neuri — AI-powered root cause analysis
• Reflex — agentic workflow execution
• Gills — a conversational, natural-language interface to your backend systems

We'd keep announcing latest changelogs, roadmaps and other stuff on our Github pages and Slack community)