Founder weekly and monthly site checks

What is this for?

These two routines give you a reliable read on the health of your site without becoming the person who runs content day to day.

The weekly pulse answers "is the site up, secure, and being worked on as expected?" in 10 minutes. The monthly review answers "is the trend healthy, is the team correctly scoped, and is the site protected by current backups?" in 30 to 45 minutes.

Both routines read from screens you already know — Dashboard, Audit Log, Users, Backups, and Settings → Notifications. You are reading, not editing. Any change that needs to be made (closing a stale account, fixing a backup gap) is routed to your platform administrator, so the routines stay safe to run at any time.

The point is not to add another task to your week. It is the opposite — a short, repeatable habit that replaces the vague worry of "I should check on the site" with a clear answer you can trust. Ten minutes once a week and half an hour once a month is a small cost for knowing, at any moment, that the site is up, secure, protected, and worked on by the right people.

The two-week rhythm pairs with the longer-horizon Founder quarterly strategy review, which steps back to look at goals and growth rather than week-to-week health.

At a glance, here is how the two routines differ:

Good use cases

Reach for this cadence when you want a dependable health read without managing content yourself.

• You own the business and want a dependable health read without managing content yourself.
• You delegate publishing to a team and need to confirm the right people have the right access.
• You want an early warning when a setting changes site-wide, a backup gap opens, or an account goes stale.
• You are preparing for a launch and want to confirm a clean restore point exists before the campaign goes live.
• You have just brought on a new team member or contractor and want to confirm their access is scoped correctly.
• You want a small, repeatable habit that replaces ad-hoc "is everything okay?" worry with a clear, recorded answer.

What NOT to use this for

• Not for editing content or settings. These routines are read-and-route. If a setting needs changing, hand it to your platform administrator — do not change backup schedules or security settings mid-month yourself.
• Not a replacement for your team's operational checks. Your editors still own page QA, your marketing lead still owns campaigns. The founder cadence sits above the day-to-day, not inside it.
• Not an incident response tool. If the Dashboard shows an active critical alert, this is your signal to escalate — not to diagnose. Route it and follow up.
• Not a substitute for the quarterly review. This page covers week-to-week and month-to-month health. Goals, growth, and structural decisions belong in the Founder quarterly strategy review.

Before you start

A few things to have in place before your first cycle.

• You need an account with permission to see the Dashboard, Audit Log, Users, and Backups screens — most founder and administrator roles have this.
• Have your platform administrator's contact ready, since any change surfaced by these checks is routed to them.
• Set aside the time: 10 minutes weekly, 30 to 45 minutes monthly. Block it on the same day each cycle so it becomes habit.
• Have a place to record the four monthly headline numbers — a note, a spreadsheet, anywhere you can compare month to month.

Where to go

Every screen used in both routines is reachable from the main admin menu. The weekly pulse touches three; the monthly review adds two more.

• Dashboard — the landing screen after you sign in. Site status, traffic, and alerts.
• Audit Log — the record of who did what, with a date filter and action-type groups.
• Users — the team roster, with role and last-active columns.
• Backups — the restore-point list, with creation time and status.
• Settings → Notifications — the controls for which alerts reach your inbox.

If a screen is not in your menu, your role may not include it — ask your platform administrator to confirm your access. The first stop, every cycle, is the Dashboard:

How to run your founder weekly and monthly checks

Two routines — a 10-minute weekly pulse and a 30-to-45-minute monthly review. Run each in a fixed order, and stop reading a screen the moment it looks clean.

Weekly check — your 10-minute site pulse

Once a week — many founders do this on Monday morning before the team starts — open SGEN and run three checks. The whole routine takes 10 minutes, and it gives you everything you need to answer "how is the site doing?" without opening every section or asking your team.

The three checks map to the three questions a founder needs answered every week:

• Dashboard answers is the site up and protected?
• Audit Log answers is the right work happening, and only the right work?
• Users answers do the right people still have the right access?

Run them in that order. Each one takes two to three minutes, and you stop reading the moment a screen looks clean — you are scanning for the exception, not auditing every row.

If Site status shows a warning or error, open Settings → Status and read the detail. Most status warnings are transient — a backup job that took longer than expected, a connection that briefly dropped. If the same warning persists for more than 24 hours, escalate to your platform administrator. See Site Dashboard for the status tile and what each state means.

Audit Log — past 7 days · 42 logged actions (Content 28 · Settings 4 · Users 3 · Security 0).

The Audit Log groups activity by type, so you can read it at a glance. Content actions — page and post publishes, edits, deletions — should make up the bulk of a healthy week. A handful of Settings and Users actions is normal. What you are watching for is anything in those last two groups that you did not expect.

If you see a Settings action you did not authorise — a billing change, an email credential update, an integration modification — flag it to your platform administrator immediately. Settings-level changes have site-wide consequences, and the Audit Log records who made each change, so your administrator can trace it quickly. A Security count above zero — failed logins, permission escalations — is always worth a question, even if it turns out to be benign. See Audit Log for the action-type filter and the user-attribution column.

Users — 8 accounts (6 staff, 2 contractors) · All 8 · Active 8 · Deactivated 0 · Trash 2.

Two columns carry the signal: Role and Last active. A high role (Administrator or Editor) paired with a stale Last active date is the pattern to watch — it means broad access is sitting on an account no one is using. The most common cause is a contractor whose engagement ended but whose account was never closed.

If a contractor shows Last active: 3+ weeks ago and the engagement has ended, ask your platform administrator to move the account to Trash. Closing the account does not delete the work they published — it removes their access while leaving the content in place. See Manage users list for the bulk-deactivate and trash workflow.

When something on the weekly pulse looks off, use this table to decide whether to route it or note it and move on. The founder rule of thumb: route anything you did not authorise; note anything that is expected activity.

A clean weekly pulse ends with three confirmations:

Monthly review — site health and team check

At the start of each month, block 30-45 minutes. This is the session where you look at the prior month with enough distance to see the trend — not the day-to-day noise. It covers four areas: site health, team structure, backup status, and notification hygiene.

The monthly review is not a longer version of the weekly pulse — it asks different questions. The weekly pulse is about exceptions this week; the monthly review is about trend and structure over the month. Where the weekly check scans for anything out of place, the monthly review steps back to confirm the foundations are sound: traffic is moving in the right direction, the team roster matches reality, backups are current, and your notifications still carry signal rather than noise.

A simple way to keep the monthly review consistent is to run the same four steps in the same order every month, and to record the four headline numbers somewhere you can compare month to month — total events, critical alerts, backups run, and active team logins. Over a few months those four numbers become your founder dashboard, and the trend tells you more than any single month's snapshot.

Here is how to read each headline number:

• Total events — your traffic volume for the period. On its own a single number means little; its value is in the comparison to the months before it.
• Critical alerts — should read zero in a healthy month. Any count above zero is a prompt to open the Audit Log for that period and confirm each one was resolved.
• Backups run — should be close to the number of days in the month for a daily schedule. A count well below that points to a gap in the schedule.
• Team logins — should match the number of people you expect to be active. A number lower than your active roster suggests an account is going unused.

If Critical alerts shows any count above zero, open Audit Log and filter to that period to identify what triggered them and whether they were resolved. If Backups run shows a count significantly below the number of days in the month, your backup schedule may have gaps — escalate to your platform administrator.

The single month-end number tells you "is it healthy now." What you are watching for as a founder is the direction over time — a steady or rising events line means the content strategy is working; a sustained drop is a signal to talk to your marketing lead. If your Dashboard exposes a multi-month view, read the trend rather than the single tile. A six-month events trend for a growing site reads like this:

A clean roster at month-end has no gaps: every active account shows a login within the past 30 days, and every contractor engagement that ended has been closed.

The month-end roster review catches the slow leaks the weekly pulse can miss — an account that quietly stopped being used, a role that should have been lowered when a project wrapped, a login that turns out to be shared across two people. None of these are urgent in any single week, which is why a deliberate monthly pass is the right place to find them. For anything you want changed, send the account name and the reason to your platform administrator and let them make the edit.

Two things make a backup screen healthy, and both are visible at a glance. First, the most recent backup should be inside the last day or two — that tells you the automated schedule is running. Second, there should be at least one older restore point that predates any major change you made this month — that is the one you would reach for if a big edit went wrong. The list below shows both: a current auto-daily run at the top and a pre-launch manual restore point a few days back.

A healthy backup screen for a site running automated daily backups reads like this:

If the most recent backup is more than 48 hours old and your schedule should be daily, escalate to your platform administrator — do not attempt to modify backup settings yourself unless you have been briefed on the consequence of changing the schedule mid-month. See Create and restore backups for the backup schedule and manual backup workflow.

After you lower the notification level and save, SGEN confirms the change with a save flash:

Make it a habit

A founder cadence only delivers value when it runs on schedule. The two routines are short by design, so the limiting factor is consistency, not time. Three small commitments keep both routines on the rails:

• Pick a fixed slot. Tie the weekly pulse to something you already do every week — Monday morning before the team starts is a common choice. Tie the monthly review to the first working day of the month.
• Record the four headline numbers. Each month, note total events, critical alerts, backups run, and active team logins. Comparing those four numbers month over month turns a snapshot into a trend.
• Route, do not fix. When a check surfaces something, send it to your platform administrator and move on. The discipline of read-and-route is what keeps the routine fast and safe to run.

The first time through, both routines take a little longer while you learn where each screen lives. By the second or third cycle, the weekly pulse settles into its 10-minute slot and the monthly review into its 30-to-45-minute block.

If you are new to the founder role, a simple first-30-days ramp gets you to a steady cadence:

After that first month you will have one data point to compare against, and every cycle from there builds the trend that makes the cadence worth running.

What success looks like

You know the cadence is working when:

• The weekly pulse takes 10 minutes or less, and most weeks end with three green confirmations and nothing to route.
• The monthly review ends with a healthy events trend, a roster where every active account logged in this month, a most-recent backup inside 48 hours, and a notification inbox carrying only critical alerts.
• Anything that needed action was routed to your platform administrator, not changed by you — and the following week's Audit Log confirms the change was made.

A founder running this cadence can answer "how is the site doing?" at any moment without opening every section or interrupting the team.

A clean month, end to end, looks like this: four weekly pulses that each ended in under 10 minutes with nothing to route, a month-end snapshot showing a rising events trend and zero critical alerts, a roster with no stale accounts, a most-recent backup from this morning plus an older restore point you could fall back on, and a notification inbox that carried only the alerts that needed a decision. When that is the picture month after month, the cadence is doing exactly what it should — keeping you informed while staying out of your team's way.

When a month is not clean, success looks different but just as good: the check caught the issue, you routed it, and the next cycle confirms it was resolved. A cadence that surfaces one real problem a quarter has already paid for the time it costs.

What to do if it does not work

Founder checks — common snags and how to clear them.

If a check surfaces something this list does not cover, route it to your platform administrator rather than acting on it. The founder cadence is a read-and-route routine by design.

When in doubt, the safe default is always the same: read it, record it, route it. You never need to fix anything from inside these routines for them to do their job.

Examples

Each example walks one routine from trigger to resolution, so you can see how the screens, the decision table, and the route-it rule fit together in practice.