A New Approach to Errors

When your app is crashed, out of resources, or misbehaving in some other way, Heroku serves error pages to describe the problem. We also have a single page for platform errors, once known as the ouchie guy (pictured right).

While the approach of showing error information directly via the web has worked well enough, there was room for improvement on both developer visibility and professionalism of presentation to end users. With that in mind, we’ve reworked our approach on error handling, making improvements that should make it much easier for you, the developer, to diagnose and correct errors in your app.

This new approach can be broken down into four features:

  1. Consolidated error page
  2. Logging of error codes
  3. Custom Error Pages add-on
  4. Improved maintenance mode

These items are now available in public beta, activated by installing the Custom Error Pages add-on. Once the public beta period is over, items 1, 2, and 4 will become the default for all apps.

Let’s take a tour of this new world of error handling.

Consolidated Error Page

An error being served in a high-traffic app is more likely to be served to an end user than to the application developer; so showing information like “backlog too deep” or “request timed out” is useless and potentially confusing to the viewer. All error pages served over HTTP are now represented by a consolidated error page, and always serve with an HTTP status code of 503.

Logging of Error Codes

Because we’re no longer putting details of the error into the page served via HTTP, you’ll need to get at them some other way. In this new model, error details are now part of your application’s log. We’ve assigned a unique code to each type of error, and they’l be placed alongside the log line produced by the HTTP router. Like this:

18:05:10 heroku[router]: Error H12 (Request timeout) -> GET myapp.heroku.com/errortest dyno=web.1 queue=0 wait=0ms service=30000ms bytes=0

In this example, the dyno spent too long servicing the request and was timed out by the router. Each type of error gets its own error code, with all HTTP errors starting with the letter H. Here’s the complete list of error codes. In the future we’ll be adding codes for other kinds of errors that can occur (for example, errors during deployment).

Note that you’ll need the new logging add-on in order to see error code logging.

Custom Error Pages

The standard error page is unbranded, but you might wish to use an error page styled to match the rest of your site. You can’t do this directly, because these error pages are generated from outside your app. (When your app is broken or overloaded, it’s impossible for it to serve any page.)

The Custom Error Pages add-on gives you the ability to specify a URL to your own error page, which can have any text and style you want. Usage is simple:

$ heroku addons:add custom_error_pages
 Adding custom_error_pages to myapp...done.
 $ heroku config:add ERROR_PAGE_URL=http://s3.amazonaws.com/your_bucket/your_error_page.html

You can put your HTML anywhere, though we recommend S3 for its simplicity and reliability. Full docs for Custom Error Pages.

Improved Maintenance Mode

The final piece of the puzzle is a new maintenance mode, to address problems with our current maintenance mode implementation for apps with more than fifty dynos. This new implementation handles maintenance mode at the HTTP router, providing an instantaneous response for turning maintenance mode on or off regardless of the size of your app. It uses a standard page which serves with an HTTP 503 code. You can use the Custom Error Pages add-on to provide your own maintenance page to the router. (If for some reason you prefer the current maintenance mode, it’s available as Rack middleware.)

Conclusion

During the beta, adding the Custom Error Pages add-on will turn on the consolidated error page, logging of error codes, and the new maintenance mode. When the beta is over, everything other than the add-on itself will become standard for all apps. Custom Error Pages will become a premium-priced feature after the beta, reflecting its nature as useful primarily to production apps with significant investment in their brand image.

We believe these changes will significantly improve the experience of dealing with errors on Heroku. Give it a try and tell us if you agree!

Win a MacBook Air with Heroku + IndexTank

We’re very excited about the growth of the add-on ecosystem following the launch of the provider program — with dozens of add-ons in various stages of release, our developers have access to a wide variety of functionality for their applications. One of the most recent additions to the generally-available add-on catalog is IndexTank, a real-time search-as-a-service with some great features.

In order to celebrate their release, IndexTank is sponsoring a contest over the holiday season. From last week until January 6th, they’re inviting developers to build the best app they can using the IndexTank add-on. You can see the full details over on IndexTank’s blog, but the TL;DR of it is: build something awesome on Heroku with the IndexTank add-on (they’re offering their $300/month plan for free during the contest) and submit it for judging.

If you don’t have a huge dataset to work with, they’ve also got some great suggestions — everything from the Twitter firehose and Wikipedia to open government data from Sunlight Labs. As for prizes, they’re giving away a Macbook Air, a USB mini-monitor, and a t-shirt with a working guitar on it(!).

Sneak away from the family for a little while over the holidays and make something great — get started today!

PostgreSQL 9 Public Beta

At Heroku, we believe PostgreSQL offers the best mix of
powerful features, data integrity, speed, standards compliance, and
open-source code of any SQL database on the planet. That’s why we
were so excited to see the new release of PostgreSQL, version 9.0.1.

The release is described as “the most anticipated PostgreSQL version in five years” for good reason. The release adds over 200 new features and improvements. For more on PostgreSQL 9, see the coverage in Computerworld, Infoworld, and Linux.com as well as the discussion on Hacker News.

Today we are making PostgreSQL 9 available to all Heroku users through our public beta program. It is offered as a dedicated database with specifications identical to our existing Ronin plan. As a beta release, we do not recommend using this for production applications.

This is an excellent opportunity to test the compatibility of your schema and application code with PostgreSQL 9, and to try out its new features. Please note that our implementation does not yet support streaming replication or hot-standbys.

The beta will be available for free provided that you test its compatibility with your application and fill out this brief questionnaire . If you do not fill out the form we will charge the standard Ronin rate of $200 / month. The beta plan will be available for one month, after which we will ask users to migrate to non-beta plans.

To provision PostgreSQL 9 on a new application and restore a PG Backups database backup, use the following commands:

$ sudo gem install heroku     # To install the latest version of the Heroku gem
$ heroku addons:add heroku-postgresql:pg9test --app <your test app name>
$ heroku pg:promote --db HEROKU_POSTGRESQL_PG9TEST_URL --app <your test app name>
$ heroku pgbackups:restore `heroku pgbackups:url --app <your production app name>`

Give it a try and let us know what you think.

Heroku Gets Sweet Logging

Access to application logs on Heroku has historically been one of the least usable functions of the platform. The “heroku logs” command was nothing more than a broadcast fetch of the logfiles for every web and worker dyno in your app. This worked ok for small apps, but the user experience became very poor once you got past five or ten dynos.

I’m incredibly excited to announce that today we’re rolling out the public beta of our new logging add-on. This is a whole new way of capturing and collating logs, based on a syslog routing layer we’ve dubbed Logplex. Logplex routes syslog traffic the same way that our HTTP routing mesh routes HTTP traffic. Not coincidentally, Logplex was built by Orion Henry and Jacob Vorreuter, the same geniuses behind the Heroku HTTP routing mesh.

Using Logplex, we can route logs not only from all of your application processes (web, worker) into a single location. Even better, infrastructure components in the platform that interact with your app can also write to the same place. For example, here’s a snippet of logs from a single HTTP request to a Rails app:

$ heroku logs
2010-10-21T14:11:16-07:00 app[web.2]: Processing PostController#list (for 208.16.84.131 at 2010-10-21 14:11:16) [GET]
2010-10-21T14:11:16-07:00 app[web.2]: Rendering template within layouts/application
2010-10-21T14:11:16-07:00 app[web.2]: Rendering post/list
2010-10-21T14:11:16-07:00 app[web.2]: Rendered includes/_header (0.1ms)
2010-10-21T14:11:16-07:00 app[web.2]: Completed in 150ms (View: 27, DB: 121) | 200 OK [http://myapp.heroku.com/]
2010-10-21T14:11:16-07:00 heroku[router]: GET myapp.heroku.com/ dyno=web.2 queue=0 wait=0ms service=251ms bytes=24523
2010-10-21T14:11:16-07:00 heroku[nginx]: GET / HTTP/1.1 | 208.66.27.62 | 247 | http | 304

The logs show not only the Rails logs from the dyno which served the request (web.2), but also logs from the HTTP routing mesh and Nginx. We also log events like web dynos idling and un-idling, process restarts, and more.

The logging add-on also adds some seriously bad-ass client-side features. You can filter down to an individual source or process (for example, just your app logs, or just the logs from worker.1). And realtime tail (heroku logs —tail) is spectacular for any app that’s doing heavy background processing. The docs have all the details.

Keep in mind that this is a beta feature, so there will be a few rough edges. During the beta process we need to prove that Logplex can scale to handle the huge volume of logs being generated by all the apps running on Heroku. We’re also working on more options for long-term archival and search of app logs. Once these questions are answered we’ll be able to remove the beta label, at which time the logging:basic add-on will become the default for all new apps.

The Next Level

What if enterprise apps were built the way you’d build an agile Ruby app? What if they were a pleasure to work with, deploy, and manage? What if big companies could adopt the philosophies of Heroku and the Ruby community? What if your company actually preferred you use Heroku to build apps?

That’s the next level for Heroku. That’s where we want to go, so we’ve made a decision we’re excited to share: we have signed a definitive agreement to be acquired by salesforce.com. We expect the deal to close by January 31st.

Why Salesforce.com?

Salesforce.com is the original cloud company. They convinced the enterprise world to consume software as a service before Gmail, Basecamp, or Facebook existed. They created one of the world’s first platforms-as-a-service and helped popularize the term. They get it.

Heroku always aspires to be trusted by more customers with their data and applications. Salesforce.com has achieved a level of trust and credibility unparalleled in the cloud. They are trusted today by the largest companies on the planet to store their most sensitive data. And their sales and support organizations are second to none.

We have long been fans of salesforce.com due to the unusual philosophies they share with us:

No software, no private cloud
There is so much value provided to customers when they consume services rather than buying software and running it themselves. Salesforce.com is religious about not selling software for private cloud use, and so are we.

Abstraction = Value
Don’t make users, customers, or developers do anything they don’t have to. Let them focus 100% on their data and their applications. Most products are more hands on and less abstract than Heroku. Salesforce.com however, is even farther down the abstraction curve than we are.

Multi-Tenancy
Multi-tenancy enables continuous upgrades and improvements, maintainability, and scale. Multi-tenancy is an architectural decision key to how both Heroku and salesforce.com have achieved success.

Salesforce.com Loves Heroku

Salesforce.com loves our developers and the community and culture they have brought to our platform. They love our maniacal focus on the developer experience. They love that we are a 100% open platform, enabling openness and choice everywhere we possibly can. They love that we support the tools and languages and architectures of the next generation of web apps.

Salesforce.com aspires deeply to these same goals and sees Heroku as leading the way. Together we can bring an open platform for modern apps to enterprise customers.

To hear this in the words of salesforce.com, see founder Parker Harris’s blog post: What I Love About Heroku.

Independence

Salesforce.com loves who we are and wants to preserve our brand, product, our values, and our roadmap. Though we’re joining forces, Heroku will remain independent.

This means the whole Heroku team, the founders, our technology and services, our free offerings for developers, our exciting roadmap, existing customer signup process, and most importantly our philosophies will remain intact and unchanged.

Our focus on design and user experience will stay as sharp as ever; we will stay purple. The Heroku you know will continue to grow.

Our roadmap stays the same, but we can do more of it, faster. Joining forces with salesforce.com gives us an enormous amount of fuel to keep building the platform toward the vision we’ve always had.

Ruby

This deal is a victory and validation for all of our early adopters, our passionate users and customers, and for the Ruby community as a whole. The combination of salesforce.com’s trust and credibility with Heroku’s developer-focussed platform will be an incredible force pushing Ruby into the mainstream.

Heroku has been designed from the beginning to support multiple languages, but Ruby will always be our first love.

As we’ve talked about before, over the long run we want to constantly support more use cases and allow developers to choose the right tool for the job, like we did with our experimental Node.js support. Joining forces with salesforce.com doesn’t change this; we will add other languages when and where we feel it advances those goals.

Amazon and Ecosystem

Our relationship with Amazon Web Services will remain unchanged. We are huge fans of Amazon’s EC2 and the fast growing ecosystem of cloud services within it, and have no plans to leave. We are likely to add additional infrastructure providers over time to support a variety of customer use cases, and as above, we will follow the same path and decision making process we always have.

Great for Developers and Customers

Heroku will always be focused on developers above all else. Salesforce.com deeply understands why that is valuable and is making an enormous bet that we will continue to make developers happy. Not only does Salesforce.com want us to continue on unchanged, but they hope through this merger some of Heroku’s philosophies will rub off on them.

With salesforce.com’s trust and credibility, it will soon be a no-brainer to convince your company to use Heroku for your important projects.

With salesforce.com’s huge reach, we will be able to grow the ecosystem faster. This means more add-on providers with more great cloud service options for developers.

For customers, this means we will soon provide better sales processes for larger organizations, add more trust and security for data and applications, achieve more IT policy compliance, and provide more premium support options.

Great for Add-on Providers

The salesforce.com brand plus accelerated growth of the developer base, the types of applications on the platform, and the number and size of customers all bring huge opportunity for add-on providers.

Our Commitment

The founders and the whole team at Heroku are 100% committed to the long term vision we have shared since the beginning. This is Heroku going to the next level; a chance to further our vision, to take things to a larger scale, and to reach a wider audience than ever before with our product and our message about next-generation deployment.

We couldn’t be more amped!

The Heroku Team


Official press release here.

Browse the blog archives or subscribe to the full-text feed.