Admin Panel

Overview

The admin panel gives the operator of an installation platform-wide visibility and a small set of platform-wide controls. It lives at /admin, opens from the Admin entry of the sidebar, and is only there for accounts marked as admin: it has nothing to do with plans. It is separate from a schedule owner's own admin portal, and nothing here is scoped to one schedule.

The navigation is five tabs. Dashboard and Realtime are each a page; Insights, Manage and System each hold several, and which of those appear depends on how the install is configured. This guide follows the same order.

The tabs run across the top of every admin page. A tab that holds several pages opens its first one, and a second row under the tabs lists them all, with the page you are on marked. On a phone the whole section is one dropdown, grouped the same way. A number beside a tab or a page counts what is waiting on you there; see Needs attention.

A Refresh button sits at the end of the navigation row and reloads the page. Realtime has none, because it updates itself, and Support checks for new messages on its own; every other page shows its numbers as of the last page load.

Date range

Six pages carry a date-range selector, at the end of the line that says what the page shows: Users, Revenue, Analytics, Usage, Growth and Boost. The choices are fixed: Last 7 Days, Last 30 Days (the default), Last 90 Days and All Time. There is no custom start and end date. Where a page shows a change percentage, it compares against the immediately preceding window of the same length. All Time has no preceding window, so read its change figures as noise: with nothing to compare against, every one of them reports +100%.

The Dashboard has no selector: its windows are fixed at the last 24 hours, the last 30 days and the last 12 weeks. The Audit Log has its own From and To date filter instead, and the remaining pages are not date filtered at all.

Accessing /admin

The admin panel lives at /admin, which redirects to /admin/dashboard. It is restricted to users whose is_admin column is set to true. There is no screen for granting that, on purpose, so it is done from the command line or in the database.

1. Grant the flag by running php artisan app:make-admin [email protected] on the server, or by updating the users table directly (see the query below). Run the command with no email to list who is an admin already.
2. Make sure the account has a password. An account created through Google or Facebook sign-in has none, and the panel will send you to the Security tab of your settings to set one first.
3. On an install with IS_HOSTED=true, turn on two-factor authentication for the account. The panel refuses an admin without it and sends them to the same Security tab. A plain selfhost does not ask for it unless you set ADMIN_REQUIRE_2FA=true.
4. Sign in and open /admin, or use the Admin entry that now appears in the main sidebar, just above Settings.
5. Re-enter your password when prompted. This confirmation is required once per session, on top of being signed in.

php artisan app:make-admin [email protected]

Or, if you would rather do it in the database:

UPDATE users SET is_admin = 1 WHERE email = '[email protected]';

Session protections

• Password confirmation - stored per session, so a rejoined session asks again. Failed and successful confirmations are both recorded in the audit log.
• Re-authentication window - a confirmation lasts 24 hours of inactivity, and loading any admin page restarts that clock, so an admin at work is not interrupted. Separately, a confirmation is never good for more than 30 days no matter how continuously the panel is used - only entering the password again resets that ceiling. Set ADMIN_REAUTH_TIMEOUT and ADMIN_REAUTH_MAX_LIFETIME (both in seconds) to change them. Neither can outlast SESSION_LIFETIME (minutes), because both are stored in the session.
• Browser binding - the confirmed session is tied to the browser that confirmed it. If the user agent changes, the confirmation is dropped, an admin.session_changed entry is written, and you are asked to confirm again.
• Rate limits - admin pages allow 30 requests per minute per user, and the password confirmation form allows 5 attempts per minute.

Dashboard

The dashboard is the landing page of the admin panel and is read-only. Its windows are fixed: the last 24 hours, the last 30 days and the last 12 weeks. An install with no schedule, no event and no account but yours shows the headline numbers and a single card until there is something to report. From top to bottom it shows:

Open full size

Open full size

Needs attention

Above the metrics sits Needs attention: every queue in the admin panel that is waiting on a person, as a row of links, each going straight to the page where you deal with it. The first four are shown and the rest open from the last link. It is only rendered when there is something in it, so a dashboard without it means nothing needs you.

Rows are listed in the order below: breakage and held-up money first, then review queues, then rows that are informational. A row with a count of zero is omitted, and a row whose page does not exist on this install can never appear.

The same counts drive the badges on the Insights, Manage and System tabs and on the pages in the row under them (on a phone, the number in brackets after a page's name in the dropdown). A tab's badge takes the colour of the most serious row it contains, so a failed job is not softened by sitting next to an informational row such as an available update. Each count reuses the query the destination page runs, so a badge and the page it links to cannot disagree.

Realtime

Realtime shows who is on the site right now: the marketing site, schedule and event pages (custom domains included), the signed-in app, and the sign-up and log-in pages. It is switched on and off at Settings; it starts on for eventschedule.com and off on every other install. While it is off, the tab holds one card that says what would be recorded, with a Turn on in settings button.

Open full size

Open full size

The page updates itself every ten seconds and slows to once a minute while its tab is hidden; a dot at the top says Live or Reconnecting. If your password confirmation lapses while it is open, it stops and asks you to confirm again. From top to bottom:

Consent decides who is identified

Turning Realtime on also turns on the cookie consent banner. A visitor who allows analytics (Allow all, or Analytics ticked under Choose) is shown as a person, with a daily-rotating one-way key and, when signed in, their account, including the pages they viewed in that browser just before signing in (not what the browser shows after they sign out). Anyone who declines, does not answer, or whose browser sends Global Privacy Control is only counted: their page views appear in the chart and the three lists, with no identifier and nothing that links one page view to another (pages behind sign-in are recorded by kind, such as "/{subdomain}/{tab}", rather than by address). Withdrawing consent later, including through the privacy page, strips the identifiers from what that browser still has on its current network, and from the account's records when they are signed in at the time. The line beside Visitors right now says what share of page views comes from visitors who have not accepted, and the Visitors card what share from those who have.

Records are deleted about an hour after a visitor's last activity. Realtime stores no IP address or user-agent string and sets no cookie of its own. Site administrators see all of its records. Schedule owners see none of them unless you also switch on their own view, and then only the part about their own pages and never who anyone is.

Who is never counted

REST API clients, including apps and AI agents using an API key; calendar feeds; email opens; visitors with JavaScript turned off; and embedded calendars on other websites, which appear only as a count at the bottom of Visitors right now. A schedule owner signed in on their own custom domain appears anonymous there, because their session belongs to the main domain. Identical phones with the same language setting on one network can count as one visitor. A blocked account is left out too, with every view of its schedules' and events' pages and what happened on them in the last day. What it browsed while not signed in, before or after, shows as an anonymous visitor and is never joined to anyone else.

What schedule owners see

A second switch at Settings, Show schedule owners live traffic to their own pages, gives everyone who manages a schedule a Realtime tab on their Analytics page, and a Realtime number on their dashboard, described in the Analytics guide. It is on for eventschedule.com and off on every other install until you turn it on, and it works only while Realtime itself is on.

Users (Insights)

Users is the first page of the Insights tab: an aggregate report on who signed up in the period, how far they got, and where they came from. It is not a user directory: there is no search box, no per-user page to open, and no way to edit an account from here. Only confirmed accounts are counted, and the demo account is excluded. From top to bottom:

Open full size

Open full size

To act on a single account or schedule, use Manage > Schedules, which is where the search, filters, plan editing and manual verification live.

Revenue (Insights)

The Revenue page reports on ticket sales across every schedule, plus subscription health where the install sells plans. Amounts are the payment amounts recorded on each paid sale. A partially refunded sale stays paid, so it counts at its full amount, and only fully refunded sales count toward the refund rate. The totals are all time; the date range sets the trend and the figures marked "in period". From top to bottom:

Open full size

Open full size

Amount mismatches

When the amount a payment provider reports does not match the amount the sale expected, the sale is parked as a mismatch rather than being treated as paid. Those sales, and any boost campaign in the same state, are listed in an amber panel, with two actions each:

• Approve - accept it and mark it paid. For a ticket sale, the buyer is then sent their tickets
• Refund - for a ticket sale, send the whole payment back through the provider that took it, Stripe, PayPal or Razorpay, which the confirmation names. The button only appears when that provider can refund, so a mismatch paid through Invoice Ninja or Payfast offers Approve alone. A boost campaign's charge is refunded through Stripe

Both ask you to confirm, both are recorded in the audit log, and the row disappears from Needs attention once the queue is empty. Schedule owners refund their own sales, in full or in part, from their Sales page; see Managing sales.

Subscriptions still billing for deleted schedules

A red Subscriptions Still Billing for Deleted Schedules panel lists every subscription Stripe will keep charging although its schedule is gone, so the owner cannot cancel it from the app. Each row has a Cancel in Stripe action, which asks first, then cancels the subscription in Stripe and writes the cancellation to the audit log. Cancelling refunds nothing: a charge made after the schedule was deleted has to be refunded in the Stripe dashboard.

Subscriptions on an unrecognized price

A red Subscriptions on an Unrecognized Price panel lists live Stripe subscriptions whose price is none of the plan prices this install sells. The app cannot tell which plan such a customer is paying for, so the plan is withdrawn and the subscription counts as zero revenue while Stripe keeps charging. There is no button: either add that price ID to the STRIPE_PRICE_* configuration, or move the subscription onto a current price in Stripe.

Refunds awaiting confirmation

A refund that was sent to Stripe, PayPal or Razorpay and still has no confirmed outcome after 15 minutes is listed in a red Refunds Awaiting Confirmation panel, with its date, event, amount, status, reference and last error. The money may or may not have moved, and nothing in the app retries it, because a retry after the provider's idempotency key has expired is how one refund becomes two. Look the reference up in the provider's own dashboard and settle it there. Until then the refund holds its amount against the sale, so the schedule owner cannot refund that money again.

Analytics (Insights)

The Analytics page rolls up the same daily page-view data that each schedule owner sees on their own Analytics page, across every non-demo schedule, for the selected date range.

• Device breakdown - total page views for the period split into desktop, mobile and tablet. Views whose device could not be determined are counted in the total only.
• Traffic sources - direct, search, social, email, newsletter and other
• Feature adoption - six bars showing how many verified schedules use Google Calendar sync, sell through Stripe, have a custom domain, use custom CSS, have sent a newsletter, or have run a boost campaign, each as a count and a share of every verified non-demo schedule. The Stripe Payments bar counts schedules with an event actually priced in Stripe, not schedules that merely connected an account.
• Stripe funnel - the three stages that bar skips past: connected an account, finished onboarding, and priced an event in Stripe
• Top schedules by events - the ten schedules with the most events

Open full size

Open full size

Usage (Insights)

The Usage page counts calls to the services your install depends on, so you can see what is consuming your API quotas and mail allowance. Every operation is tallied per day and per schedule as it happens.

Seven categories are summarised in one strip, each with the total for the selected period, today's total against the configured daily limit, and the average per day:

• Emails, AI / Gemini, Google Calendar, Stripe, Invoice Ninja, CalDAV and YouTube

The daily limits come from config/usage.php and its environment variables, not from this page. YouTube has no limit. When today's total for a category passes its limit, its figure turns red and a red Usage Anomalies Detected Today notice appears at the top of the page.

Below the summaries:

Open full size

Open full size

Growth (Insights)

Growth picks up where Users stops: where sign-ups turn into active schedules, and where those turn into paying ones. The page only exists when IS_HOSTED=true, because a plain selfhost has no plans or subscriptions to report on. From top to bottom:

Boost (Manage)

The Boost page is the first page of the Manage tab. It is where you oversee every paid promotion bought on the platform, whether it runs as a Meta ad or as a promotion served on your own pages. From top to bottom:

Granting credit and capping budgets

Below the revenue trend, two forms act on a single schedule, identified by its subdomain (the field autocompletes as you type):

• Grant Boost Credit - add up to 1,000 to a schedule's boost balance. A boost is paid from the balance when the balance covers its whole cost; otherwise the card is charged. Schedules holding a balance are listed underneath.
• Set Spending Limit - raise or lower the maximum budget that schedule may put on a single campaign. Schedules with a custom limit are listed underneath; when none has one, the card names the default that applies to everyone else instead.

Both are written to the audit log.

Open full size

Open full size

Schedules (Manage)

This is the Schedules page of the Manage tab, at /admin/schedules, and it is there on every install. On a hosted install the older /admin/plans address redirects to it. It is the one place in the admin panel where you change something about an individual schedule. From top to bottom:

Editing one schedule

Edit opens the schedule on a page of its own, under a Schedules link that leads back to the list. Its name and address head the page, and each card below saves on its own:

Restore is also the undo for a takedown you did not start: the same release runs when someone who holds the contact address on an unclaimed page signs in and chooses This is not me, and when a schedule is deleted through the API. Every change here is recorded in the audit log with the values before and after, including both subdomains, so a release can be traced later.

Plans are the only hosted part

This page is on every install, because a schedule can be deleted and its name released on a selfhosted install too, and this is where you undo it. Only plans behave differently: a plain selfhost resolves every schedule to the Enterprise feature set, so the plan counts, the plan filters and columns, and the card that assigns a plan only appear on hosted installs. The features in each tier come from the application itself and what a plan charges from your Stripe prices; neither can be edited here. The figures the site advertises are set in the Plan pricing card on Settings.

Blocked (Manage)

The Blocked page, at /admin/blocked, is where you shut out an account that abuses the service, and where you keep the list of what new accounts are refused for. It is there on every install. Deleting a spam schedule on the Schedules page leaves its owner free to make another one; blocking the account does not.

• Four totals - accounts that may be spam, blocked accounts, entries on the list, and how many sign-ups the list has refused
• May be spam - accounts a watched word turned up for, waiting for you to look at them. See Accounts that may be spam
• Find an account - by name, email address or a schedule it owns. The owner card on a schedule's admin page and the names under Recent sign-ups on the Users page lead to the same place
• Blocked accounts - who is blocked, how many schedules the block took down, when and by whom, and your note
• Refused at sign-up - the list itself, with how often each entry has refused someone

Accounts that may be spam

An account is listed under May be spam when one of your watched words is in the name or subdomain of a live schedule it owns, or in the name of an event it made. Its own name and email address count too once it owns a live schedule, so a ticket buyer or a follower is never listed for theirs. Nothing is done to it: the list is a reason to look, and each row says where the word was found. The same accounts are counted in Needs attention and on the Manage tab, so you see them without opening the page. A new match usually appears within ten minutes; when the admin pages have not been opened for a while, it appears one page load later.

• Review opens the account's own page, where the words found are listed first and you can block it
• Not spam takes it off the list for good, for example an account that runs a bitcoin meetup. Its page then says who marked it and when, with Flag again to undo that. Unblocking an account marks it not spam as well
• A blocked account and an administrator are never listed

Words to watch for, under the list, holds the words, separated by commas. A word is found anywhere in the text, in capitals or not, so a word that sits inside ordinary names will find those too. In a subdomain a space is read as a hyphen, so cash app also finds cash-app-help. Each word needs 3 to 50 characters, and the list holds up to 50. Out of the box it holds common payment, crypto and support-line words: paypal, bitcoin, crypto, coinbase, binance, metamask, cash app, cashapp, venmo, quickbooks, customer service, customer care, helpline and toll free. Leave the field empty to stop watching. Marking an account not spam and changing the words are recorded in the Audit Log.

Blocking an account

A block is decided on the account's own page, which shows what you need first: the schedules it owns, how it signs in, the network address it signed up from, and the other accounts that were made from that same address, each one press away. Press Block account and:

• The account can no longer sign in, by password, Google or Facebook, or use its API key. Anyone signed in to it is signed out on their next page
• Every schedule it owns goes offline and its subdomain is released, exactly as Delete on the Schedules page does. A paid plan on one of them is cancelled, and a newsletter waiting to be sent goes back to a draft
• Its email address goes on the list, so it cannot sign up again
• It leaves the lists and counts on the Dashboard and the Realtime page: its sign-up, its schedules and every event it made or they own, even one it put on somebody else's venue. On Realtime its signed-in visits, anyone's views of its pages and what happened on its schedules go too. A few figures still include it, because they are history or work for you: Active users, revenue, the Federation card (an event of its on another schedule is still shared), custom domains, Needs attention and the Insights pages

Two switches add more to the list, and both are off until you turn them on. Also refuse new accounts from the address adds the network address the account signed up from (for an IPv6 address, the /64 it sits in). Also refuse new accounts at the domain adds its email domain. Beside each is the number of other accounts that share it: a large number means an office, a mobile network or a mail provider that ordinary people use, and it should stay off.

An administrator cannot be blocked, and you cannot block yourself. Schedules the account is only a member of are not touched.

Unblocking

Unblock account, on the same page, undoes what the block did and nothing else. The account can sign in again, the schedules this block took down come back, and the entries it added leave the list. A schedule that was already deleted before the block stays deleted, a cancelled plan stays cancelled, and a subdomain somebody has taken in the meantime stays theirs: the schedule then comes back under its released name. If a watched word turns up for the account, Unblock also marks it not spam, so it does not go straight back on that list.

The list

A new account is refused when it matches an entry, whichever way it is being made: the sign-up form, Google or Facebook, the API, or the account a guest form offers. Accounts that already exist are never affected by the list, so adding a domain does not lock anyone out. An entry is one of:

• Email address - one mailbox. A +tag, and for Gmail the dots in the name, do not make a new address
• Email domain - everything at example.com and its subdomains
• Network address - one IP address, or a range such as 203.0.113.0/24. The widest range allowed is /16 for IPv4 and /32 for IPv6

When you add an entry by hand, the page tells you how many existing accounts already match it. The address an account signed up from is kept for 90 days, or for as long as the account is blocked, so the address switch is not offered for an older account. Every block, unblock and change to the list is in the Audit Log.

Private calendars (Manage)

The Private calendars page, at /admin/private-calendars, lists schedules that look as though a calendar import is publishing somebody's private calendar: events that show a meeting's passcode or dial-in code, a join link carrying the meeting's password, or an email made into an entry. A sweep reads the events calendars bring in every 15 minutes, and the list counts toward the alerts on the admin dashboard. It only finds; nothing on the page happens until you press it.

A schedule's page shows what was found first, then four steps, each audited: Hide what is public now (the flagged events become drafts, except ones people hold tickets to, and venues made out of meeting links are taken down), Pause the sync (stops reading the calendar and keeps pushing to it), Tell the owner (an email in the owner's language, with a preview, at most once a week) and Mark reviewed, which takes the schedule off the list until something new turns up. Hiding and pausing can be put back from the same page.

Feeds (Manage)

The Feeds page, at /admin/feeds, lists every feed on the install: the addresses schedules keep reading for events, which schedule reads what, and whether it is being read. A feed is shown by its site, never by its address, because for a private calendar the address is the key to it.

• Three totals - all feeds, how many are failing, and how many are paused
• Search and filter - by schedule, subdomain, feed name or site, and by state: Failing, Paused or Waiting for somebody (drafts to review, or a decision)
• The list - twenty per page, what is not being read first: the schedule, which opens its admin page, the feed with its site, kind and number of events, its status, its last good read and its next try
• Status - a failing feed shows a reason and a status code (http_error 503) and how many tries have failed, never what the other server said. A paused one shows why it was paused. A feed on a schedule whose plan does not include feeds shows Not being read

Actions

• Read now - reads the feed on the next run, whatever its wait after a failure says. Runs start every minute
• Resume - starts a paused feed again with a clean slate

Feeds are read by the app:import-feeds task, every minute, so they need the same cron entry as everything else on the Queue page. Each read is one request to the feed's address, and a feed of posts also opens each new post's own page. All of them go through the same guard as every outbound fetch: public addresses only, with every redirect checked again.

Domains (Manage)

The Domains page lists every schedule that has connected a custom domain, in either mode: Direct, where the domain serves the schedule itself, or Redirect, where it forwards to the subdomain.

• Four totals - all custom domains, how many are direct, and how many of those are active or still setting up
• Search and filters - by schedule, subdomain, domain or hostname, and by mode and status (Setting up..., Active or Setup failed)
• Status - for a direct domain, where Event Schedule believes its setup stands (Setting up..., Active or Setup failed, with the reason for a failure), and under it the phase read back from DigitalOcean when the DigitalOcean API is configured. A redirect has no setup to be in, so its status is empty
• Listing - twenty domains per page, newest first

Actions

• Re-provision - registers the hostname with the hosting platform again and returns the domain to Setting up.... Changing the app's domains redeploys it briefly, which the confirmation says. If the hostname was already registered nothing is changed, and the page tells you to check its DNS record, or to remove the domain and add it back. Direct-mode domains only, and only when the DigitalOcean API is configured.
• Remove - clears the domain from the schedule and, for a direct-mode domain, removes the hostname from the hosting platform. The schedule falls back to its subdomain. If the hosting platform refuses the removal, the domain is kept and marked Setup failed, so you can try again.

Certificates themselves are issued by the hosting platform, not by Event Schedule. If a domain stays on Setting up, the usual cause is DNS that does not yet point at your install. Each owner connects their own domain from their schedule; see Custom domains for the operator's side of the setup.

Referrals (Manage)

The Referrals page lists everyone who signed up through a referral link, and where each referral stands. It is read-only, and it only exists when IS_HOSTED=true, because the program pays its reward in plan credit and a plain selfhost has no plans.

• Figures - total referrals, how many are Pending, Subscribed, Qualified, Credited and Expired, and the conversion rate: the share that got as far as subscribing
• Status filter - one pill per status, which narrows the list to it
• The list - fifty per page, newest first: the referred user and the referrer, each with name and email address, the plan the referred user took, the status, the schedule the credit went to, and the date

What each status means, and when a referral moves from one to the next, is in Referral statuses. A referrer sees their own referrals with the email address masked; this page shows it in full.

Newsletters (Manage)

These are platform newsletters to the people who have registered on your install, which is a different thing from the newsletters a schedule owner sends to their own followers. Only admins can create them, and they never go to a schedule's followers.

The section has three tabs of its own under the admin navigation: Newsletters, Segments and Templates. The builder, a segment and a newsletter's statistics each open on a page of their own, with a link above the title that leads back to the tab they came from.

Composing and sending

1. Create - choose Create Newsletter on the Newsletters tab, start from scratch or from a saved template, give it a subject, and build the body from ten block types: heading, text, button, image, video, divider, spacer, social links, quote and offer.
2. Style it - pick one of five layouts (Modern, Classic, Minimal, Bold or Compact) and set the background, accent and text colours, the font, the button shape and the footer text.
3. Choose the audience - select one or more segments. The recipient count for each is shown as you pick. Leave the selection empty and the newsletter goes to every confirmed account that has not opted out.
4. Check it - preview the rendered email, and send a test to yourself.
5. Send or schedule - send immediately, or schedule it for a future time in your own timezone. A scheduled newsletter can be cancelled while it is still waiting, which returns it to draft.

The Newsletters tab

The list shows each newsletter's subject, its status with the time it went out or is due to, how many recipients it reached, its open and click rates and when it was created. A draft or a scheduled newsletter opens in the builder with Edit; a sent one opens its full statistics with Stats. Clone copies any newsletter into a new draft, and Delete is offered on everything except a newsletter that is being sent.

Segments

The Segments tab lists the segments with the number of recipients each resolves to, above the form that creates one. Five kinds are available:

• All Platform Users - every confirmed account
• Plan Tier (hosted installs) - the owners and admins of schedules on Free, Pro or Enterprise
• Signup Date - accounts created between two dates
• Admins - every admin account, yours included, useful for testing
• Manual - a list you add people to by hand: open the segment, search for an account and choose Add Subscriber

Only the name of an existing segment can be edited; to change what a segment matches, create a new one. Every send drops anyone who has unsubscribed from platform newsletters or turned email off entirely, whichever segment produced them, so an opt-out is honoured even from a manual list. A segment cannot be deleted while a draft or scheduled newsletter still uses it.

Templates

A template is a saved design to start a newsletter from. The Templates tab lists them, each to use, edit or delete, and Create Template builds one from scratch. Any saved newsletter can also be kept as one with Save as Template in its builder.

Open full size

Open full size

Blog (Manage)

The Blog page manages the posts of the marketing site's blog: a list with each post's status, views and word count, Create Post, and edit, preview and delete on each row. The blog belongs to the marketing site, which only eventschedule.com serves, so this page and its entry in the Manage row are missing on every other install, selfhosted or SaaS.

A post the scheduled writer finished but its check would not publish is kept as a draft marked Held, with the reason under its title: fix it and publish it, publish it as it is, or delete it. The check looks at what a post says about the product, the pages it links to, its length and its wording. On the create and edit forms, Generate Content writes a post from a topic and shows what the check made of it above the form; nothing is saved until you save.

Review goes through the posts already published: what the check finds in each, which posts are on the same subject, and what is proposed (keep, rewrite, merge into another post, or hide from search engines). It changes nothing by itself. Merge on a row makes that post's address redirect to the other one, and keeps its text.

Audit Log (System)

The Audit Log is the first page of the System tab: a record of sign-ins, changes and payments across the installation and who made them, newest first. Each row shows the time, the user, the action, the IP address and a line of details. An action that failed or was refused is marked in red.

• Four figures - total entries, entries today, failed sign-in attempts today, and how many distinct IP addresses were seen today
• Filter by category - admin, api, auth, boost, event, google_calendar, profile, sale, schedule, stripe, subscription and webhook
• Filter by date - a From and To range
• Search - matches the action name, the details and the IP address
• Sort - press a column heading to sort by time, user, action, IP address or details, and again to reverse it
• Listing - fifty entries per page

Open full size

Open full size

Queue (System)

The Queue page reports on the scheduler and on background jobs: calendar syncs, newsletter batches, graphics generation and anything else the application defers. It reads from the top down in the order you would ask: is the runner alive (Scheduler), how much has it left to do (Work Waiting), then the jobs themselves. When the scheduler has stopped, a job has failed or the oldest due job has waited more than an hour, a red Queue Health Issues notice says so above everything else.

Scheduler

The card at the top of the page answers one question: is timed work happening at all? Nothing else on this page can drain while the scheduler is stopped, so read it first.

• Last tick - every scheduler run stamps a heartbeat, even on minutes when nothing was due, so a stale value means the scheduler itself stopped rather than that the queue is quiet. The threshold is SCHEDULER_STALE_MINUTES (default 20).
• Rails - each way of running the schedule ages separately: a crontab or worker running schedule:run, and the /translate_data cron endpoint. They are listed apart on purpose, so a worker that has died is visible even while another rail keeps the overall heartbeat fresh. Label a dedicated scheduler container with SCHEDULER_RAIL=worker.
• Scheduled Tasks - how many of the tasks that do something on this install are reporting, and under Needs attention how many are failed or overdue. Those are listed in the card, with the error for a failure; the Show all line under them opens every task with its cadence and when it last ran. Tasks that are a no-op on this kind of install, such as the subscription reminders on a plain selfhost, are left out. A task is only called overdue relative to its own schedule, so "20 hours ago" is fine for a daily task and a problem for an hourly one, and a task skipped because the previous run was still going is not a failure. While the scheduler is stopped the list is hidden, because none of it would mean anything.
• Runtime - the cache store that holds the heartbeat, whether every container can read it, and the host the last task ran on. A store that lives inside one container (file on an install with more than one) hides a healthy scheduler from this page, and the card says so when that is what it is seeing: set CACHE_STORE to a shared driver such as database.

Installs driven only by the /translate_data endpoint see a note instead of the task list: that route reports a single heartbeat rather than per-task results.

Work Waiting

Most timed work never becomes a queued job: the scheduled command does it itself. This card counts the rows those commands still have to get through, which the job counts below cannot show.

• Translation Backlog - what is still waiting to be translated, by kind, with what the last run got through, the rate that makes per hour and an estimate of the time to clear. Rows that have failed repeatedly and are waiting out a retry cooldown are named apart, because the next run will skip them
• Everything else with a countable backlog - one row each, such as Newsletters to send, Events to share, Installments to charge, Unpaid tickets to release and Waitlist holds to expire, beside the task that drains it and how often that runs
• Measure now - the counts are measured at most every five minutes, so the navigation's Refresh does not move them. The foot of the card says how old the measurement is, and this button takes a new one

Jobs

• Four figures - pending jobs (with a per-queue breakdown underneath the number), failed jobs, job batches, and the age of the oldest pending job
• Oldest Pending Job - the last of the four turns red once a job has been due for more than an hour, which normally means the scheduler is not draining the queue
• Pending Jobs by Class - which job type is backing up
• Failed jobs - the hundred most recent, each with its class, queue, failure time and exception; retry or delete them individually
• Pending jobs - the hundred most recent, with attempt count and when each becomes available
• Job batches - the fifty most recent, with progress and failure counts

Three bulk actions sit in the heading of the list each one acts on, each behind a confirmation prompt. They are only rendered when they have something to act on:

• Retry All Failed and Clear All Failed - shown only while there is at least one failed job
• Flush Pending - shown only while there is at least one pending job. It truncates the job table, so the work is discarded permanently; use it only to clear a backlog you know is stale.

Failed jobs are also retried automatically: the cron entry pushes them back onto the queue for you, so a job that failed because of a passing problem (an unreachable mail server, a rate-limited API) usually recovers without anyone touching this page. Each job gets five automatic retries spaced fifteen minutes apart. After that it is left alone rather than retried forever, so a job that can never succeed stops consuming a worker on every cron run - it simply stays in the table with the exception that explains it.

Nothing is set aside permanently. The count resets after a day, so a job left over from a long outage is picked up again tomorrow, and pressing Retry clears it immediately - which is what to do once you have fixed whatever the exception was pointing at. A job whose exception says it refers to a record that no longer exists cannot be retried at all, because the record it needs is gone; delete it.

Open full size

Open full size

Logs (System)

The Logs page reads the application log at storage/logs/laravel.log so you can diagnose problems without shell access. It parses only the last 5 MB of the file, which keeps a very large log from exhausting memory but also means older entries are not shown.

• Four figures - the size of the file, the number of entries read, how many are errors (error level and above) and how many are warnings. When any errors are present, or the file has grown past 100 MB, a red Log Health Issues notice says so first
• Repeated Errors - entries at error level and above, grouped by their message with the variable parts collapsed, showing the number of occurrences and when it was last and first seen. A message only appears once it has been logged at least twice, so this is usually the fastest way to find the one thing going wrong repeatedly. A row opens to its full message and stack trace, and a button copies the error
• Recent Log Entries - up to 200 shown at a time, newest first, each opening to its context and full stack trace. Narrow them to a single level, from emergency down to debug, and search the message text and the stack trace
• Download Log - at the end of the page's opening line, fetches the whole log file
• Clear Log - at the foot of the page, apart from Download on purpose: it asks first, empties the file, and cannot be undone

Open full size

Open full size

App Update (System)

The App Update page shows the version this installation is running next to the latest release published on GitHub, and applies an update in one click. It never appears on eventschedule.com, which deploys from git. The same update is offered on the App Update tab of your own Settings page; the admin one is the operator's copy, and it is the one the System tab badges when a release is waiting.

• Installed Version - what config/self-update.php reports, which the release you are running ships. If this stays on an old number after a successful update, you have a cached config: run php artisan config:clear.
• Latest Version - the newest tag on GitHub, refreshed once a day by a scheduled check so no page load has to wait on the network. It reads Unknown if GitHub could not be reached, which is never treated as an update being available.
• Last Checked - how long ago the latest version was last read from GitHub.
• Check for Updates - ask GitHub now instead of waiting for the daily check. Limited to five requests a minute, because an unauthenticated install gets 60 GitHub calls an hour in total.
• Update - only there while a newer release is out, beside an Update available mark. It asks first, then downloads and installs the new release and runs any new database migrations. Take a backup first.

An update never replaces bootstrap/cache/, so it clears the cached config, routes, events, views and package manifest for you once the new release is in place. If you run php artisan optimize as part of your deployment, re-run it afterwards.

Settings (System)

The Settings page holds the handful of settings that apply to the whole installation. It is built from separate cards, each with its own Save button, and a card is only rendered when it can do something on this install. There are seven, and a plain selfhost sees four of them: Header / Footer Code, Event Schedule network, Platform currency and Realtime visitors, plus Accommodation affiliate when it is enabled. None of these settings can be changed while the install is in demo mode.

Open full size

Open full size

Header and footer code

This is where site-wide tracking such as Google Tag Manager or Google Analytics goes.

• Header Code - injected into the <head> of public pages. Best for tag managers and analytics loaders.
• Footer Code - injected just before the closing </body> tag. Best for deferred scripts, chat widgets, and the Google Tag Manager <noscript> snippet.

The code is applied to public schedule, event and ticket pages. It is never added to the admin portal or to the marketing site. Script tags you paste are given the request's security nonce automatically, so they are allowed to run.

Google Tag Manager and Google Analytics are permitted by the built-in Content Security Policy and work out of the box. Scripts that load from other external domains may be blocked: add the domain to the script-src directive in app/Http/Middleware/SecurityHeaders.php if needed.

Injected analytics are not gated by the cookie consent banner: header and footer code runs before anyone is asked. Gate it yourself on the visitor's choice, which every page exposes as window.esConsent.has('analytics') and window.esConsent.has('marketing'), with an es:consent-change event on document when it changes, and write your own privacy policy under Legal Pages to say what it does.

Event Schedule network

This card opts your installation into sharing its public events with the eventschedule.com listings. From top to bottom:

• Where the install stands - once it has connected: pending review, approved with the number of events on the network and a link to them, or suspended, and when the last sync ran. A sync that failed is reported here too
• Share events with the network - the toggle itself. Turning it off withdraws the listings again
• Contact email - lets the moderators reach you with their decision and the steps to get listed
• Also list these schedules - the schedules you own that have not been listed yet, each with how many of its events would be shared, so switching sharing on and choosing what to share is one save
• The preview - exactly which schedules and events would be sent, each event marked sent, next sync, needs an image or not accepted, so nothing leaves your install unseen
• Two counts under the preview - why it may be shorter than you expect: schedules that have not verified an email address or phone number, and other owners' schedules that have not been listed yet, whose owners are asked on their dashboards

See Federation for the full picture.

Monetization

This card configures advertising on free schedules: whether to show AdSense, the publisher and ad slot IDs, whether personalized ads are allowed, whether to run your own promotions marketplace, whether promotions take priority over AdSense, and the prices you charge per thousand impressions and per click. It stays hidden unless ADS_ENABLED=true and the install is a multi-tenant hosted platform other than eventschedule.com, because a selfhosted install resolves every schedule to Enterprise and so has no free tier for an ad to appear on. See Monetization for what each setting does.

Plan pricing

Four fields, the monthly and yearly amount for Pro and for Enterprise, decided in one place and used everywhere the platform quotes itself: the pricing page and the rest of the marketing site, the user guide, the referral program, the upgrade prompts and Plan tab inside the admin portal, and the structured data search engines read. Saving moves all of them at once, with no deploy and no php artisan config:cache.

Leave a field empty to fall back to the matching STRIPE_PRICE_*_AMOUNT variable in .env; the value in force is shown as the field's placeholder, so an empty box is never ambiguous. Amounts take two decimal places and are printed in the platform currency set below, which means a currency with no minor unit, such as the yen, rounds them to whole numbers. The card is hidden on a single-tenant selfhosted install, where every schedule resolves to Enterprise and nothing quotes a plan price at all.

Platform currency

The currency this installation quotes its own prices in. It decides the symbol printed beside every plan price and upgrade prompt, and it is the currency a new event falls back to when its schedule has no country set. Pick from the same list the ticket and gift-card pickers offer. It defaults to PLATFORM_CURRENCY from .env, and to US dollars when that is unset.

It does not touch money that already exists. A ticket is always shown in the currency it was priced in, a past sale in the currency it was taken in, and a schedule that has set a country keeps the currency that country implies. Changing this never rewrites a stored amount.

Realtime visitors

The first toggle, Record live page views, switches Realtime on or off for the whole install. Turning it on also shows the cookie consent banner, since visitors are identified only after they accept. Turning it off deletes every live activity record straight away.

The second, Show schedule owners live traffic to their own pages, decides whether people who manage a schedule get a Realtime tab of their own on their Analytics page. With it off, Realtime is yours alone.

Venue map

Schedules can show a map of their venues on their public page. It is off until you name its address search in .env, and it has no card on this page.

• MAP_GEOCODER_URL is the address search that finds each venue's position. Your server asks it, once per address: at most four addresses a minute from the scheduler, and one a second for a quarter of a minute after an owner switches a map on. An address is kept while a map still uses it and for 90 days after. It has to answer in Nominatim's /search format, and a key it wants in its query string can be part of the address. Until it is set there is no map and no row in the schedule form.
• MAP_TILE_URL is where a visitor's browser fetches the street images, so that service sees the visitor's IP address. Nothing is fetched until the visitor has allowed marketing cookies or pressed Show map beside a sentence naming the service. Left unset, the map is pins on a plain ground and no third party is contacted from the browser.

OpenStreetMap's own services work for both: https://nominatim.openstreetmap.org/search and https://tile.openstreetmap.org/{z}/{x}/{y}.png. Both are free and both have a usage policy you accept by using them, so a busy install should run its own or use a hosted provider. The credit printed on the map comes from MAP_ATTRIBUTION and links to MAP_ATTRIBUTION_URL.

Accommodation affiliate

Setting STAY22_ENABLED=true lets schedules show a map of lodging near their venues and earn affiliate commission. The card holds a single field, the Fallback Stay22 affiliate ID, used only for schedules that enabled the map without supplying an ID of their own, and never on a schedule's own custom domain. See Accommodation affiliate for the disclosure obligations it places on you.

Cookie consent banner

The banner has no card of its own: it follows from the settings above and from .env. It appears only when something on the page actually needs consent: Google Analytics (ANALYTICS_ID), advertising (ADS_ENABLED), the accommodation map (STAY22_ENABLED), the Meta Pixel for Boosted events (META_PIXEL_ID) or Realtime, which identifies visitors only after they accept. A plain install that has none of those shows no banner at all, and sets no cookie that is not needed to make the site work. It never appears inside an embedded calendar, where nothing that needs consent runs.

Visitors choose two categories separately, or both at once with Allow all and Decline. Analytics covers Google Analytics, which is not loaded at all until it is allowed, and the identified Realtime view (yours, and where you have switched it on, the rows with no name a schedule owner sees). Marketing and embedded content covers the attribution cookies, the Meta Pixel, AdSense, and maps, videos and booking widgets from other sites; until it is allowed, a YouTube video or a Google map shows a button that loads just that one item. A visitor whose browser sends Global Privacy Control declines both automatically and never sees the banner. The choice lasts twelve months, and a Cookie preferences link in the footer of the marketing site and of every schedule page reopens it.

Where you have switched on the schedule owners' view, the banner's first line also says that the organizer of a schedule page sees visits to it, so everyone reads it before choosing. The banner names Google Analytics only on an install that has ANALYTICS_ID set; without it the Analytics option describes the Realtime view alone, and where neither is in use that option has nothing behind it. If you do set ANALYTICS_ID, say so in your own privacy policy under Legal Pages: until you publish one, the banner's Learn more link leads to eventschedule.com's policy, which describes eventschedule.com and may not mention Google Analytics at all.

The attribution cookies, utm_params, utm_referrer_url and utm_landing_page, remember for 30 days which campaign or referring site brought a visitor in, so a later signup or ticket sale can be credited to it. They are written only after a visitor allows marketing. Without that they are never written, and attribution lasts for the current session only, which is enough for a visitor who buys on the same visit.

Set COOKIE_CONSENT_BANNER=true in .env to show the banner regardless, which is what you want if you run marketing campaigns and need attribution to survive across visits.

Translations (System)

The Translations page lets you review and customize every piece of text the app shows, in any of the supported languages. Fix an awkward translation, adapt wording to your industry (for example rename "ticket" to "registration" or "booking"), or fill in missing translations - all without editing any files.

• Pick a language and file - messages holds the app's UI strings; accessibility and marketing are smaller companion files. English is editable too, which is handy for renaming built-in terms.
• Search and filter - find strings by key or text, and set Status to Customized for only the keys you have changed or to Missing translations for those the selected language lacks.
• Edit and save - type your text beside the original. A bar at the bottom of the page counts the unsaved changes and holds Save. Changes apply immediately, are stored in the database, and survive app updates. A per-row revert restores the shipped translation at any time, and clearing a field is the same as reverting it.
• Copy as PHP - at the end of the page's opening line. It copies your customizations as ready-to-paste language-file lines, useful for moving them into another install or contributing a pull request.

Sharing improvements with the community

Many translation fixes are useful to every Event Schedule install. You can share yours with the community for review, and approved suggestions ship with future releases. Nothing is sent unless you choose it. After a save the bar at the bottom asks whether to share what you just saved (Not now, Always share or Share now), and while anything is unshared a Share button beside Copy as PHP opens the list, where you tick exactly which changes to send. The Community sharing card under the table holds the Automatically share translation improvements toggle, for saved changes to be submitted on their own. Keep it off if your wording is specific to your business. Unshared changes are also counted on the dashboard's Needs attention list, so nothing sits forgotten.

Sharing sends the language, the file, the translation key, your suggested text and the shipped text it replaces, plus your app version and a random anonymous install identifier, to eventschedule.com. No URLs, email addresses, or other personal data are included. On eventschedule.com itself there is nothing to share: the same place holds a Review suggestions button, which opens the queue of what other installs have sent.

Where customizations are kept

Customizations are stored in the database and published as override files under storage/app/lang, or wherever LANG_OVERRIDES_PATH points if you run several servers from a shared volume. Hand-made override files (the pre-existing custom translations approach) are adopted into the editor automatically. After restoring a database backup or cloning to a new server, run php artisan translations:publish to rebuild the files.

Legal Pages (System)

Your installation ships with a privacy policy and terms of service written for eventschedule.com. They are almost certainly not the documents you need: privacy law differs by country, and GDPR, PAIA and POPIA each ask for different disclosures. The Legal Pages screen lets you replace them with your own, and add a cookie policy, which the app has no page for otherwise.

There is a card for each of the three documents, Privacy Policy, Terms of Service and Cookie Policy, and each one offers two ways to supply it:

• External URL - link to a policy you already publish elsewhere, for example on your main company website. Every link in the app goes straight there.
• Document - write the policy here in Markdown. It is served from your own domain at /privacy, /terms-of-service or /cookie-policy, styled to match your install, with a "last updated" date. Headings automatically get anchors, so you can link to individual clauses.

If you fill in both, the external URL wins, and the card warns that your document is not being shown. If you leave both blank, the built-in page is used, exactly as before. The end of each card's title row says which of the three is in force (Built-in page, External URL or Your own document), with a View page link once you have supplied one. Each card saves on its own. Nothing ships pre-filled: the editors start empty, because a template written for one jurisdiction would be wrong for most.

Where your policies appear

Saving a document changes every link to it across the whole app at once - the "I accept the terms and privacy policy" checkbox on signup, ticket checkout, RSVPs, booking requests and event submissions, the issued ticket, the admin portal's About menu, and the cookie banner's "Learn more" link, which prefers your cookie policy when you have one. Until you write one, those links continue to point at eventschedule.com.

Federation (System)

The Federation page is the other end of the Event Schedule network card: the moderation queue for the installs that share their events with eventschedule.com. It exists only on eventschedule.com, so it is not in your System row. What you see of it from your own install is the result: the status on the network card (pending review, approved or suspended) and the email the moderators send to your contact address.

• Tabs - Pending, Approved, Suspended and All, plus Flagged while an approved install has changed its address
• Each install - its name, address and contact email, when it was last seen, its public schedules and a sample of the listings it would publish, so an approval is never made on a name alone
• Actions - Approve, after which the install's listings publish automatically, Suspend, which hides them, and Send welcome email. Ticking several installs applies one action to all of them

The Federation guide describes the whole exchange from the selfhost side.

Support (System)

The Support page is the admin's side of the built-in support chat: conversations from people signed in to the app and, on eventschedule.com, from visitors on the website. It only exists when IS_HOSTED=true. Unread messages are counted on the System tab and in Needs attention.

• Support availability - the switch at the top marks you as available for chat, and the words beside it say how you are shown right now
• Conversations - the list, newest message first, with a count on each one that has unread messages and a mark on those that are closed
• The open conversation - who it is (for an account, its email address and schedules), the messages, and the reply box. Close ends the conversation

The page checks for new messages on its own while it is open. How the chat is switched on, who is notified and when, is in Support chat in the SaaS guide.