How we run a system we support
When we support a system, faults are caught by tests and monitoring before users report them, every change is reviewed and tested before release, and each month you get a written account of what happened. This page sets out the practice, so you can judge it before you trust us with a system the business depends on.
What we put in place
The same practice runs on the systems we already support, including OpenIRIS, which research institutions across Europe use every day. On a system we take over, it is added in stages, starting with whatever protects the business most.
Every change goes through a test copy first
Changes are released to a test environment, then to a release-candidate copy that matches production, and only then to the live system. Nothing goes straight from a developer to your users.
Automated tests run every night
Browser tests walk through the journeys your users depend on, such as signing in, booking, ordering or invoicing, every night. A change that breaks one is caught before it is released, not reported by a user.
Every code change is reviewed
Each change is checked by an automated code review and by an engineer before it is merged. The review looks for faults, security problems and changes that would make the system harder to maintain.
Errors are watched every working day
Error monitoring records every failure in production with the detail needed to trace it. The errors are reviewed each working day, and anything new or recurring becomes a tracked piece of work, often before a user has noticed it.
Performance and uptime are monitored
Application performance monitoring shows which pages and database queries are slow, and automated checks alert us when the system stops responding.
Logs that let us trace a fault
Structured server logs are kept so that a reported problem can be followed from the screen the user saw to the request and the database call that failed.
Releases on a regular cycle
Systems in active development are released on a weekly cycle. Small, frequent releases are easier to test and easier to reverse than large, rare ones.
A monthly report
Each month you get a short written report: faults and how quickly they were handled, what was released, what the monitoring showed, and the risks we see coming.
When something goes wrong
What happens between your call and the fault being closed.
You report it
By email or phone, in your own words. You do not need to know the cause. Urgent faults should be phoned in on 0800 433 7990.
We set the severity with you
By its effect on the business, using the definitions below, and confirm that work has started.
We find the cause
From the error monitoring, the logs and the code, with a workaround first if one exists, so your people can carry on.
The fix is tested and released
Through the same test and release-candidate copies as any other change, so the fix does not cause a second fault.
It is written up
What happened, what we changed and what stops it happening again appear in the monthly report.
Response times by severity
A response means someone who knows the system has started work on the problem. Severity is set by the effect on the business, so whoever reports a fault can class it without knowing the code. The response time for each level is written into your support agreement, after the assessment, so that we only commit to cover we can deliver.
| Severity | What it means | For example |
|---|---|---|
| Critical | The system cannot be used, or data is being lost or exposed. | Nobody can log in, or orders are not being saved. |
| Major | An important function has failed, but there is a way round it. | Invoices will not print, but can be exported and sent by hand. |
| Minor | Something is wrong or awkward, and work carries on normally. | A report column is misaligned, or a message is misleading. |
| Request | A question, or a small change the business would like. | Add a field to a screen, or explain how a figure is calculated. |
Cover is Monday to Friday, 9am to 5pm UK time. Out-of-hours cover for critical faults is available by agreement. Response times are confirmed in your support agreement.
What you see each month
A short report written for whoever is responsible for the system, not only for the technical team.
Read a sample report- Faults and responseEach fault, its severity, when we responded and how it was resolved.
- ReleasesWhat changed in the system and why.
- MonitoringAvailability, errors and slow pages, and what we did about them.
- Risks and datesComponents nearing the end of support, capacity, and what we recommend next.
Low risk to try
-
First month refunded
If you are not satisfied in the first 30 days of a support plan, tell us and we refund that month's fee.
-
30 days' notice
Support plans run month to month. Change plan or leave with 30 days' notice, with no minimum term.
-
Priced before we start
Every piece of work is quoted in writing before any chargeable work starts. Nothing is added to the bill without your agreement.
-
You own everything
The code, the accounts, the hosting and the documentation are in your name, and kept so another team could take over.
What that means in practice
Questions
What are your hours of cover?
Monday to Friday, 9am to 5pm UK time. Out-of-hours cover for critical faults is available by agreement.
Do you put this in place on a system you take over?
Yes, in stages. The first month of a support plan proves that the system can be built, released and restored. Monitoring, automated tests and the release process are then added in order of risk, starting with the journeys the business cannot do without.
Who pays for the monitoring tools?
Where a tool has a licence or hosting cost it is agreed with you first and, where practical, the account is in your organisation's name, so the history stays with the system if you ever change supplier.
What is the difference between a response time and a fix time?
A response time is how soon someone who knows the system starts work. A fix time is how soon the fault is resolved, which depends on a cause nobody knows yet. We commit to response times and tell you as soon as we know how long a fix will take.
Related
- Software maintenance and supportSupport plans, what they cover and how one starts.
- You own everythingCode, accounts and documentation in your name, and how we hand a system back.
- Taking over an existing systemHow we take on software another supplier built.
- What a support contract should includeThe terms to check in any supplier's agreement.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.