Since day one, our mission at Mergent has been to provide the most reliable infrastructure for background jobs. We’ve focused relentlessly on uptime and simplicity, making sure developers could trust that their jobs would run without surprises.

Over the past three years, Mergent has consistently delivered industry-leading reliability, with over 99.995% uptime.

We’ve been fortunate to power critical workflows for teams that value reliable infrastructure that just works. Now, we’re taking the next step by joining Resend.

Resend is redefining how developers send and manage email — fast, reliable, and developer-first. Together, we’ll combine our strengths to create a more robust platform for communication at scale.

What does this mean for Mergent users and customers?

Mergent’s service will wind down over the next 90 days, ending July 28th, 2025. We’ll continue to ensure stability during the transition, and we’re here to help you migrate smoothly.

We recommend existing Mergent users migrate to Resend for email scheduling use cases, and Inngest for other background job and queueing use cases. Inngest has built a reliable platform for background jobs and workflows, and has published a guide for Mergent users to migrate to Inngest.

If you have questions, or need help with the migration, please reach out to support@mergent.co — we’re here to support you through this process.

Thank you

To every developer who trusted Mergent with their workloads: thank you. It’s been an honor to serve you.

We’re incredibly proud of what we’ve built, and we’re even more excited for what comes next.

— The Mergent Team

Automatic Discounts as You Scale

Our new dynamic pricing model automatically lowers your costs as your usage increases. This enables all of our customers to benefit from economies of scale without having to get on a call to negotiate new pricing.

Brand-New Transparent Pricing

Our plans are now more straightforward with a clear breakdown:

• Free Plan: Up to 1,000 invocations per month at no cost.

• Standard Plan: Pay-per-use with automatic discounts based on usage, as low as $0.000003 per invocation.

• Enterprise Plan: Custom pricing with dedicated support.

Effective Date and Retroactive Application

The new pricing went into effect on June 6 and retroactively applies to your next invoice. For example, if your subscription is set to renew on June 15, the entire invoice from May 15 to June 15 will be recalculated under the new pricing model, ensuring you benefit from the changes immediately.

Learn More

We've published a new pricing documentation page with a usage-based pricing table, pricing examples, and an FAQ.

If you have any questions or feedback, please send us a message at hello@mergent.co. We're always looking to improve our documentation, and questions from customers is the best way for us to know how we can improve our docs.

We're happy this new method of pricing benefits every single one of our growing family of customers. We invite you to try Mergent for yourself for free!

Task Rate Limits are implemented to help avoid overloading applications with an excessive number of tasks simultaneously. By leveraging a sliding log algorithm, Mergent accurately maintains the dispatch rate within the defined limits across any given time window.

Rate limits can be adjusted anytime via the Mergent Dashboard, enabling developers to dynamically manage application throughput based on current performance and workload expectations.

Default Configuration: The default rate limit is set to 500 tasks per second per project.

This feature is available in beta today, and we'll be collecting feedback and data for further improvements. Let us know what you think.

Head over to the task rate limits docs to learn more.

What's New?

1. Easier Access: We've integrated the API reference into our main documentation to make it easier to find.

2. Richer Examples: Our examples are more comprehensive, practical, and tailored to real-world scenarios that we see often (e.g., Authorization).

3. In-depth Field Details: Expect clearer explanations of required fields, nullable types, default values, and more.

4. Better Descriptions: Every endpoint has been revisited for clarity.

If you spot anything amiss or have any suggestions, please don't hesitate to reach out.

Details of the deal are available in Bookface. Ready to get started? Email us at yc@mergent.co.

All personal accounts and organizations have been consolidated into the new Mergent teams. Project billing and team member management have also been migrated to teams.

Team members are free to add to any team, even teams on our free plan. So go forth and collaborate!✨

We'll be using the changelog to post the changes to the Mergent platform, including our dashboard, API, SDKs, and more.

We'll also be posting changes on X @mergentlabs, so be sure to follow us there, too.

The Journey to Reliable Uptime

• Focus on API Stability: Understanding the critical role our APIs play in your applications, we've put in a ton of effort to ensure they are robust and resilient.

• Advanced Monitoring Tooling: We've set up sophisticated monitoring systems that alert us instantly to any performance dips and help us predict disruptions before they happen. This means we can often resolve issues before they impact our customers.

• Continuous Infrastructure Enhancements: Our infrastructure isn't static. We're continually upgrading our underlying infrastructure to handle increasing loads while keeping our APIs up and available.

Why This Level of Uptime Matters

• Seamless User Experience: High API uptime translates to a smooth, uninterrupted experience for your users. Your applications depend on our APIs for various functionalities, and our uptime ensures these functions are always available.

• Supporting Your Growth: As your business grows, our infrastructure scales with you. The reliability of our services means you can focus on expanding your business, without worrying about backend stability.

• Trust in Service Continuity: Even a minute of downtime can be costly. Our track record of high uptime gives you the confidence to build and scale your applications, knowing that our APIs are a reliable foundation.

Behind the Scenes: How We Maintain High Uptime

Achieving and maintaining over 99.995% uptime involves a combination of technology, processes, and people.

1. Robust Technology Stack: At the core of our high uptime is a robust technology stack, designed for resilience and scalability.

2. Team Focused on Reliability: Our team is passionate about delivering reliable services, working around the clock to monitor, update, and improve our APIs.

3. Proactive Problem-Solving Approach: We don't wait for issues to arise. Instead, we proactively address potential issues before they arise, ensuring that our services remain uninterrupted.

Our Commitment to You

This achievement is more than just maintaining uptime; it's about our commitment to providing you with APIs you can depend on.

• A Partnership Approach: We see our relationship with clients as a partnership. Your success is our success, and our API uptime is a critical part of that.

• API Enhancements: As we celebrate this milestone, we’re also looking ahead. We're constantly exploring innovative ways to enhance our APIs.

• Community and Customer Feedback: Customer feedback drives us. We actively engage with our customers to understand their needs and experience. This feedback is crucial in guiding our improvements.

What’s Next for Mergent

Looking forward, we have a lot coming.

• Enhancing Developer Experience: We’re focused on making Mergent even more developer-friendly, with easier integration, improved debugging, and more intuitive features.

• Expanding Our Offerings: We’re planning to roll out more features, giving you more tools to build amazing applications.

• Strengthening Security and Compliance: We’re doubling down on our efforts to ensure our APIs are not just reliable but also secure and compliant with standards like SOC 2 and ISO 27001.

Conclusion

We’re proud of what we’ve achieved, but we’re even more excited about what this means for you. Our commitment to reliability, innovation, and partnership remains stronger than ever. Thank you for trusting Mergent. We’re looking forward to another year of delivering excellence and supporting your growth.

In this blog post, we'll explore the pros and cons of building vs. buying software infrastructure to help you decide which option would be best for your situation, along with a list you can use to calculate your software's total cost of ownership (TCO) and an example using Apache Kafka.

The real meat of this post is in the TCO calculation, so if that's what you're here for, feel free to skip the following two sections.

Building - Pros and Cons

Building software infrastructure from scratch can be an excellent option for teams with unique or specialized needs that off-the-shelf solutions cannot meet. By building your own software, you can tailor it precisely to your needs, ensuring that it does exactly what is needed and integrates seamlessly with existing systems.

Additionally, building gives you complete control over the development process and allows you to make changes and updates quickly and easily.

However, building software infrastructure from scratch also has its downsides. One of the biggest cons is cost. Developing software from scratch can be a time-consuming and expensive process. Building your own software also has a higher risk of bugs and security vulnerabilities.

Before we dive into calculating costs, let's discuss the alternative: buying.

Buying - Pros and Cons

Buying software infrastructure off-the-shelf can be an excellent option for teams that want a proven solution that has been tested and validated by other organizations. Off-the-shelf software is generally less expensive and less time-consuming to implement than building your own software from scratch. Additionally, buying software from a vendor can provide access to technical support and updates, which can be essential for ensuring the ongoing security and performance of the software.

However, like building, buying software infrastructure off-the-shelf also has its downsides. One of the biggest cons is that off-the-shelf software may not be tailored to your specific needs and may require additional customization to work effectively. Additionally, buying software off-the-shelf limits your control over the development process and makes it more challenging to make changes and updates to the software.

Total Cost of Ownership (TCO)

Whether building or buying, the TCO of software is often miscalculated or even overlooked entirely. We've put together a short "checklist" you can use to calculate the total cost of ownership.

When calculating the TCO, be sure you calculate the cost for each team involved (e.g., if you have separate infrastructure and development teams, consider the TCO for both independently).

Up-front costs

• software cost & licensing, if applicable

• learning & education

• implementation & testing (including data migration costs)

• documentation & knowledge sharing

• customization

Ongoing costs

• direct infrastructure costs (e.g., hosting & storage)

• backup infrastructure costs (e.g., failover & additional AZs)

• supporting infrastructure costs (e.g., monitoring & alerting)

• maintenance, patches/upgrades, & support

• feature additions

Team & opportunity costs

• hiring to replace the engineers now working with the new software

• time spent on infrastructure that could otherwise be spent on core product

TCO Example: Apache Kafka

Using a simplified version of the above list, let's dig into an example with Apache Kafka, a popular open-source distributed streaming platform many companies use to build data pipelines and send data between services.

To remain unbiased, we'll compare it to Heroku's Apache Kafka as a service Standard plan. This means we are looking for the following specs:

• Capacity: 300GB

• Retention: 2 weeks

• vCPU: 4

• Ram: 16GB

• Brokers: 3 Kafka, 5 Zookeeper

In this example, we assume both the infrastructure engineer and the software engineer have all-in costs of $200k/yr, or $3,846/mo (note: $200k is very low in the United States when including benefits, shares, bonuses, & perks)

Yes, you're reading that right: buying your Kafka cluster from Heroku is cheaper than building with AWS.

Conclusion

When it comes to software infrastructure, teams have the option of building it from scratch or buying it off the shelf. Both options have their own set of pros and cons, and the decision ultimately comes down to the specific needs and goals of the organization.

Teams should carefully consider their specific needs and goals, as well as the cost and resources required for each option. While building software infrastructure can be a good choice for teams with unique or specialized needs, buying off-the-shelf software can be a more cost-effective and low-risk option for organizations that want a proven and supported solution.

One common use case for message queueing is background jobs. These are tasks that need to be run periodically or asynchronously, such as sending email notifications or generating reports. By using a message queue, organizations can offload these tasks from their main application, improving performance and scalability.

While SQS has long been a popular choice for background jobs, we are proud to announce that Mergent has outperformed SQS in terms of uptime in 2022. Over the past year, we achieved an impressive 99.997% uptime, beating SQS's SLA of 99.9% uptime.

This may not seem like a significant difference at first glance, but it can have a major impact on the reliability and availability of systems that rely on message queueing for background jobs; a 0.1% difference can translate to almost an entire day of downtime over the course of a year. And when it comes to background jobs, even a few minutes of downtime can have serious consequences, such as missed notifications or incomplete reports.

But it's not just about uptime. Mergent also offers a number of other benefits that make it a strong competitor to SQS for background jobs. We offer a range of advanced features, such as message scheduling, 30-day task history retention periods, and delivery delays. This makes it easy for organizations to fine-tune their background jobs to fit their specific needs.

In addition, we offer a range of pricing options to fit the needs of any organization, with flexible pay-as-you-go pricing starting at $20/mo and volume discounts available. This makes it easy for teams of all sizes to get the background job capabilities they need without breaking the bank.

But perhaps most importantly, Mergent is designed with ease of use in mind. We understand that background jobs and cron tasks are just one part of a larger system, and we strive to make our service as simple and straightforward as possible. Our intuitive APIs and clear documentation make it easy for developers to get up and running quickly, so they can focus on building great products and features for their users.

Ultimately, Mergent is designed to provide reliable, scalable, and feature-rich task queuing for any organization. We are proud to have consistently outperformed SQS in terms of uptime, and we are committed to continuing to deliver the highest level of service to our customers. If you're looking for a serverless task queue, we encourage you to give Mergent a try. We think you'll be impressed by what we have to offer.

There are a few notable changes to the API between V1 and V2.

As always, feel free to visit our docs or API reference directly. We're also available at support@mergent.co to answer any questions.

There are new library versions.

If you're using one of the official Mergent libraries, update to the most recent version to use the new V2 API.

The API prefix is now /v2 instead of /v1.

If you're using the API directly, change the API prefix to /v2. API endpoints prefixed with /v1 will become inaccessible on May 31st, 2022.

The rate limit has been changed to 500 requests per second.

This is a soft limit, and with increases per project available by emailing support@mergent.co. We plan on continuing to increase the rate limit over time.

All resources now require a queue attribute when being created.

By default, the Mergent libraries will set this to default. Soon, we will be providing another update with ways to control Tasks within a queue. Stay tuned.

All resources now return an id attribute upon creation.

Previously, Mergent's APIs used an optional name as a primary identifier. Now, Mergent returns an id attribute. Please use this for Task/Schedule identification.

Tasks no longer have a description attribute.

This was a holdover from before Mergent Schedules were separated from Mergent Tasks several months ago. Schedules continue to have a description attribute.

name is now strictly used for the deduplication of queued and working tasks.

Before, Mergent used name both as a deduplication key and primary identifier for all resources. Due to the way deduplication was handled behind the scenes, names could not be reused once a Task was completed.

With this change, name only deduplicates tasks that are either queued or working.

Want to Learn More?

Check out our docs, our new API reference, or send us a note at support@mergent.co. We're here to help!