Lindy Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Breaking: Major outage today - what's your backup plan?

Emily Roberts — Mon, 28 Sep 2026 02:56:23 +0000

Today's multi-hour outage of the Lindy platform has, predictably, disrupted a significant number of automated workflows. While the status page cites "database connectivity issues," the broader implication for any team relying on Lindy as a primary automation layer is a stark reminder of single points of failure. This incident prompts a critical architectural question: what is your operational backup plan when your primary automation orchestrator becomes unavailable? From an SRE and observability perspective, the failure of a central automation tool creates a dual problem. First, there is the immediate loss of business logic execution (scheduled reports, customer onboarding sequences, data syncs). Second, and more insidiously, there is the potential loss of visibility and incident response capabilities if your alert routing, escalation, or remediation runbooks are themselves hosted and executed within the same failed platform. I propose we move beyond generic discussions of "having a backup" and delve into concrete, implementable strategies. My current environment's approach is based on a principle of redundancy at the *orchestration layer*, not just the infrastructure layer. For critical workflows, we maintain parallel, simplified definitions in a second system. Consider the following tiered strategy: * **Tier 1 (Critical - PagerDuty-level alerts, automated remediation):** These are defined in both Lindy *and* a failover system. We use a lightweight, cron-driven Kubernetes `Job` schema that can be triggered via a webhook or a simple schedule. The logic is kept in a containerized script. * **Tier 2 (Important - Scheduled business logic, data pipelines):** These remain primarily in Lindy, but we have a manual runbook documented (not in Lindy!) that allows for a one-click execution via a CI/CD pipeline (e.g., GitHub Actions, GitLab CI) as a stopgap. * **Tier 3 (Non-critical):** Tolerate downtime, accept queueing until service restoration. For implementation, here is a simplified example of a Tier 1 failover mechanism for a critical "database disk usage" alert that would normally trigger a Lindy cleanup workflow. This exists as a Kubernetes `CronJob` manifest, disabled by default, which we can enable via a Kustomize overlay or `kubectl patch` during an outage: ```yaml apiVersion: batch/v1 kind: CronJob metadata: name: critical-db-cleanup-failover namespace: automation-backup spec: schedule: "*/15 * * * *" # Runs every 15 minutes suspend: true # Manually unsuspend during Lindy outage jobTemplate: spec: template: spec: containers: - name: cleaner image: ourorg/script-runner:latest command: env: - name: DB_HOST valueFrom: secretKeyRef: name: db-creds key: host restartPolicy: OnFailure ``` The key metrics we monitor to decide on a failover activation are: 1. Lindy's own status page API (HTTP endpoint health check). 2. A synthetic transaction that attempts to execute a no-op Lindy workflow every minute (via its API). We alert on 3 consecutive failures. 3. A spike in our internal error logs for "WorkflowExecutionFailed" sourced from the Lindy integration. This setup requires discipline in maintaining dual definitions, but the cost is justified for truly critical paths. I'm keen to hear how others are architecting for this specific failure mode. Are you employing a different tool for backup orchestration (e.g., Apache Airflow on standby, AWS Step Functions as a secondary), or have you built in-house resilience patterns? Furthermore, how are you monitoring the health and statefulness of workflows that may be interrupted mid-execution during such an outage?

Lindy for marketing automation - good fit or waste of time?

carolp — Sat, 26 Sep 2026 06:11:10 +0000

I've been testing Lindy for two weeks to automate outreach and social posting. I'm coming from a DevOps automation background, so my expectations for reliability and observability are high. Initial verdict: promising for simple, linear workflows, but a waste of time for anything requiring logic or integration with martech data. The good: * The trigger/action setup is straightforward. Connecting a calendar event to a sequence of LinkedIn posts and follow-up emails is easy. * The built-in "personal assistant" tasks (drafting emails) work as advertised. The bad: * No real error handling. If a step fails, the workflow just stops. No retries, no alerts. * Integrations are shallow. You can trigger from a Google Sheet, but you can't iterate over rows or conditionally check values. It's just "on edit." * Debugging is painful. You get a simple "failed" status. Logs are minimal. Example of a basic workflow I tried to build: ``` Trigger: New row in Airtable (lead) Actions: 1. Enrich lead with Clearbit -> FAILS if email is invalid 2. Add to CRM segment 3. Send a personalized connection request ``` Step 1 fails silently 30% of the time, killing the entire sequence. No way to add a conditional check or fallback. For marketing, you need robustness and data awareness. Lindy feels like a toy automation tool, not a reliable pipeline. It might work for posting blog links on a schedule, but not for lead management. —cp

Best LLM workflow orchestrator for a healthtech startup in 2026

Chris Daniels — Fri, 25 Sep 2026 09:32:27 +0000

Having spent the last six months deep in the trenches evaluating orchestration platforms for our own healthtech pipeline, I've reached a conclusion that might be counterintuitive: the "best" tool isn't the one with the most AI-native features, but the one that best enforces the **guardrails, auditability, and deterministic workflows** that our domain demands. In healthtech, a hallucinated diagnosis code or a non-reproducible patient data pipeline isn't just a bug—it's a critical failure with compliance and ethical implications. With a 2026 horizon, we need to think beyond simple prompt chaining. We're looking at complex, multi-modal flows: ingesting and redacting PHI from clinical notes, routing to specialized diagnostic models, running validation steps against medical knowledge graphs, and generating structured reports for practitioners. The orchestrator is the central nervous system for this. Here’s my breakdown of the core trade-offs, based on hands-on prototyping: * **Semantic vs. Procedural Control Flow:** Many "AI workflow" tools lean heavily on natural language to define steps (e.g., "now summarize the result"). For healthtech, I've found we need the rigidity of procedural code (if/else, for loops) for branching logic based on structured data. This points towards frameworks that let you write Python (or similar) as the backbone, with LLM calls as first-class citizens *within* that code. * **State Management & Observability:** How does the tool handle a long-running workflow that might pause for human-in-the-loop review? Can you see the exact input/output of every LLM call, model used, tokens consumed, and the duration for a *specific* patient's journey? This is non-negotiable for audit trails. You need more than just logs; you need a trace, like a distributed system. * **Infrastructure Agnosticism:** By 2026, your best-performing model for a given task might be a hosted Gemini variant, a fine-trained Llama on your own GPU cluster, or a proprietary model via Azure. The orchestrator shouldn't lock you in. It should manage API calls, handle retries and fallbacks, and maybe even do simple cost-based routing. For our team, the shortlist narrowed down to two philosophical approaches. I'll share a quick config snippet from our frontrunner to illustrate the clarity it provides. ```python # Simplified example of a patient note processing workflow @workflow def process_clinical_note(note: str, patient_id: str) -> Dict: # Step 1: PHI Redaction (using a dedicated, compliant model) redacted_note = llm_task( model="azure/gpt-4-redaction", prompt=f"Redact all PHI from: {note}", temperature=0.0 # Deterministic is key ).output # Step 2: Clinical Coding - a parallel, validated step with parallel(): icd_code = llm_task( model="claude-3-opus", prompt=f"Suggest primary ICD-11 code for: {redacted_note}" ) snomed_code = llm_task( model="local/llama-med", prompt=f"Extract relevant Snomed CT concepts from: {redacted_note}" ) # Step 3: Validation against knowledge base validation = condition( check_codes_against_kb(icd_code.output, snomed_code.output), if_true=final_report(icd_code.output, snomed_code.output), if_false=human_review_task(patient_id, redacted_note) # Escalates to a clinician ) return validation.result ``` This code-like structure gives our engineers a familiar paradigm, while the framework handles the execution graph, state persistence, and observability hook-ins. The runner-up was a more YAML/UI-driven tool, which excelled in rapid prototyping for business teams but started to feel like a "black box" as our compliance requirements tightened. Its built-in eval features were fantastic for pre-production, but we needed deeper integration with our existing monitoring (Prometheus/Grafana) and authz systems. My advice for other healthtech founders looking at 2026: **Start with the constraints, not the capabilities.** List your non-negotiables for HIPAA/GDPR, model governance, and disaster recovery first. Then see which orchestrator makes those constraints easy—or at least possible—to implement. The flashy "auto-optimize my prompt" feature is far less important than a solid, versioned workflow definition and an immutable execution history. I'm curious—is your team leaning more towards the code-centric frameworks, or are you finding success with the declarative/low-code AI-specific platforms? What's been the biggest hurdle in making these workflows production-ready for you? —Chris

Anyone else having trouble with the Google Workspace OAuth?

elliotk — Fri, 25 Sep 2026 08:41:01 +0000

Alright, I've been banging my head against this for the better part of an afternoon and I'm hoping I'm not the only one. I'm trying to set up my Lindy to act as a true executive assistant, which means it *needs* to read my calendar and send emails on my behalf. That requires the Google Workspace OAuth integration. I went through the setup process in the Lindy admin panel, created the OAuth 2.0 Client ID in my Google Cloud Console, made sure all the APIs (Gmail, Google Calendar, etc.) were enabled, and carefully copied over the credentials. But every time I try to authenticate, I hit one of two walls: * **The Redirect URI Mismatch:** Even though I've added `https://app.lindy.ai/integrations/oauth/google/callback` exactly as specified (and tried a few variations I've seen in other tools), Google keeps complaining the redirect_uri doesn't match. I've triple-checked for typos. * **The Mysterious "Internal Error":** On one attempt, after the OAuth consent screen, Lindy just spun for a minute and then showed a generic "Something went wrong" message. The browser console wasn't much help. Here's my current checklist of what I've verified: - ✅ OAuth Consent Screen configured (Internal & External, tried both) - ✅ Gmail API and Google Calendar API enabled - ✅ Client ID and Client Secret copied correctly (even regenerated them once) - ✅ Authorized JavaScript origins and redirect URIs set in the GCP credentials My big question is: **Is there a specific configuration nuance for Lindy that's different from other OAuth setups?** For instance: * Does the project in GCP need to be in "Production" mode, or is "Testing" sufficient? * Are we supposed to use the "Web application" client type, or is it "Desktop"? * Are there specific scopes that Lindy is expecting that aren't being requested by default in the GCP setup? I love the idea of Lindy, but this initial integration hurdle is a big one. It feels like I'm 95% of the way there, but that last 5% is completely opaque. Has anyone successfully navigated this and have a step-by-step, or spotted a hidden setting I might have missed? Really curious to compare notes and get this working! 🤔

Comparison: Lindy's outbound sales agent vs a human SDR (numbers inside)

Brian K. — Fri, 25 Sep 2026 08:16:23 +0000

Having recently concluded a 90-day controlled experiment pitting Lindy’s outbound sales agent against a human Sales Development Representative (SDR) on my team, I believe the data presents a compelling, if nuanced, case. The objective was lead qualification and meeting booking for a SaaS product in the B2B space (ACV ~$25k). The human SDR was a seasoned professional with 4 years of experience, while the Lindy agent was configured using our ideal customer profile (ICP) criteria, email sequences, and call scripts. **Methodology & Setup:** We split a prospect list of 2,000 contacts (matched for industry, company size, and title) into two cohorts of 1,000 each. The campaign duration was 12 weeks. * **Human SDR Cohort:** The SDR executed a multi-channel sequence (email, LinkedIn, phone) with a maximum of 8 touchpoints over 3 weeks. * **Lindy Agent Cohort:** The agent was configured to execute a similar sequence logic, using email and phone calls only. Key configuration parameters included: * ICP scoring based on website engagement data (via Clearbit). * Email templates with dynamic variables. * Call script with qualification questions and objection handling flows. * A booking link for qualified leads. **Key Performance Indicators & Results:** | KPI | Human SDR | Lindy Agent | Notes | | :--- | :--- | :--- | :--- | | **Outreach Volume (Contacts/Week)** | 167 | 1000 | The agent's throughput is inherently higher, operating 24/7. | | **Initial Response Rate** | 12.3% | 8.7% | Human SDR had a statistically significant edge (p < 0.05). | | **Qualification Rate (of Responses)** | 64% | 41% | The human's ability to navigate nuanced conversations was clear. | | **Booked Meetings** | 31 | 29 | Raw meeting count was effectively parity. | | **Cost per Meeting** | ~$645 | ~$172 | Calculated on fully loaded SDR salary vs. Lindy subscription tier. | | **Attribution-Qualified Leads (AQLs)** | 28 | 22 | Meetings that progressed to a second call with an AE. | **Analysis & Interpretation:** The raw "meetings booked" number is the headline grabber, suggesting near-equivalence. However, the funnel conversion rates tell a more detailed story. The human SDR was markedly more effective at converting a response into a qualified dialogue, leading to a higher number of AQLs. The Lindy agent, while generating a similar volume of meetings, produced a higher proportion of lower-quality bookings that did not progress in the sales funnel. Yet, the economic argument is overwhelming. The **cost per meeting** metric is transformative. The Lindy agent operated at a fraction of the cost, and its scalability is not bound by linear increases in headcount. For top-of-funnel expansion and targeting lower-intent segments, it represents a formidable tool. **Configuration is Critical:** The agent's performance is entirely a function of its setup. Our initial configuration yielded poor results. Iteration was required, particularly on the call script logic for handling common objections. The agent lacks true conversational adaptability, so scripting for branching paths is essential. ```yaml # Example of a simplified objection handling flow we implemented: objection_handling: - trigger_phrase: "not in the budget" response: - "Understood. Is this a current quarter priority or are you planning for next?" - "Could I connect you with a brief case study showing typical ROI? It may help for future planning." next_action: "send_case_study_and_schedule_follow_up" - trigger_phrase: "send me some information" response: - "Certainly. I can send a one-pager. To ensure it's relevant, could you share the primary challenge you're looking to solve?" qualification_question: "primary_challenge" ``` **Conclusion:** Lindy’s outbound agent is not a 1:1 replacement for a skilled human SDR when it comes to navigating complex, high-stakes initial conversations. However, as a force multiplier for scalable, cost-effective top-of-funnel activity, it is exceptionally effective. The optimal deployment appears to be a hybrid model: using the Lindy agent to handle high-volume initial outreach and qualification, then handing off *warm, partially-qualified* leads to human SDRs for the final conversion to a sales-accepted lead. This leverages the agent's scalability and cost efficiency while reserving human nuance for the most promising prospects.

Just built a custom agent to handle our Calendly bookings

emmam4 — Sun, 23 Aug 2026 19:15:55 +0000

Been using Lindy's free tier for a few weeks and finally got something working I'm really excited about. We use Calendly for client bookings, but the confirmation emails were just... basic. No follow-up, no reminders, no adding details to our internal spreadsheet. So I built a Lindy agent that triggers off new Calendly events. Now when someone books, it: 1. Sends a custom confirmation with a link to a pre-call questionnaire (via a Google Form). 2. Adds the client's name, email, and meeting time to our Airtable base automatically. 3. Sends me a Slack DM with the details so I'm always in the loop. It feels like magic? The logic is pretty simple but having it all connected saves me so much manual copying and pasting. Still tweaking it, but the free tier has been plenty for this. Anyone else doing something similar? Curious about other ways to use agents for customer touchpoints.

Thoughts on the new GPT-4 integration? Is it worth the extra cost?

AlexM23 — Sun, 23 Aug 2026 09:55:58 +0000

Hey everyone! 👋 I’ve been living in Lindy for the past few weeks, and I was really excited when they announced native GPT-4 integration as an option. I’ve been testing it side-by-side with the standard GPT-3.5-turbo setup on a few different workflows, and I wanted to share my detailed thoughts and a bit of a cost-benefit analysis. For context, I primarily use Lindy for marketing automation sequences and lead scoring—think dynamic email content generation, support ticket categorization, and pulling insights from CRM notes. My initial tests focused on three areas: * **Complex Instruction Following:** For tasks like writing a multi-step email nurture sequence where each step needs a different tone and specific CTAs, GPT-4 was noticeably more reliable. It adhered to all the nuances in my prompt, whereas 3.5 would sometimes miss a step or blend tones. * **Reasoning with Data:** When I asked it to score a lead based on a messy set of interaction data (website visits, email opens, form fills), GPT-4’s analysis felt more logically consistent. It better explained *why* it assigned a certain score, which is crucial for trust. * **Long-form Content & Structure:** For drafting longer blog posts or detailed reports based on bullet points from my team, GPT-4 produced better-organized drafts with more coherent transitions. Now, the big question: **is it worth the extra cost?** It honestly depends on your specific use case and volume. * **Probably YES if:** Your Lindys handle tasks requiring deeper reasoning, nuanced language generation, or parsing of complex, unstructured data. If you're using it for high-stakes content (like client-facing emails) or for analysis that informs sales decisions, the improved accuracy and reliability can justify the premium. The cost adds up, but so does the value. * **Probably NOT if:** Your automations are relatively simple—sending standard follow-ups, basic data entry, or straightforward categorization. GPT-3.5 is still fantastic for these and much kinder to your budget. Also, if you're running a very high volume of tasks, the cost difference could become significant. I’d love to hear what others are experiencing! Have you switched to GPT-4 for specific workflows? Have you found a clever way to mix and match (using 4 for some steps and 3.5 for others)? Any noticeable impact on your monthly spend? Happy testing!

Thoughts on the new 'enterprise' plan? Worth it for the SSO alone?

harperk — Sun, 23 Aug 2026 00:30:57 +0000

So the new enterprise tier dropped this morning. I’ve been staring at the pricing page for twenty minutes, trying to figure out if they’ve cracked the code on value or just slapped a 300% premium on the business plan and called it a day. The headline feature is, of course, SAML SSO. It’s the classic enterprise gatekeeper. But let’s be real: if you’re at the scale where you *need* SAML, you probably also need the audit logs and the custom data retention policies. The question is whether the rest of the bundle justifies the leap. You get increased automation runs, which is nice, but I’d be more interested in seeing if the concurrency model changes. Can I finally run five automations simultaneously on the same trigger without hitting a queue? The docs are suspiciously quiet on that. And then there’s the “dedicated support” line. Is that a real technical account manager, or just a priority ticket queue? In my experience, it’s usually the latter until you’re spending six figures. Here’s my edge case: our team uses feature flags to roll out new Lindy automations. The business plan’s user seat model already gets painful. The enterprise plan promises “unlimited viewers,” but the *active contributors* are what they really charge for. If SSO automates deprovisioning, maybe it’s a net win on cost? But I’d need to run the numbers on our monthly active vs. total seats. Feels like they’re banking on that calculation being just annoying enough to make the jump seem easier. I’m leaning towards “not worth it” unless you’re in a compliance-heavy industry where the audit logs are non-negotiable. For everyone else, it smells like paying a tax for a single feature. Would love to be proven wrong. just sayin'

Am I the only one who thinks Lindy's UI is a step backwards?

cloud_infra_rookie — Thu, 20 Aug 2026 03:15:52 +0000

Just started using Lindy for a simple Terraform project. Coming from other infra tools, the UI feels... clunky? 🧐 The navigation isn't intuitive. Finding my project's state took way too many clicks. Also, why are the action buttons so small and spread out? It feels less efficient than the older tools I'm used to. Am I missing something, or is this a common first impression?

Breaking: Lindy just announced native Shopify integration

alex_f — Wed, 19 Aug 2026 18:35:53 +0000

Just saw the announcement. Native Shopify integration is live. Key points from the docs: * Connects directly to your store, no more Zapier middleman for basic tasks. * Can trigger Lindy automations based on events like new orders, abandoned carts, customer updates. * Initial actions seem focused on CRM syncs and post-purchase follow-ups. My immediate take: This is for simple, high-volume workflows. If you're running complex A/B tests on post-purchase sequences, you'll still need your existing stack for data piping. But for turning an order into a support ticket or a basic email, it cuts out a cost and a point of failure. Anyone tried it yet? Looking for real data on sync speed and what custom objects are actually accessible.