Use your Playbook365 staff login. Same one as everywhere else.
Late at night you can also post from Slack with /status. It uses the same form as this app.
Sun, Sep 14, 2026 · 1:41 PM ET · One incident open
What customers see on status.playbook365.com right now.
Site checks: 213 of 214 loaded at 1:40 PM ET. 17 not checked. See the log
Found by the system. Nothing here goes public until a person says so.
One web server stopped answering at 1:12 PM. Auto-repair fixed it at 1:15 PM. About 1 in 5 page loads failed while it was down.
The nightly customer check found two email addresses that are no longer customers. They were removed and will not get updates.
The cause is a storage stall at our hosting provider. Booking and payments still work. We are watching it closely and will update within 30 minutes.
Some pages are taking longer than usual to load. We are looking into it.
Announced to subscribers on Sep 12.
Admin dashboard, Online booking and Payments offline for up to 10 minutes.
Every change, and where it came from.
/status.Everything that was, or nearly was, on the public page.
| Incident | Status | Started | Length | Opened via | Updates |
|---|
Planned work customers will notice, plus the routine releases deploybot logs.
Shown on the public page. Linked ones start and end themselves when deploybot calls in.
| Maintenance | Status | Window | Affects | Starts and ends by | |
|---|---|---|---|---|---|
| Database server updateAnnounced Sep 12 · reminder goes out 1 hour before | Scheduled | Tue Sep 1611:00 – 11:30 PM ET | Admin dashboard, Online booking, Payments | DeploybotID mw_41 in the webhook | |
| Storage cluster firmwareCompleted in 38 minutes | Completed | Sun Aug 2411:30 PM – 12:08 AM ET | All services | WebBilly started and ended it by hand |
Logged by the deploy webhook. Never shown to customers unless linked to a scheduled maintenance.
| Release | When | Took | Result |
|---|---|---|---|
| 2026.09.11 | Thu Sep 11 · 11:02 PM ET | 7 min | Finished |
| 2026.09.10 | Wed Sep 10 · 11:04 PM ET | 9 min | Finished |
| 2026.09.09 | Tue Sep 9 · 11:01 PM ET | 6 min | Finished |
| 2026.09.06 hotfixSaturday, critical fix for a weekend event | Sat Sep 6 · 7:40 AM ET | 4 min | Finished |
What the public page lists, in customer words. Change a status here and it shows within a minute.
| Service | Public status | Watched by | On public page |
|---|
An open incident sets these for you. A status you set by hand goes back to Running after 4 hours unless an incident is open, so nothing stays "Slow" by mistake.
| When | Site | Server | Result | Load time |
|---|
Newest first. Showing the last hour; older checks are kept for 90 days.
Last snapshot: Thu, Sep 24 · 6:46 AM CT · 2 problems
| Check | Now | What customers notice | If it fails |
|---|---|---|---|
| Horizon sportid-prodSportID365 workers on s01 | FATAL | SportID365 imports, exports and sync stop | Draft after 30 min |
| App mail on s01csf SMTP rules | Blocked | Little. Most mail uses the SparkPost web API | Staff only |
| Shared storage /homereadable on every node | 5 of 5 | 1 in 5 page loads say Forbidden | Draft if it outlasts auto-repair |
| Web serversApache and PHP 8.4 | 5 of 5 | Errors on that server's share | Draft for PHP, staff only for Apache |
| Databasesmaster and read copy, from every node | Reachable | Everything fails | Draft |
| Redis sessions4% full | OK | People get signed out | Draft at 90% |
| Redis queue0% full | OK | SportID365 sync stops | Draft at 80% |
| Horizon pb-prodshared sync workers on s03 | Running | SportID365 sync stops | Draft after 30 min |
| Disk, load, logs, config cachesprimary load 35 | OK | Nothing directly | Staff only |
Want a live view? @gig health-check in Slack runs the same check on demand.
Active customers only. Checked against FusionAuth every night.
| Who | Channel | Signed up from | Customer check | Since | Status |
|---|
The other ways updates get in, and who can post them.
What customers see at status.playbook365.com.
Deploybot calls this when a release or maintenance starts and ends.
POST /api/hooks/deployrelease.started release.finished maintenance.started maintenance.finishedEvery release is logged. Only a release that carries a maintenance ID is shown to customers. Calls with a bad secret or a timestamp older than 5 minutes are rejected. If a maintenance never gets its finished call, it is flagged 15 minutes after the window and #ops-status is pinged. It never closes itself.
Post from Slack, and tell the team what was posted.
/status in any channel opens the same form as Post updateRuns on this server, not on the cluster, so it keeps working when the cluster does not. Only people on the Team list can use /status, matched by their Slack email. Anyone else gets "Ask Billy to add you".
The cluster's own checks on primary report in here.
Who counts as a customer.
Sent through SparkPost, the same as the app.
Sent through Plivo, the same account Playbook365 uses.
Customers subscribe from inside their own dashboard.
When it lands, those sign-ups arrive here already matched to a customer, with the email and mobile number from their account. Nothing changes on this side.
Things that fix themselves, so nothing stale sits on the public page.
Admins change settings. Posters can only post updates and maintenance. Remove someone and they are signed out everywhere at once.
Picking a status fills in a starting message. Say what they will notice and when you will update next.
Customers see this title. Plain words, no server names.
Inside the normal release window (Mon to Thu, 11:00 PM to 8:00 AM ET).
mw_41 in the webhook. No one has to be awake. If the finished call never comes, it is flagged 15 minutes after the window, never closed on its own.