A Monday planning habit: pick the week's tasks and keep the list short
Most small teams do not fail because they lack work. They fail because the list has forty items and nobody can say which five matter this week.
On a Monday, open the task list and pick no more than five things. Put everything else in the backlog and leave it there until the next Monday. Give each task one owner and one line that says what done looks like. 'Fix the contact form' is a wish. 'Contact form sends to the right inbox and the test passes' is a task someone can finish.
A short list gets read. A long list gets scrolled past, and the work that matters sinks into it. If a task has sat in the backlog for three weeks, that is a signal too. Either it is not important or it needs to be split into smaller pieces.
Midweek: an alert arrives and the team decides whether it needs a task
On a Wednesday, a monitor sends an alert. A client's site has stopped responding for four minutes. The alert goes only to people in your organisation, so the right person sees it first.
The question is not 'what broke?' yet. The question is 'does this need a task?' Some alerts are noise: a slow response during a backup, or a single failed check from a flaky network. Others need a person to look at them today.
Here is a simple rule. If the alert needs someone to change code, configuration or a server, create a task and assign it. If it resolved itself and nothing changed, note it in the incident and move on. Either way, the decision is recorded. A team that decides on purpose is less likely to ignore the next alert.
If the alert affects customers, post an update on your status page. Say what you know, what you are doing and when you will update next. Do not promise a fix time you cannot keep.
Using grouped errors to see what is repeating and what is new
An error that happens once is rarely a crisis. An error that happens two hundred times across a day is a pattern, and patterns need attention.
Grouped errors help here. Similar errors are collected into one group, so you see the same stack trace once with a count, rather than two hundred separate lines. On a midweek check, look at two things: which groups grew since Monday, and which groups are new.
New groups deserve a look even when the count is low. They often come from a recent deploy. Repeating groups that have been around for weeks may be known and accepted. Write that down so the next person does not spend an hour rediscovering it.
The aim is not to clear every group. The aim is to know which errors are old, which are new, and which are growing. That is enough to decide what goes on Monday's list.
Friday: a ten-minute review of what was done, what slipped and what broke
On Friday afternoon, set a timer for ten minutes. Go through three short questions.
What was done? Move finished tasks to done and note anything that shipped. What slipped? Tasks that did not move go back to the backlog, or they get a new date and a reason. What broke? Check the incidents and alerts from the week, and confirm each one has an outcome.
Keep the review short. It is not a meeting about who was slow. It is a record. When someone asks in a month why the contact form changed, the answer should be easy to find.
This review is a habit you run by hand. Nothing in the product writes it for you, and that is deliberate for now. Writing it yourself makes you read the week.
A weekly habit list a team of two to ten can copy
The routine above fits on one card. Copy it, adapt it and pin it where the team can see it.
- Monday: choose no more than five tasks for the week. Give each one an owner and a finish line.
- Monday: check the backlog for anything that has stalled for three weeks and split or drop it.
- Daily, for a minute: scan new alerts. Decide task, note or ignore, and record the decision.
- Wednesday: review grouped errors. Note new groups and growing groups.
- Any customer-facing outage: post a status update within the first hour, then update it at the time you promised.
- Friday, ten minutes: review done, slipped and broke. Write the outcome next to each item.
- Monthly: look at which monitors cause the most noise and tune their thresholds.
A team of two can run this in less than an hour a week. A team of ten may need a named person to own the Friday review, so it does not drift.
What works today and what is still manual, said plainly
Here is what you can do today. You can track tasks, set up monitors, including heartbeat monitors for cron jobs and backups, and view grouped errors. You can run a status page and post incident updates on it. Alert emails go only to people in your organisation. The service is run from the UK and hosted in France. You can download your data.
Here is what is still manual. The planning habit, the Friday review and the decision about whether an alert needs a task are all done by people. The product gives you the information. It does not make the decisions for you, and it does not replace a team agreeing on how it works.
We are a small company with a live product, and we would rather say that than oversell it. If a habit above does not suit your team, change it. The point is to have one routine that everyone follows.
Tweed Tyne runs its own work this way
Tweed Tyne runs its own work on AperioFlow, using the same weekly routine described here. The Monday list, the midweek alert decisions and the Friday review all happen in the same place that monitors the sites they look after. It is the simplest way we know to show what the habit looks like in practice.
If your team is small and you are the person who gets the message when something breaks, the routine is worth trying for a few weeks. Pick five tasks on Monday, decide on each alert, and spend ten minutes on Friday looking back.
Start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors. If you grow past one person, the team plan is 29 pounds a month flat for up to 10 people, as on the pricing page.