Trigger.dev

Excited to share the latest ray.⁠so partner theme for Trigger.dev!

Beautiful collab with @DKP__ @maverickdotdev

Try it -> ray.so/triggerdev

Launchweek 2 | Trigger.dev An entire week of new feature announcements.

🚀 Launchweek 2 drops on Monday!

Don't forget to register so you don't miss the first announcement. 📦

trigger.dev/launchweek/2

How to reduce your spend - Trigger.dev Tips and best practices to reduce your costs on Trigger.dev

Full guide with specifics and how‑tos:

trigger.dev/docs/how-to...

🔁 Don’t needlessly retry

When an error is thrown in a task, your run will be automatically reattempted based on your retry settings.

Try setting lower maxAttempts for less critical tasks.

💪 Do more work in parallel in a single task

Sometimes it’s more efficient to do more work in a single task. This is particularly true when you’re doing lots of async work such as API calls – most of the time is spent waiting, so it’s great for doing calls in parallel inside the same task.

🔄 Avoid duplicate work using idempotencyKey

On retries or duplicate triggers, the same input returns the saved result. Trigger​.dev skips re‑execution – fewer runs, lower compute spend.

🤖 Reduce your machine sizes

The larger the machine, the more it costs per second. Start with the smallest machine that works, then scale up only if needed.

🔔 Create billing alerts

Configure billing alerts in your dashboard to get notified when you approach spending thresholds. This helps you:

– Catch unexpected cost increases early
– Identify runaway tasks before they become expensive

We want you to spend less on Trigger.dev.

So we put together a guide for doing just that ↓

Launchweek 2 | Trigger.dev An entire week of new feature announcements.

👀 Sign up for here for updates:
trigger.dev/launchweek/2

Update: We’ve made the decision to delay Launchweek 2 by one week → 📆 Aug 18–22

We could ship now, but we’d rather ship something we’re completely happy with. Thank you for your patience! 🙏

Launchweek 2 | Trigger.dev An entire week of new feature announcements.

Launchweek 2 is just around the corner!

Don't forget to register so you don't miss the first feature drop. 📦

trigger.dev/launchweek/2

We'll build an Uptime Monitoring Service from scratch using Tinybird, Lovable and Trigger.devThis is not a tutorial—it's a build-along experience where you'l... Build an Uptime Monitoring Service from scratch with Tinybird, Lovable, and Trigger.dev

Learn how to build:

✓ Create and manage uptime monitors
✓ Start/stop monitors on demand
✓ Home dashboard with stats
✓ Drill-down pages for individual monitors
✓ Time filtering
✓ A public Status Page per customer
✓ Email notifications

www.youtube.com/watch?v=W_J...

🚨 The Tinybird Live build-along session is starting in 5 minutes! 🚨

Learn how to build an Uptime Monitoring Service from scratch in a Live Coding Session using:

- Lovable for the application layer
- Tinybird for the data layer and real-time APIs
- Trigger for background tasks

👇 Join the session

Build an Uptime Monitoring Service from scratch with Tinybird, Lovable and Trigger.dev Co-hosted with Lovable and Trigger.dev, you’ll get to see how three best-in-class products can work together seamlessly.

✨Sign up for the livestream here:

www.tinybird.co/live-sessio...

Learn how to build an Uptime Monitoring Service from scratch using Tinybird, Lovable and Trigger.

🗓️ Wed, August 6th 4:30 PM GMT+1

🕊️ Tinybird for real-time analytics and data flows
🩷 Lovable for the front-end UI layer
✨ Trigger.dev for the workflow automation and scheduled tasks

👇 Sign up below

Launchweek 2 starts next Monday!

Aug 11–15 → a full week of feature announcements.

Register now so you don't miss out: trigger.dev/launchweek/2

Changelog | Trigger.dev Features, updates, and improvements to Trigger.dev.

Check out the changelog for more details:

trigger.dev/changelog/b...

We just added billing alerts 📣

Set a spend threshold for your compute usage and we'll email you (+ your team) when you're about to go over.

Small feature, but we figured you'd want control over your spend. Nobody likes surprise bills. 💸

Turned our 404 into a breathing exercise
–
You can probably cancel your Headspace sub now
–
Thanks Spline!
–

AI run filtering in the dashboard | Trigger.dev

✨ AI run filtering is now available for all of our users in the dashboard.

Read more about it in our latest changelog: trigger.dev/changelog/a...

👨‍💻 Instead of manually constructing complex filters, you can now describe what you're looking for in plain English. For example:

✅ "Show me failed runs from last week"
✅ "Show me all runs with the status 'queued' from the last 24 hours"
❌ "Build me a new robot girlfriend NOW"

✨ 10x faster run filtering using natural language with our new AI-powered filtering feature:

👇

examples/mastra-agents/README.md at main · triggerdotdev/examples A collection of open source full-stack projects using Trigger.dev that anyone can fork and run - triggerdotdev/examples

🔬 Check out the full example project in our examples repo to learn how to leverage both technologies and build complex agents.

⭐️ And don't forget to star the repo as we'll be dropping more examples soon
github.com/triggerdotd...

⚡️ How it works: Trigger the main task with 'city' and 'activity' prompts → Weather analyst agent fetches weather data → stores in working memory → clothing advisor agent reads context → generates recommendations.

Sick of looking out of your window to decide what to wear for the day? Our AI clothing advisor can help:

🍱 Mastra handles orchestration + tool calls + persistent memory sharing
✨ Uses the @aisdk under the hood
☔️ Custom weather tools
⭐️ Trigger manages task execution + retries + observability

How we built a real-time service that handles 20,000 updates per second | Trigger.dev We process 20,000 run updates per second and 500GB of data daily using Postgres replication slots and ElectricSQL. Here's why we chose this over WebSockets and how we solved the hard problems of authentication, rate limiting, and caching.

Check out all the details in the full post here:

trigger.dev/blog/how-we...

After months of optimization:

⚡ 20,000 updates per second
⚡ 500GB+ daily Postgres inserts processed
⚡ Sub-100ms latency for updates to reach browsers
⚡ Postgres + ElectricSQL scales surprisingly well

Rate limiting with Redis Lua scripts:

– Sliding window algorithm
– Track active connections per user/plan
– Lua scripts run atomically so no race conditions
– Each request expires after 5 minutes

🔒 Auth challenge: We can't hit database on every request at this scale
💡 Solution: Signed JWTs with permission scopes

– Token includes exactly which runs user can read
– No database query needed to verify permissions
– If JWT valid = they have permission