Recurring Project Maintenance Calendar

Design the calendar around evidence decay

Cadence should follow three inputs: how quickly the underlying state changes, how much harm silent failure creates, and how expensive a safe check is. A checkout can break after any deployment or provider change, so a reversible synthetic check may run daily. Domain recovery access changes slowly, but the cost of discovering a problem during an incident is high, so review it quarterly and after personnel or registrar changes. Legal copy is event-triggered by practice and policy changes rather than a weekly timer.

Write an expiration rule beside every receipt. A test email from today might support the support-delivery check for a week; a current sitemap fetch might be useful until the next routing deployment; a recovery exercise may remain credible for a quarter. Expiration keeps historical proof from masquerading as current truth. It also reveals where automation can reduce cost without replacing accountable review.

• State-change rate
• Consequence of silent failure
• Cost and risk of a safe check
• Receipt expiration
• Event triggers that force an early recheck

Daily: protect high-consequence user paths

Daily checks should be few, cheap, and tied to direct user harm. Confirm the public site returns useful content, the primary conversion route accepts a safe fixture, and critical background jobs have not accumulated failures. For paid products, test-mode payment and webhook monitoring may belong here, but do not create real charges or messages simply to satisfy cadence. Use a check designed for repetition and keep its data isolated.

Monitor symptoms first. Google SRE guidance recommends signals that reflect service behavior such as latency, traffic, errors, and saturation, but a small product still needs the business-layer result: the signup created, the report delivered, the support request queued, or the checkout reconciled. Emit a compact receipt with environment, timestamp, result, and deployment version. Page someone only when the failure needs a decision; do not train the operator to ignore noisy daily alerts.

• Homepage and primary journey smoke
• Failed scheduled jobs and webhook backlog
• High-risk support or security queue
• Payment state reconciliation alerts
• Recent deployment regression signal

Weekly: close loops that need human judgment

Weekly work is where a small team reviews evidence and makes one or two decisions. Inspect the oldest support items, acquisition freshness, content CTA path, unusual activation changes, failed provider tasks, and upcoming commitments. Sample actual receipts instead of accepting aggregate counts. If an automated run says seven posts were published, open the canonical URLs and verify that they are useful, correctly attributed, and linked from the intended hub.

Use the weekly review to prune. Pause channels with no strategic role, remove duplicate metrics, and convert repeated exceptions into tests or clearer policies. Finish with one named decision: repair a conversion path, change a cadence, update an owner, stop an experiment, or keep the current course. A weekly report that merely restates numbers creates maintenance work without operating leverage.

• Support aging and escalations
• Channel freshness and message truth
• Content-to-activation sample
• Provider-task exceptions
• One evidence-led decision and owner

Monthly: walk the complete public-to-value journey

Run a full signed-out journey on desktop and mobile. Start from a realistic acquisition link, inspect the canonical page, complete the CTA, cross authentication, reach activation, and verify the final artifact. Confirm source context survives redirects and signup. Review the sitemap, robots response, trust pages, contact route, pricing, current beta language, and the highest-traffic evergreen content. This is a deliberate human walkthrough, not a replacement for daily automation.

Reconcile the systems that can drift: analytics against first-party records, payment provider against entitlements, public documentation against product behavior, and scheduled tasks against actual public artifacts. Document material discrepancies and do not force numbers to match when definitions differ. The monthly review should improve the measurement contract, not manufacture a clean dashboard.

• Acquisition-to-activation walkthrough
• Canonical, sitemap, robots, and trust review
• Pricing and product-claim truth
• Analytics and first-party reconciliation
• Recovery of one controlled failure

Quarterly: rehearse continuity and clean access

Quarterly checks protect the assets that change less often but become existential during an incident. Review domain registrar, DNS, deploy platform, source repository, database, payment provider, analytics, support, email, and key social accounts. Confirm primary and backup owners, recovery methods, billing contacts, and the location of controlled credentials. Remove access that is no longer required and verify that emergency access is possible without copying secrets into the calendar.

Run one tabletop exercise. Choose a plausible scenario such as an unavailable founder, broken production credential, provider outage, accidental deploy, or compromised social account. Walk through detection, communication, safe mode, restoration, evidence, and post-incident improvement. NIST contingency planning and CISA incident response material are larger than most startups need, but their emphasis on roles, restoration priorities, communications, and exercises scales down well.

• Critical-account ownership and recovery
• Least-privilege access cleanup
• Backup and restore evidence
• Vendor and billing continuity
• One tabletop or controlled recovery exercise

Event-triggered checks: do not wait for the calendar

Some changes invalidate evidence immediately. Re-run affected checks after routing, authentication, payment, email, analytics, canonical, domain, or environment changes. Personnel changes trigger an ownership and access review. A new claim, pricing model, audience, or data practice triggers content and legal review. An incident triggers both a regression test and an update to the recovery card that proved incomplete.

Attach triggers to change workflows. Required status checks can guard code paths, while a release template can name manual provider checks. Keep the trigger list scoped; not every text edit needs a checkout test. Map each change class to the smallest evidence set that could disprove safety, then require that evidence before the change is considered complete.

• Deploy or routing change
• Authentication or signup change
• Payment or webhook change
• Domain, DNS, or provider change
• Owner or access change
• Incident or material customer complaint

Give every routine a complete task contract

A recurring title such as check SEO is too vague to execute or review. Write the trigger, inputs, environment, safe action, expected result, evidence, accountable owner, operator, reviewer, failure threshold, escalation, and stop condition. Include a link to the authoritative source or runbook. The contract should let another competent person perform the work without guessing what done means.

Separate measurement from mutation. A crawler can safely inspect a public sitemap; submitting a provider request or publishing a post may require credentials and approval. Mark those boundaries explicitly. If the automated portion can only gather evidence, the task should stop in ready for review rather than claiming completion. This keeps a human gate meaningful and prevents quiet expansion of authority.

• Trigger and cadence
• Safe inputs and environment
• Expected result and receipt
• Owner, operator, and reviewer
• Escalation threshold
• Approval and stop conditions

Budget attention, not only task frequency

Calculate the weekly review burden. Ten daily checks that each require five minutes of human interpretation consume more than four hours per week. If they rarely change a decision, redesign them. Aggregate healthy results, surface exceptions, and sample evidence. Preserve the ability to drill into each receipt, but do not require a founder to watch every successful run.

Set work-in-progress limits for maintenance. Keep incidents and broken user outcomes separate from improvements. Reserve capacity for one or two structural fixes that reduce future toil, such as a deterministic integration test, clearer ownership, or an idempotent webhook handler. Without that investment, the calendar becomes an expanding tax rather than a compounding system.

• Estimate review minutes per cadence
• Bundle healthy evidence
• Alert on actionable exceptions
• Limit concurrent repairs
• Fund one toil-reduction improvement

Use proof that is reviewable and privacy-conscious

A receipt should answer five questions: what was checked, where, when, against which expected outcome, and what happened. Prefer durable identifiers and structured output over screenshots alone. Redact personal information, tokens, full payment details, and private customer content. Store evidence only as long as the operating or legal purpose requires, and document the retention rule.

Do not use a provider shell, outdated screenshot, or successful run from another date as current proof. Preserve exact blockers such as signed-out access, missing permission, unavailable test environment, or rate limit. A missing receipt is not automatically a failed user outcome, but it is a failed verification and should remain visible until resolved or consciously accepted.

• Check and expected outcome
• Environment and timestamp
• Authoritative result or identifier
• Redaction and retention
• Exact blocker when proof is unavailable

Turn the calendar into a reviewable worksheet

Keep one row per routine and make the row answer the questions a reviewer will actually ask. Include the protected user outcome, system dependency, cadence, trigger, owner, safe procedure, expected result, evidence location, receipt expiration, escalation threshold, approval boundary, and next review. Add a status field with a small vocabulary such as current, failed, blocked, expired, or paused. Avoid a generic done checkbox: it hides whether the check succeeded, could not run, or ran against the wrong environment.

A useful worksheet also separates the routine definition from each execution. The definition changes rarely and explains how the check should work. The execution log records the timestamp, operator or automation identity, input fixture, environment, result, evidence reference, exception, and reviewer. This structure prevents an old successful receipt from overwriting a current failure. It also makes it possible to change cadence or procedure without rewriting history.

Review the worksheet from the exception outward. Sort failed, blocked, and expired rows first; then sample current rows according to consequence. Do not reward a project for producing more receipts than it can review. If the same exception repeats, decide whether the procedure is wrong, the dependency is unreliable, the alert threshold is noisy, or the underlying product needs a structural repair. Record that decision beside the routine so the calendar becomes a learning system rather than a compliance theater.

• Protected outcome and dependency
• Routine definition separate from execution log
• Current, failed, blocked, expired, or paused status
• Receipt link and expiration
• Reviewer and escalation decision
• Structural follow-up for repeated exceptions

Choose automation by reversibility and consequence

Automate collection before automating consequential action. Fetching a public page, parsing a sitemap, checking a signed test fixture, or counting an authorized queue is usually easier to repeat safely than publishing, sending, charging, deleting, changing DNS, or revoking access. Let automation gather a dated receipt and prepare the next step; require a human decision wherever identity, money, public claims, customer communication, or irreversible state is involved.

Document the stop condition in the same row as the cadence. Stop when the environment is ambiguous, the fixture is missing, the account identity is wrong, the result conflicts with first-party truth, or the requested action exceeds the routine's authority. A stopped run is useful evidence when it names the blocker precisely. Silent retries and optimistic completion make the calendar look healthier while increasing operating risk.

• Automate safe observation first
• Use isolated fixtures
• Gate money, messages, publishing, access, and deletion
• Stop on ambiguous identity or environment
• Preserve the exact blocker
• Escalate repeated failures into a product fix

Start with the minimum viable maintenance calendar

For a small live product, begin with four routines: a safe primary-journey check, a weekly support and exception review, a monthly public-to-activation walkthrough, and a quarterly ownership and recovery exercise. Add payment, email, content, or provider checks according to actual dependencies and consequence. Do not copy every task in this guide into a new product.

Run the calendar for four weeks, then inspect false alerts, missed failures, review burden, and decisions produced. Delete tasks that neither protect an outcome nor create learning. Strengthen any check that passed while a real issue escaped. The calendar is finished only temporarily; its job is to evolve with the product while remaining small enough to operate.

• Daily safe journey receipt
• Weekly exception and support review
• Monthly full-funnel walkthrough
• Quarterly continuity exercise
• Four-week prune and strengthen review

Put this into practice

Copy the cadence ideas, but design the actual calendar from your user outcome, dependencies, consequence, and evidence-decay rate. Start with four routines, write complete task contracts, and preserve exact exceptions. A maintenance calendar creates authority when it repeatedly catches real drift, produces reviewable receipts, and gets smaller as the underlying system improves.