These are three things that users or visitors can do on the site that must always work.

They follow the form:


For example:

  • An anonymous user visits the home page and can play the video
  • An anonymous user visits and sees a list of stories with a thumbnail, title, author and description
  • A user with the editor role can create and edit an 'activity' node and view the resulting page

When on-boarding a new customer, we gather 3 critical cases for each site. You can provide these via e-mail, or if you'd prefer, we can talk through them over the phone.

We use these for testing any update we make to your site, and when possible, we'll actually automate tests for them (using Behat, if you're curious about the tech side of it :-)).

If one of the critical use cases stops working, we consider it a critical issue.

How are the 3 critical use cases used?

Before deploying most changes to your site, we'll first test them on a staging version of your site. As part of this testing, we'll try your 3 critical use cases. If one of them fails, we won't deploy the change to your site until we fix it.

This is particularly important when deploying security updates! It's important to make security updates as quickly as possible (and we promise that we'll make them the same day they're released). But sometimes a security update will also break some part of the site, and so we want to test the change first, but testing can be time consuming.

By testing the 3 critical use cases we strike a compromise: we can get updates out fast, and we know that the update at least doesn't break anything critical.

Obviously, in the rare case that an update causes *any* problems (even outside of these use cases) we'll help fix it, but these provide a "smoke test" to ensure that at least the most critical things are unaffected.

NOTE: On the Basic plan, we only fix critical issues, including site outages, the site getting hacked or the critical use cases breaking, or any problem introduced by an update we did. On the Standard and Enterprise plan, we'll fix any problem that's within scope.

Why only 3 critical use cases?

If you insist (and you're on the Standard or Enterprise plan), we'll accept 4 or 5 critical use cases. :-)

However, we find that having too many dilutes the "criticality" and starts to include things that aren't truly critical. This starts to take away the value from marking certain things as critical, and you may as well not mark anything as critical.

The critical use cases should represent the things that would require immediate action. It's usually best to focus on external users, since those are usually the most critical - issues that affect internal users lead to annoying delays where people can't get their work done for a short time, but they can usually remain broken for a couple hours while a solution is found.

Remember: unless you're on the Basic plan, you aren't limited to things that affect the critical use cases. We'll help you with almost any problem that affects your site! So, there's no need to try and make tons of critical use cases :-)

Why are the critical use cases included in the contract?

For the Basic plan, it's important to include the critical use cases in the agreement that we sign with you because they help to define the services we're providing you.

However, for the Standard and Enterprise plan signing off on the use cases is largely symbolic. It signifies that we've sat down and decided in advance what we're going to consider critical.

Can I change my critical use cases later?


As sites and organizations grow and evolve, the things that are "critical" also naturally evolve. You can let us know any time you want to change your 3 critical use cases, and we'll send you a new amendment to the agreement to sign.

However, if you're on the Basic plan, please don't change your critical use cases just to "trick" us into helping with your latest issue. That's not cool and it violates our trust. If it becomes a pattern we'll call you out on it and consider whether we want to continue our relationship or not.